DEV Community: Cesar Vega

Skills, MCPs, and Commands are the same context engineering trend.

Cesar Vega — Thu, 20 Nov 2025 21:54:01 +0000

What are skills:

Skills are folders of instructions and scripts that Claude loads to do specialized tasks. The point of skills is to make Claude follow guidelines and be more deterministic.

Benefits.

More deterministic
Easy to edit, share, and set up.
Efficient context use.*

Make AI more deterministic.

This is one of the biggest issues with LLMs right now: they spout a lot of code, and they can and will come up with two different approaches and answers to the same prompt. With skills, we add guardrails, instructions, and scripts that tell the LLM exactly what to do. For example, the playwright-skill I downloaded has a helpers.js file which has a bunch of scripts like launchBrowser or safeClick, so Claude can use those functions and the result will always be the same.
* This was also a benefit that MCPs had.

Easy to edit.

Since Skills are just .md files and scripts, they are really easy to edit and share if necessary. The downside is that the files can be hard to maintain if they don't have a single source of truth.

Context

Understanding Claude context

Running /context in Claude code (And in most other CLIs) gives you a breakdown of how context is used in the CLI:

The context is divided into:

System prompt: The instructions set that defines Claude's identity, behavior, and core operational guidelines
- Skills are loaded here.
System tools: Built-in capabilities available in every conversation (file operations, execution, web access, agents).
MCP tools: MCP tools and descriptions of each tool.
Memory files: Project-specific context files (like CLAUDE.md) that provide persistent knowledge about your projects and preferences.
Messages: The actual conversation history between you and Claude in the current session.
Free space: Available context window capacity for additional content.
Autocompact buffer: Reserved space that triggers automatic context compression when filled to prevent overflow.

Skills context

Claude's path when using skills works like this:

At the start of a session, Claude scans all available skill files and reads a short explanation for each one from the frontmatter YAML in the Markdown file - this is very token efficient: each skill only takes up a few dozen extra tokens, with the full details only loaded in should the user request a task that the skill can help solve.

For example, at the very beginning of each session, Claude generates a system context file. In which skills are loaded in a section like this:

   <available_skills>
     <skill>
       <name>analyzing-financial-statements</name>
       <description>This skill calculates key financial ratios and metrics from financial statement data for investment analysis
  (project)</description>
       <location>managed</location>
     </skill>
     <skill>
       <name>example-skill</name>
       <description>Demonstrates the basic structure of a Claude Skill. Use this as a template when creating new skills. (project)</description>
       <location>managed</location>
     </skill>
     <skill>
       <name>playwright-skill</name>
       <description>Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms,
  take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test
  websites, automate browser interactions, validate web functionality, or perform any browser-based testing. (project)</description>
       <location>managed</location>
     </skill>
   </available_skills>

You can see an example of the whole prompts at leaked prompts at ageirtj's repo

All my skills take approximately 200-250 tokens (including XML tags, descriptions, and metadata). The actual descriptions alone (just the text content) would be 35~40 tokens total.

Claude only loads the .yaml-like description and data at the top of the document, and from there it decides if it's worth reading more (Progressive Disclosure):

NOTE: Skills depend on a coding environment

One thing to note is that the skills mechanism is entirely dependent on the model having access to a filesystem, tools to navigate it, and the ability to execute commands in that environment. The filesystem is your computer, and it can change things in YOUR computer. So you should always verify whether your functions or commands have side effects that could affect your system.

This can also be beneficial because you are not dealing with external dependencies, but it brings back the "It works in my computer" problem.

Skills vs MCP

I mentioned that skills are not FULLY loaded upfront; they load the basic description, and then the agent decides whether it's worth reading more. MCPs used to be designed (And some still are) in a way that all of their tools were loaded up front, taking a lot of context. But new MCPs are improving their architecture, and they are using the same patterns as Skills to have separate code execution, which brings their context size to similar levels as Skills.

Note: Technically, you can use scripts in skills and avoid MCPs. (And vice-versa)
You can use both together: MCP connections give Claude access to tools, while Skills teach Claude how to use those tools effectively.
MCP connects Claude to external services and data sources. Skills provide instructions for how to complete specific workflows.

Skills PROS:

Skills are simple: The core simplicity of the skills design is why I'm so excited about it. MCP is a whole protocol specification, covering hosts, clients, servers, resources, prompts, tools, sampling, roots, elicitation, and three different transports (stdio, streamable HTTP, and originally SSE). Skills are Markdown with a tiny bit of YAML metadata and some optional scripts in whatever you can make executable in the environment.
Skills are stable: Since skills are just .md files with scripts, they are usually very stable and simple to maintain.

MCP PROS:

Can connect to external applications: This is the biggest pro in my opinion; If you want an API-like interface that can connect to other applications, this is the way to go, especially since there are many officially supported MCPs from big organizations like Linear/Slack/Stripe. You can also benefit from MCP servers that run the code in the owner's cloud instead of locally.

Things to consider that I didn't delve into:

Reliability, security/isolation, cross-device availability, latency, required runtime permissions, collaboration features, etc...

Plawright MCP vs skill example.

DISCLAIMER: It's not the same maintainer, so some of the features in the MCP are not in the SKILL and vice versa.
The Playwright skill uses around 100 tokens in context, while the MCP uses ONE HUNDRED times more (10'000 tokens). The main difference is that the Skill has a lot of the functionality the MCP has, but it gets loaded ONLY when it's necessary, while the MCP is always in memory.

Here is a breakdown of the approximate token use that Playwrite MCP uses:

  Based on the JSON schema definitions visible to me, here's a rough estimate:

  Simple tools (minimal parameters):
  - browser_close, browser_navigate_back, browser_install, browser_console_messages
  - ~150-250 tokens each

  Medium tools (moderate parameters):
  - browser_resize, browser_navigate, browser_press_key, browser_take_screenshot, browser_wait_for, browser_tabs
  - ~300-500 tokens each

  Complex tools (extensive parameters with nested schemas):
  - browser_evaluate, browser_fill_form, browser_click, browser_type, browser_drag, browser_hover, browser_select_option, browser_run_code
  - ~500-800 tokens each

  Rough total estimate: 8,000-10,000 tokens for all 22 Playwright MCP tools, including their full JSON schema definitions, descriptions, and parameters
  specifications, and metadata.

I will say this again, 10'000 tokens in context for something we might not use is not worth it. I have personally disabled the Playwright MCP, but I had to change the Skill a bit to fit my work better (which is waay easier to do in Skills, since I have the files right there in my codebase).

Semi-outdated MCP criticisms (In my opinion):

I saw this quote by Simon Willson, but I think the main point about spending tokens can be mitigated by good MCP design:
* "My own interest in MCPs has waned ever since I started taking coding agents seriously. Almost everything I might achieve with an MCP can be handled by a CLI tool instead. LLMs know how to call cli-tool --help, which means you don't have to spend many tokens describing how to use them—the model can figure it out later when it needs to."
* My comment about this is that there is a new trend with MCPs that do the same as Skills, they display a short description and then point to relevant files and scripts to be used. - But note: For most tasks, it's probably still better to use Skills.
- https://www.anthropic.com/engineering/code-execution-with-mcp

What about RAG?

RAG is a concept that was very hyped before, and it's still relevant. RAG is a middle step where the agent searches and retrieves external data with whatever tools are available to it - grep, vector database, or any relevancy algorithm.

It can be similar to Skills or MCPs in the way that it's a tool that an LLM can use to improve its answer.

What about Claude commands?

Custom slash commands allow you to define frequently-used prompts as Markdown files that Claude Code can execute. There are plenty of pre-loaded commands in Claude code like /context, /mcp, /github, etc...
They behave almost the same as skills in the way that they are some kind of script or prompt that the LLM runs when you tell it to.

It seems that commands haven't gained a lot of traction, and I think it's because they tend to be focused on small changes. I think of Skills as an orchestrator of commands. If a command is a single function or bash, skills are a group of functions or commands.

Understanding that context is stateless,

We pass the whole conversation every time
One thing that really helped me understand why keeping context clean is important is that LLMs are stateless; in every new message, we are just passing the whole conversation back and forth to the model (Maybe some providers optimize for this?). So every new message ends up being your whole conversation and the latest message attached to it.

Sending a single-line message at the end of a 400-line discussion with a lot of back-and-forth is a lot different than sending one at the end of a 100-line structured discussion. MCPs and Skills can help us keep this context as small as possible and even save their thoughts in concise documents that we can reference in a new chat with an LLM.

Conclusion

Claude, it's becoming a general agent, an orchestrator. Skills, Commands, MCPs, and Agents make this explicit. And we as developers will have to focus a lot more on managing Context and providing guardrails, scripts, and instructions to restrict the LLM when necessary and let it work in what it does best.

Even when models are pushing context windows of 1 million tokens, they still struggle to keep track of things we have done in long conversations, so keeping things understandable and documented is still critical.

Feel free to send me sources and comments about this.

Sources:

https://support.claude.com/en/articles/12512176-what-are-skills
https://simonwillison.net/2025/Oct/16/claude-skills/
https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
https://github.com/lackeyjb/playwright-skill?tab=readme-ov-file
https://news.ycombinator.com/item?id=45619537

https://github.com/asgeirtj/system_prompts_leaks/blob/main/Anthropic/claude-4.5-sonnet.md
https://www.anthropic.com/engineering/code-execution-with-mcp
https://aws.amazon.com/what-is/retrieval-augmented-generation/
https://code.claude.com/docs/en/slash-commands
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

In Cursor, Context is King.

Cesar Vega — Sat, 05 Jul 2025 17:07:15 +0000

Executive summary

If there is one thing you should take away from this document, it is to "Document what you are doing in a separate file."
If you have time for a second thing, it is "Add context manually."

Understanding Context.

Context window

First, what is a context window? And how does it relate to effectively coding with Cursor?

A context window is all the context an LLM has when answering a prompt.

In Cursor, "context" is the information that is provided to the model. There are two types of context:

Intent context defines what the user wants to get out of the model. For example, a system prompt usually serves as high-level instructions for how the user wants the model to behave. Most of the "prompting" done in Cursor is intent context. "Turn that button from blue to green" is an example of stated intent; it is prescriptive.
State context describes the state of the current world. Providing Cursor with error messages, console logs, images, and chunks of code are examples of context related to state. It is descriptive, not prescriptive.

Providing context to Cursor.

When answering a prompt, Cursor will try to find context by itself, it does this with a proprietary model that pulls in the parts of your codebase that the model estimates are relevant, such as the current file, semantically-similar patterns in other files, and other information from your session. It also might use "tools" and MCPs like web search to find relevant context.

This proprietary model is pretty good, but it falls short when dealing with complex problems.

I made an experiment to show this. The experiment is a variation of the "Needle in the haystack" test. In this test I placed a riddle in our code, and asked Cursor to solve it.

Context experiment

The experiment consisted of a riddle that added a .txt file of 25k characters ~ 6k tokens with random text, and a riddle inside the random text. In this case, the riddle was a Caesar cipher with the key at the end of the file.

If anyone wants to see the whole experiment, please comment or DM me.

The results of the experiment were:

* Gemini 2.5 pro
 - Finds the file correctly ❌
 - Gets the answer correct. ❌

* Claude 4.0 sonnet
 - Finds the files correctly ✅
 - Gets the answer right. ✅

As we see, even with only a 6k context window, the Gemini model can't figure out the answer to the riddle. (6k tokens is about ~850 lines of code, 4 characters =~ 1 token).

I haven't confirmed, but I am sure that if I made the puzzle more intricate by adding text and more cross-references, the model would break

This is relevant because imagine Cursor looking for how to answer your prompt in the best way possible, it will look online, it will look at all your files, but it won't read them UNLESS you pass the file into context. (You can test this by seeing how many tokens are passed if you use a custom API token in Cursor)

How much context do we have?

In Cursor; Gemini, and Claude have 120k tokens for context. That might seem like a lot, but remember our experiment with 6k context? The models could degrade with way shorter contexts.

Here is the context of a few things for anyone interested:

Average stack overflow page call ~15k tokens.
The code files in a mid-sized company are at least a few million characters, which is at least 0.75 Million Tokens
- Average characters per file is about 4,721 characters ~= 1k tokens.
- Large files for an average company are ~= 30k characters ~= 8k tokens.

How Cursor handles a prompt.

This is how the Cursor handles a prompt:

You write your prompt and add your context. Then press enter.
Cursor uses it's proprietary model to analyze your prompt and context. You haven't hit the AI model yet (Gemini, Claude, etc...)
- There is no official documentation that says this directly, but there are allusions to it in Cursor official docs, and in Anthropic's system prompt docs. (And the leaked system prompt from Anthropic around May 2025).
  - Cursor prompts some tools with a proprietary LLM or algorithm to decide what MCPs to use.
Cursor takes the context you added, AND it takes what it thinks is the relevant context and appends it to the api.
- Cursor also adds a small system prompt (can't find official docs. But cursor adds about ~1k tokens to all your requests. I assume those are its custom instructions.)
The API/LLM then processes the prompt, and you receive the answer.

How to improve my prompts? - Keep track of your decisions in a document.

Finally, the good part. Here is what to do if you want to significantly improve the context that you send Cursor:

Make one or two documents depending on how big is your task, I usually call it "PLAN.md" and/or "TASKS.md"
Write down the problem, objective, insights and thoughts you have, and a plan on "PLAN.md", you can use AI to help you write the plan. It's usually useful to ask AI to write a plan with "atomic" steps, so it gives you small steps to follow.
Start working on the problem, every time you make progess (progress might be a new insight, a new piece of code, etc...), write down what you did on "TASKS.md", it's even better if you can reference what you did at "PLAN.md" too. Then commit.
Keep going. Remember to write new insights, failed attempts, and sources too in your documents. This development loop forces two things.
- You will think more about what you are doing, which is a lot of help as a developer.
- The AI will keep close track of context, and you can easily revert and correct if it goes off track. The AI will also be way better at problem-solving.

How to organize your project's folders - A quick guide to repository and folder structures.

Cesar Vega — Sun, 15 Oct 2023 15:49:17 +0000

Depending on your objectives and needs, there are many ways of organizing a project in React. But some patterns are considered best practices; here, I'll explain a few.

Atomic Design.

Atomic Design is a concept introduced by Brad Frost, and it's a methodology to build consistent and reusable design systems, especially in web interfaces.

Atoms

Atoms are the basic building blocks in this methodology. They're the smallest possible components, like form labels, buttons, inputs, or even design tokens such as colors, fonts, etc. Atoms can be abstract and don't necessarily represent the final product, but they help to create a consistent interface and development process.

Molecules

Molecules are combinations of two or more atoms that form relatively simple components together. An example could be a form label, a text input, and a button combined to make a search form. While atoms can exist in isolation (like a button), molecules find their true meaning when used in conjunction.

Organisms.

Organisms are relatively complex UI components composed of groups of molecules (and possibly atoms). Examples might include the header of a website with a logo (atom), a navigation menu (molecule), and a search form (molecule). Organisms provide context for the molecules and demonstrate how molecules can work together.

/src
  /components
    /atoms
      Button.jsx
      Icon.jsx
      ...
    /molecules
      FormInput.jsx
      UserAvatar.jsx
      ...
    /organisms
      Header.jsx
      Sidebar.jsx
      ...
    /templates
      MainLayout.jsx
      UserLayout.jsx
      ...
    /pages
      HomePage.jsx
      UserProfilePage.jsx
      ...

By feature or Domain.

This structure is popular for large projects. Here, we group components by the feature they relate to

/src
  /components
    /Button
      Button.jsx
      Button.test.jsx
      Button.css
    /Modal
      Modal.jsx
      Modal.test.jsx
      Modal.css
  /features
    /Todo
      /components
        TodoList.jsx
        TodoItem.jsx
      TodoActions.js
      TodoReducer.js
    /User
      /components
        UserProfile.jsx
        UserSettings.jsx
      UserActions.js
      UserReducer.js

By File Type

In smaller projects or applications with many shared components, it might make sense to group files by their type.

/src
  /components
    Button.jsx
    Modal.jsx
    ...
  /containers
    TodoContainer.jsx
    UserContainer.jsx
    ...
  /actions
    TodoActions.js
    UserActions.js
    ...
  /reducers
    TodoReducer.js
    UserReducer.js
    ...
  /styles
    Button.css
    Modal.css
    ...

Domain-driven Design (DDD)

For projects that closely align with domain-driven Design, you might structure your folders around aggregates, entities, and value objects.

/src
  /User
    UserAggregate.js
    UserEntity.js
    UsernameValue.js
    ...
  /Product
    ProductAggregate.js
    ProductEntity.js
    PriceValue.js
    ...

Modules or Packages

Modules are self-contained units of code that encapsulate a specific functionality or feature, often used in mono repo structures or when scaling with multiple teams.

/src
  /modules
    /Todo
      TodoView.jsx
      TodoLogic.js
      TodoService.js
      ...
    /User
      UserView.jsx
      UserLogic.js
      UserService.js
      ...

Conclusions

The takeaway is to keep your structure simple. It should be intuitive for developers to know where to place their files and easy for them to be consistent.
I showed a few common structures in this article, but feel free to use what fits your team.

Job hunting in Canada. (And tips for recent immigrants)

Cesar Vega — Sat, 07 Oct 2023 15:46:40 +0000

I got laid off at the beginning of September 2023. And I was lucky enough to get a job offer from another company two weeks later. I have also worked for over eight companies as a contractor and had to go through the same hoops in each.

This piece is not a guide to get into big tech, but rather somewhere in the middle-high range where you can grow, have a balance, and still make good money. So here are my five learnings from my experience:

Be a good engineer.

The article's most essential and irreplaceable point is that you can't swindle your way around getting a software developer job. You need to read and put in the effort to practice coding challenges.
I recommend a few resources for this: roadmap.sh will familiarize you with the concepts you need to learn and provide valuable resources to understand them.

I also recommend neetcode.io to try your hand at practicing coding challenges and essential concepts.

Apply to everything fast.

This advice is controversial, but this is what works for me and a few other people I've talked with. Our current job market is a mess; Some companies post ghost jobs that they don't intend to fill, [1][2], others fill the position and forget their post, and others are almost done with their recruitment process, so the odds are against you, and others.

My solution is to apply to everything quickly, sort postings by date, and apply to every job related to what you want, even in companies you don't like.
Now, you either get an opportunity to interview for a company you like or you get practice interviewing with a company you don't like. Remember, you can always turn down an offer.

Note: I have heard that this is mean and that you are wasting people's time. This point is debatable, but the short answer is that most companies have their interview process automated, and most companies don't care if they are wasting your time with many rounds of interviews. You should follow your moral compass, but don't feel bad for doing what you must do.

I usually hear this kind of argument from underrepresented people in tech, especially women. If it helps, most companies want to attract more BIOPC, LGBTQ+, and woman coders, so apply liberally. [3] [4] [5]

Where to apply?

I don't like LinkedIn, but in Canada, there are excellent offers at Indeed.com, Levels.fyi and my favorite Hired.com, a friend also recommended simplify.jobs.

Tips for immigrants

In Canada, it is generally not legal for employers to ask about your immigration status during the hiring process [6]. But if you are requested your immigration status after receiving a job offer, you should disclose it at this point. [7].

But then again, if you want the job, you will disclose it if they ask. My advice is to be honest, always have your papers in order, and keep your answers short so you don't dig a hole for yourself. If you are worried about this, contact an immigration lawyer.

Be patient.

I sent almost 100 applications before getting an offer, and earlier in my career, there were times when I spent months and over 300 applications before getting a job. Be patient and learn what you are comfortable negotiating. Plenty of companies are out there, and work is a big part of the day, so feel free to let one offer slip out if you don't fit in the culture. But don't be too picky, you might realize that you enjoy working at a company after all.

Sources:

Fixing (and removing) commits in a git branch for beginners.

Cesar Vega — Sun, 01 Oct 2023 14:34:27 +0000

We have all been there. You want to merge and have a different set of commits that you want to have. Maybe you rebased a branch you shouldn't have or checked out from the wrong branch. But don't worry, fixing it is easy.

In this article, I will show a few techniques to get your branch exactly how you want it and avoid merging code and commits that do not belong in your target branch.

Let's start with an example where we have four commits:
git log --oneline

c761a8f (HEAD -> my-feature) commit-3
e056796 bad-commit-1
269a02d commit-2
ceaab87 commit-1

We can see that a bad commit snuck into our branch, so how do we fix it?
It's simple: First, we make sure the commit is unnecessary and want to remove it.
We can do this with:

git show e056796
or
git diff e056796^!

And then, we can see what our commit did.

Pro tip: This command will look prettier if you have customized your terminal with tools like ohMyZSH

Our second step is to take that commit out of our history. I do this by rebasing our branch. We would do an interactive rebase to our target branch in our example.

git rebase -i target-branch

An editor (often Vim or Nano) will open, showing the last commits. It'll look something like this:

pick ceaab87 commit-1
pick 269a02d commit-2
pick e056796 bad-commit-1
pick c761a8f commit-3

So, to keep the commits we want, delete the line corresponding to the bad commit (bad-commit-1):


pick ceaab87 commit-1
pick 269a02d commit-2
pick c761a8f commit-3

Exit and save the file.

Pro tip: For Vim, press "i" to interact with the text. And then, you click "ESC" -> "wq" to save and exit.

Finally, if you've already pushed your branch to a remote repository before this change, you'll need to force push your changes:

git push origin your-branch-name --force-with-lease

And now you have a clean branch without all those pesky commits. Always double-check with your team if those commits are unnecessary, and remember that this will only affect YOUR branch, so don't be too scared to go through the process.

Understanding Coupling in React: Best practices and Examples

Cesar Vega — Mon, 25 Sep 2023 19:34:38 +0000

Coupling refers to the degree of interdependence between different modules or classes in a system.

What is Coupling?

Coupling speaks to how closely connected different components or modules are within an application. High coupling means that changes in one module may necessitate changes in many other modules. This results in a codebase that becomes increasingly difficult to maintain and modify over time. As such, best practices usually recommend minimizing coupling.

Separate Components by Responsibility

A prevalent form of coupling occurs when a single file or component assumes multiple responsibilities (Look at the Single Responsibility Principle). We should avoid patterns where a component takes on multiple roles; For example, having a component determine if it should render as a header or footer based on props:

const HeaderOrFooter = ({ isHeader }) => {
    if(isHeader){
        return (<div className="header">...</div>)
    } 
    return (<div className="footer">...</div>)   
}

Instead, consider creating distinct components for different roles and handling display logic at the parent level:

const ParentComponent = () => {
    ...
    isHeader ? <Header /> : <Footer />
}

const Header = () => {
    return (<div className="header">...</div>) 
}
const Footer = () => {
    return (<div className="footer">...</div>)   
}

Avoid Prop Drilling

Prop drilling refers to the practice of passing props from a parent component down through its descendants. If your components are tightly intertwined with a shared state, it's a clear sign of tight coupling.

const ParentComponent = () => {
    ...
    const [prop1, setProp1] = useState()
    const [prop2, setProp2] = useState()
    const [prop3, setProp3] = useState()

    <ChildComponent prop1={prop1} .... prop3={prop3}/>
}

const ChildComponent = ({prop1, prop2, prop3}: IChildComponent) => {
    <GrandChildComponent prop1={prop1} .... prop3={prop3}/>
}

To combat this, you can use shared context or architect your components with a clearer separation of concerns. Remember to use context carefully to avoid bloating the global state.

const ParentComponent = () => {
    const [prop1, setProp1] = useState()
    const [prop2, setProp2] = useState()
    const [prop3, setProp3] = useState()
    ...
    <ChildComponent />
}

const ChildComponent = () => {
    ....
    <GrandChildComponent />
}

const GrandChildComponent = () => {
    const {prop1, prop2, prop3} = useContext('SharedContext');
    return (...)
}

Fetch Data Close to Where It's Used

This is more of a personal preference, but I like fetching and managing data as close to its usage point as possible. This helps reduce unnecessary props passed down and keeps data handling within the concerned component.

const ParentComponent = () => {
    ...
    const data = useGetData()
    <ChildComponent data={data}/>
}

A better approach:

const ParentComponent = () => {
    ...
    <ChildComponent />
}

const ChildComponent = () => {
    data = useGetData();
    ....
}

In conclusion, managing coupling is essential for scalable and maintainable applications. By separating concerns, avoiding prop drilling, and fetching data where it's used, we can significantly reduce the effects of high coupling and build more robust React applications.

useContext to manage state between React Sibling Components.

Cesar Vega — Tue, 12 Sep 2023 14:47:26 +0000

Have you ever wanted two separate components that share common state? Maybe a controller component and a display component where one component deals with the controls and the other with displaying it. Something like this:

const [a, setA] = useState()
...
...
...

(
<Box className="grid gap-4" style={{ gridTemplateColumns: "1fr 1fr" }}>
     <GameGrid a={a} b={b} c={c}/>
     <GameControls setA={setA} setB={setB} setC={setC}/>
</Box>
)

It might be okay if we just pass a couple props, but even with few props it feels wrong. So, how do we do it?

Share context between sibling components.

To do this you need to create a context object and wrap the components in it. And then you can get the context in each object, regardless of where you manage the sate.

const GameContext = createContext<IGameControls>({
  a: 'x'
  setA: () => void
  ....
});

export const Game = () =>{
 const contextValue: IGameControls = {
    a,
    setA,
    b,
    setB,
    ....
  };

return (
    <GameContext.Provider value={contextValue}>
      <Box className="grid gap-4" style={{ gridTemplateColumns: "1fr 1fr" }}>
        <GameGrid />
        <GameControls />
      </Box>
    </GameContext.Provider>
  );
}

One important thing to pay attention to is that we only share this state between the sibling components, so the rest of the code is not burdened by this data.

And now we can get the context in each component easily:

const { a, setA, .... } = useGameContext();

Extra sources:

Next.js server prop did not match client prop; And conditional style/class rendering

Cesar Vega — Mon, 11 Sep 2023 22:01:11 +0000

Have you ever gotten the enigmatic Next.js error: "Warning: Prop "{your-prop}" did not match. Server: "{value-1}" Client: "{value-2}"?

Here is the fun fact, conditional rendering did not cause this error. But at the beginning I thought it did, that's why I created this post, so everyone struggling to get rid of that error can understand why it happens, and how to solve it.

Here is our example:

type TGrid = (0 | 1)[][];

const generateRandomTiles = () => {
  const grid: TGrid = [];
  for (let i = 0; i < numRows; i++) {
    grid.push(Array.from(Array(numCols), () => (Math.random() > 0.7 ? 1 : 0))); // returns a live cell 70% of the time
  }
  return grid;
};

export const Game = () => {
  const [grid, setGrid] = useState<TGrid>(generateRandomTiles());

  return (
    grid?.map((rows, i) =>
      rows.map((col, k) => {
          return (
            <div
              // classNames is a library that combines class texts. But this can be thought as "w-4 h-4 border-solid border border-gray-400" + grid[i][k] ? "bg-pink-400" : "bg-white"
              className={classNames(
              "w-4 h-4 border-solid border border-gray-400",
              grid[i][k] ? "bg-pink-400" : "bg-white"
              )}
              key={`${i}-${k}`}
            />
          )
      })
    )
  );
};

This code causes the following error to fire:

Warning: Prop className did not match. Server: "w-4 h-4 border-solid border border-gray-400 bg-white" Client: "w-4 h-4 border-solid border border-gray-400 bg-pink-400"

So I thought it happened because I conditionally rendered bg-pink-400 and bg-white. But it wasn't, the real problem is a little more sneaky than that.

Do not generate values when defining useState.

The real culprit is this the line where we define our grid state:
const [grid, setGrid] = useState<TGrid>(generateRandomTiles());

The problem here is that Next.js has certain state in mind when we generate the tiles in the server, but when the client runs hydrates, we end up with a different random array when we generateRandomTiles() in the frontend. You can notice this if you console log grid, and check your next.js terminal log and your frontend log.

There is a great article by react.gg about this: https://ui.dev/c/react/effects?ck_subscriber_id=2248853627

How do we fix it?

Simple, we manage effects on the frontend. Like this:


const [grid, setGrid] = useState<TGrid>();

  useEffect(() => {
    const initialGrid = generateRandomTiles();
    // Comment, first refresh
    setGrid(initialGrid);
  }, []);

Now we will not have a mismatch between frontend and backend style rendering, and the error will not happen anymore.

DEV Community: Cesar Vega

Skills, MCPs, and Commands are the same context engineering trend.

What are skills:

Benefits.

Make AI more deterministic.

Easy to edit.

Context

Understanding Claude context

Skills context

NOTE: Skills depend on a coding environment

Skills vs MCP

Skills PROS:

MCP PROS:

Things to consider that I didn't delve into:

Plawright MCP vs skill example.

Semi-outdated MCP criticisms (In my opinion):

What about RAG?

What about Claude commands?

Understanding that context is stateless,

Conclusion

Sources:

In Cursor, Context is King.

Executive summary

Understanding Context.

Context window

Providing context to Cursor.

Context experiment

How much context do we have?

How Cursor handles a prompt.

How to improve my prompts? - Keep track of your decisions in a document.

How to organize your project's folders - A quick guide to repository and folder structures.

Atomic Design.

Atoms

Molecules

Organisms.

By feature or Domain.

By File Type

Domain-driven Design (DDD)

Modules or Packages

Conclusions

Job hunting in Canada. (And tips for recent immigrants)

Be a good engineer.

Apply to everything fast.

Where to apply?

Tips for immigrants

Be patient.

Sources:

Fixing (and removing) commits in a git branch for beginners.

Understanding Coupling in React: Best practices and Examples

What is Coupling?

Separate Components by Responsibility

Avoid Prop Drilling

Fetch Data Close to Where It's Used

useContext to manage state between React Sibling Components.

Share context between sibling components.

Extra sources:

Next.js server prop did not match client prop; And conditional style/class rendering

Do not generate values when defining useState.

How do we fix it?

Useful links if you want to go deeper: