How to build a Claude Code skill stack that runs your entire dev process

Most developers using Claude Code are still treating it like a fancy autocomplete. They open a chat, type a request, get some code, copy it in, and repeat. That works fine for small tasks. But it falls apart the moment you're trying to run an actual product development cycle — deciding what to build, breaking a PRD into tickets, planning the implementation, writing the code, validating it works, and reviewing it before it ships.

The fix isn't a bigger prompt. It's a stack of small, focused skills that each own one stage of that process, so the agent always knows exactly what "good" looks like at every step.

This guide walks through how to build that stack yourself, using the official Agent Skills standard that now powers Claude Code, Claude.ai, and even other coding agents like GitHub Copilot and Cursor.

What actually is a Claude Code skill?

A skill is a folder containing at minimum a SKILL.md file with YAML frontmatter and instructions. Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks, teaching Claude how to complete specific tasks in a repeatable way. Anthropic maintains the official spec and examples in the anthropics/skills GitHub repository, which is the best place to see real-world examples before writing your own.

The mechanism behind why skills work so well is called progressive disclosure. The Skill's YAML frontmatter provides discovery information, and Claude loads this metadata at startup and includes it in the system prompt. The full instructions only get pulled into context when they're actually needed, which keeps your token usage sane even with a dozen skills sitting in a project.

Full official documentation lives at Claude Code Docs — Extend Claude with skills, and it's worth reading start to finish before you build anything custom.

Why does the description field matter more than the instructions?

This is the part almost everyone gets wrong on their first attempt. The frontmatter isn't documentation for humans — it's the trigger mechanism the agent uses to decide whether to even load your skill.

The agent decides whether to load your skill based entirely on the description field, and skills appear in Claude Code's context as a list of names and descriptions — when you make a request, the agent scans that list and loads any skill whose description matches what you're asking for. Write it too vague, and the skill never fires. Write it too narrow, and it misses obvious variations of the same request.

If you're building a skill for turning a PRD into tickets, don't write "helps with tickets." Write something specific: "Use when the user has a product requirements document, spec, or feature description and needs it broken into implementable engineering tickets with acceptance criteria."

How do you structure a full development pipeline with skills?

Think of your development process as a pipeline with distinct handoffs, and give each handoff its own skill:

1. Decide what to build — a skill that interrogates a rough idea, asks clarifying questions, and produces a lightweight spec or PRD.
2. Cut the PRD into tickets — a skill that reads that spec and outputs scoped, sequenced tickets with acceptance criteria.
3. Plan the implementation — a skill that reads a single ticket, explores the codebase, and writes an implementation plan before any code gets touched.
4. Build — a skill (or just the agent's default behavior plus your CLAUDE.md) that executes the plan step by step.
5. Validate — a skill that runs tests, checks the build, and iterates on failures without you babysitting it.
6. Code review — a skill that reviews the diff against both your team's coding standards and the original ticket's intent.

Each of these should be a separate SKILL.md, kept minimal on purpose. A skill that tries to do everything defeats the point of progressive disclosure — you want small, composable pieces the agent can chain together in one conversation, the same way you'd hand off work between team members.

What does a real validation skill look like in practice?

Validation is where a lot of custom workflows get built wrong, because people write a skill that just says "run the tests." A better validation skill teaches the agent to discover the actual verification steps for your specific project and remember them.

Claude Code's newer built-in tooling actually automates part of this. Running the skill generator once per project builds a recipe, and when the agent has to build and drive an app without a recorded recipe, it writes what worked to the skills directory at the repo root, so later runs and other agents follow the same steps — at the repo root, the recorded skill replaces the bundled version. That means your validation skill gets smarter the more you use it, instead of staying static.

This is the piece that makes autonomous iteration actually reliable. As long as the agent has a documented way to check its own work — build commands, test runners, a way to spin up the app and click through it — it can catch its own mistakes and correct course without you stepping in every five minutes.

How does code review as a skill differ from asking for a review in chat?

Asking "can you review this?" in a normal chat gets you a generic pass. A dedicated code review skill gets you something closer to what a senior engineer would actually leave in a PR comment, because you can bake in the specific dimensions that matter to your team.

Look at what's already out there for inspiration. One popular pattern reviews the changes since a fixed point along two axes — whether the code follows the repo's documented coding standards, and whether it matches what the originating issue or PRD asked for — running both reviews in parallel sub-agents and reporting them side by side. That two-axis approach (style compliance vs. spec compliance) catches a different class of bug than a generic "look for issues" prompt ever will.

You can browse dozens of these patterns at Claude Code Skills — Code Review category before writing your own from scratch. It's often faster to adapt an existing one than to start blank.

How do you actually install and organize these skills?

Custom skills in Claude Code are entirely filesystem-based, which makes them easy to version, share, and drop into any repo.

Custom Skills in Claude Code are filesystem-based and don't require API uploads: place them in ~/.claude/skills/ (personal) or .claude/skills/ (project). Here's the practical setup:

1. Create the folder structure. For a project-wide skill, run mkdir -p .claude/skills/plan-ticket inside your repo. For something you want on every project, use ~/.claude/skills/ instead.
2. Write the SKILL.md. Start with just the frontmatter (name + description) and a short instructions body. Don't overengineer it on the first pass.
3. Test it in a real conversation. Ask Claude Code to do the task in plain language and watch whether it picks up the skill on its own. If it doesn't fire, tighten the description field first — that's the most common failure point.
4. Commit it to the repo if it's project-specific, so the whole team gets the same workflow automatically.
5. Iterate based on real runs, not hypotheticals. Skills get better the same way prompts do — by watching where the agent goes off track and patching the instructions.

One important caveat if you're running things remotely: personal skills in the home directory do not load in Cowork or cloud sessions, since every routine run is a fresh remote session, and a personal-only skill returns "not found" every time. If you want a skill to work in cloud or headless runs, commit it to the project's .claude/skills/ folder instead of keeping it personal.

For a broader look at where skills fit next to hooks, subagents, and CLAUDE.md, the Claude Platform Docs on Agent Skills covers the full mental model, including when a skill is the wrong tool and a hook or subagent would serve you better.

Which skills should you build first?

Don't try to build all six pipeline stages on day one. Start with whichever part of your process currently wastes the most of your time when done manually. For most teams, that's either the PRD-to-tickets breakdown (because it's tedious and inconsistent between people) or code review (because it's the step everyone skips when they're rushed).

Build one skill, run it on five real tasks, fix the description field until it triggers reliably, then move to the next stage. A working skill is a working skill, and the next one will take less time — by the third, you'll start seeing workflows you repeat and immediately think that should be a skill. That's the point.

The teams getting the most out of coding agents right now aren't the ones with the fanciest prompts. They're the ones who stopped re-explaining the same process every single session and instead built a system that remembers it for them. Start with one skill this week — pick the most annoying, repetitive part of your workflow, and give the agent permission to own it.