I had a conversation with a tech lead at a client last quarter that crystallized why this article needed to exist. They had spent three weeks building what they called “their agent fleet,” six custom agents for different parts of their codebase, with bespoke prompts, careful naming, the works. We sat down to look at why they could not figure out how to run two of them in parallel.<\/p>\n\n\n\n
The answer was that they had not built agents. They had built six skills. All living inside one Claude Code<\/strong> session, all loading into the same context window when their descriptions matched. By the time the third one was active, the context was past 150K tokens<\/strong> and quality was degrading. Running two of them at once was not a thing because they were not separate processes. They were paragraphs in the same prompt.<\/p>\n\n\n\n The conceptual gap cost them three weeks. The rewrite, once we named the primitive correctly, took two days. The system was much smaller after we were done, and it ran in parallel for the first time.<\/p>\n\n\n\n This article is the layer most teams confuse, written so you do not have to lose those three weeks.<\/p>\n\n\n\n Before skills versus subagents, the layer that gives both of them context. Claude Code (and any modern coding agent) operates on three orthogonal layers, and most teams have only really internalized one of them.<\/p>\n\n\n\n Tools are verbs.<\/strong> They are what the agent can physically do, there’s some questions, for example:<\/p>\n\n\n\n These are built into the agent. You do not configure them. You allow or restrict them.<\/p>\n\n\n\n MCPs are external connections.<\/strong> The Model Context Protocol<\/a> is an open standard Anthropic introduced in November 2024 and has since been adopted by OpenAI, Google, Microsoft, Cursor, and most agent surfaces<\/a>. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation.<\/p>\n\n\n\n Anthropic-reported adoption: <\/strong>97 million-plus monthly SDK downloads and 10,000-plus active MCP servers. MCP is the layer that connects your agent to your production database, Datadog, Sentry, GitHub, Slack, Jira, and anything else with an API.<\/p>\n\n\n\n Skills are recipes \u2014 folders of markdown that tell the agent how to do a specific kind of work well in your context: when to write a Postgres migration this way and not that way, how to structure a spec at this company, what “code review” means when this particular team does it. They are the institutional knowledge of your team, version-controlled and tool-agnostic.<\/p>\n\n\n\n The three layers are independent. Most teams I see have figured out tools (they ship features), have plugged in two or three MCPs (usually GitHub and a database), and have done almost nothing on skills. Skills are where the highest-leverage investment is for most teams in 2026.<\/p>\n\n\n\n Read more: <\/strong>The Three Eras of Software: From Autocomplete to Agentic Development<\/a><\/p>\n<\/blockquote>\n\n\n\n A skill is a folder. At minimum it contains a SKILL.md with two YAML frontmatter fields: name and description. That is the only required content. Optionally, the folder can include references\/ (additional markdown loaded on demand), examples\/ (concrete examples the agent reads when relevant), and scripts\/ (executable code the skill can call).<\/p>\n\n\n\n The mechanic that makes skills cheap is what Anthropic calls progressive disclosure<\/strong>, and it is on the official skills docs<\/a>. Three levels of loading.<\/p>\n\n\n\n Level one is the frontmatter. Just the name and description. This is in the agent’s system prompt all the time, in every session. Claude reads only this when deciding whether to invoke the skill.<\/strong> A description like “when the user wants to plan a Postgres migration” is what tells the agent “this skill is relevant to this task.” Get the description wrong and the skill never gets used.<\/p>\n\n\n\n Level two is the body of SKILL.md<\/em><\/strong>, loaded only when the skill is activated. Anthropic recommends keeping this under 500 lines \u2014 past that, you are pushing the agent’s working memory and the skill stops being cheap to run.<\/p>\n\n\n\n Level three is the references\/ files. Loaded only when the body of the skill points to them. This is how you carry deep reference material (a 2,000-line database conventions doc, say) without paying its context cost on every task that touches the database. The agent fetches it only when it needs it.<\/p>\n\n\n\n Skills follow a four-level hierarchy:<\/strong> Enterprise, User, Project, Plugins. Same hierarchy as CLAUDE.md, which is intentional. Skills work across agent surfaces too. The same SKILL.md runs in Claude Code, Cursor, Codex CLI, OpenCode, and Copilot CLI. That portability is part of why skills are the layer you should invest in over surface-specific prompts.<\/p>\n\n\n\n I do not love when engineering teams build everything from scratch. Skills are an area where the community has shipped a lot of useful work, much of it free, and forking is usually the right move.<\/p>\n\n\n\n Superpowers<\/strong> is the largest community-built skill pack<\/a>, authored by Jesse Vincent (obra). On January 15, 2026 it was accepted into Anthropic’s official Claude Code plugin marketplace<\/a>, which is roughly the open-source equivalent of getting endorsed.<\/p>\n\n\n\n It ships skills for brainstorming, test-driven development, systematic debugging, subagent-driven development with code review, and skill authoring itself (yes, a skill that writes skills).<\/p>\n\n\n\n Install with \/plugin install superpowers@claude-plugins-official. Works across Claude Code, Cursor, Codex, Copilot CLI, Gemini CLI, and OpenCode.<\/p>\n<\/blockquote>\n\n\n\n GStack<\/strong> is Garry Tan’s pack<\/a>, shipped on March 12, 2026 under MIT. Garry Tan is President and CEO of Y Combinator, and GStack is opinionated in a way that reflects YC’s view of a startup engineering team. Twenty-three specialists modeled as personas (CEO, Designer, Engineering Manager, Release Manager, Doc Engineer, QA Lead, Chief Security Officer, others) plus eight power tools.<\/p>\n\n\n\n The loop the pack enforces is Think, Plan, Build, Review, Test, Ship, Reflect. Useful for small teams that want a strong opinion on workflow without writing one themselves.<\/p>\n\n\n\n Tech Leads Club agent-skills<\/strong> is a pack built by a Brazilian engineering community<\/a>, MIT-licensed, on npm at @tech-leads-club\/agent-skills<\/em><\/strong>. The flagship skill is tlc-spec-driven which implements the Specify, Design, Tasks, Execute workflow with adaptive depth.<\/p>\n\n\n\n Other skills in the pack include skill-architect, subagent-creator, create-technical-design-doc, handoff, and diagnose. Install interactively with npx @tech-leads-club\/agent-skills<\/em> or per-skill<\/em> with agent-skills <\/em>install -s tlc-spec-driven.<\/em><\/p>\n\n\n\n The pattern across all three is the same. Do not build from scratch what someone has already shared. Fork the pack, customize the parts that need to fit your context, contribute back if you can.<\/p>\n\n\n\n Read more: <\/strong>Spec-Driven Development: How to Capture Intent Before You Burn Tokens<\/a><\/p>\n<\/blockquote>\n\n\n\n This is where most teams trip. The anatomy of a subagent looks identical to a skill on paper: a markdown file with frontmatter. <\/strong>The behavior is structurally different.<\/p>\n\n\n\n The official Anthropic docs<\/a> state it plainly. “Each subagent starts with a fresh, isolated context window. It does not see your conversation history, the skills you’ve already invoked, or the files Claude has already read.” That sentence is the whole point. A subagent is a separate process with its own context, its own tools, its own model, and its own permissions.<\/p>\n\n\n\n Four practical differences from skills.<\/p>\n\n\n\n The rule of thumb I use is mechanical: if the same instruction will be reused across many tasks and does not need its own context, write a skill; if the work needs its own isolated window, its own model, or its own tool restrictions, spawn a subagent. Skills are how-to. Subagents are who-does-it.<\/p>\n\n\n\n This is the architectural pattern that makes era-three coding actually scale, and it is the reason getting the skills-vs-subagents distinction right matters.<\/p>\n\n\n\n The shape is one orchestrator agent, typically running on a stronger model (Opus 4.7 in the May 2026 lineup), that coordinates several specialist subagents running in parallel on a faster, cheaper model (Sonnet 4.6).<\/p>\n\n\n\n A typical feature might have a backend specialist, a frontend specialist, an infra specialist, and a product manager specialist, each working in its own context, each producing its own output. Downstream of the specialists, a reviewer subagent reads the combined diffs. The human gates after the reviewer.<\/p>\n\n\n\n The reason this works is the same reason a real software team works. Each specialist has clean context. Nobody’s working memory is polluted by what another specialist is doing. The orchestrator owns the coordination and the contract between the pieces. The reviewer owns the integration check.<\/p>\n\n\n\n Boris Cherny at Anthropic, in Mastering Claude Code in 30 Minutes<\/strong>, describes shipping 20 to 30 pull requests a day this way. Five parallel Claude instances, each running in a separate terminal tab with its own checkout, each started in plan mode<\/a> so the plan can be reviewed before the implementation goes wide. That routine is not possible if your “agents” are skills sharing one context window. It requires real subagents in real worktrees.<\/p>\n\n\n\nThe three layers. Tools, MCPs, Skills.<\/strong><\/h2>\n\n\n\n
\n
\n
What a skill actually looks like<\/strong><\/h2>\n\n\n\n
Ready-made packs worth knowing<\/strong><\/h2>\n\n\n\n
\n
\n
Subagents are different<\/strong><\/h2>\n\n\n\n
\n
The orchestrator and specialists pattern<\/strong><\/h2>\n\n\n\n