Getting 100% Out of Claude Code Skills — And Building Your Own Agents

If you read Part 1, you know the mechanics: what skills are, where they live, how matching and priority work. Good.

Now let’s talk about getting everything out of the system — the patterns that most people never reach because they stopped at “slash commands that work.”

---

The gap between 60% and 100%

Most developers use skills like macros. Type /deploy, it deploys. Type /review, it reviews. Clean, useful, done.

That’s 60%. The remaining 40% is understanding that skills are a composition layer — you can chain them, feed them structured data, spawn real parallel agents, and build workflows that would take a human hours.

Here’s how you get there.

---

Pattern 1: Skills that call other skills

Claude can invoke one skill from inside another. This is how you build multi-step workflows without cramming everything into one massive file.

Say you have:

# release

Prepare a release for the current branch.

Instead of writing every step inline, you compose:

# release

Prepare a release for the current branch. Do the following in order:

1. Run the `/test` skill to verify all tests pass
2. Run the `/changelog` skill to generate a CHANGELOG entry
3. Run the `/deploy` skill to push to staging
4. Report a summary with links and any failures

If any step fails, stop and report the failure clearly — don't proceed.

Now /release is a workflow, not a command. And each sub-skill stays independently useful too. You can call /changelog by itself. You can call /deploy by itself. Composition doesn’t break decomposition.

The key instruction: “in order” + “stop if any step fails”. Without that, Claude might parallelize things that need to be sequential, or keep going after an error.

---

Pattern 2: Structured output with schemas

This one unlocks a lot. By default, skills produce text. But you can tell Claude to return structured JSON that other tools or agents can consume.

Here’s a skill that returns a machine-readable audit result:

# security-scan

Scan the current diff for security vulnerabilities.

## Output format
Return a JSON object with this shape:

{
  "severity": "critical" | "high" | "medium" | "low" | "none",
  "findings": [
    {
      "file": "path/to/file.ts",
      "line": 42,
      "issue": "Short description",
      "detail": "Full explanation",
      "fix": "Suggested fix"
    }
  ],
  "summary": "One-sentence summary"
}

If there are no findings, return an empty findings array with severity "none".

Now you can pipe /security-scan output into a CI check, a Slack notification, or the input to another skill that takes findings and auto-generates fixes.

Structured output is what turns skills from human-facing summaries into machine-composable components.

---

Pattern 3: Build a real multi-agent workflow

This is where it gets fun. Let’s say you want to do a thorough architecture review of a codebase before a big refactor. A single Claude pass will miss things. Multiple independent passes — each with a different lens — will catch much more.

Here’s a skill that does exactly that:

# arch-review

Do a comprehensive architecture review before the planned refactor.

## Agents to spawn (run in parallel)

Spawn three independent agents with the Agent tool:

**Agent 1 — Data flow audit**
Trace how data moves from the API layer to the database. Look for:
- N+1 query patterns
- Missing indexes for common queries  
- Data that gets fetched but never used

**Agent 2 — Coupling analysis**  
Find tight coupling that will make the refactor painful. Look for:
- Modules that import from each other bidirectionally
- Business logic mixed into controllers or views
- Config values hardcoded in business logic

**Agent 3 — Test coverage gaps**
Identify what's not tested that should be. Look for:
- Critical paths with no integration tests
- Business rules only tested at the unit level
- Error paths that aren't tested at all

## Synthesis
After all three agents complete, synthesize a single report:
1. Top 5 things to fix before the refactor (ranked by pain risk)
2. Things that are fine and don't need attention
3. Recommended order of operations for the refactor

Keep the synthesis to one page.

This is the fan-out + synthesize pattern. Three agents run concurrently, each focused, each producing a clean result. Claude then synthesizes. You get coverage that a single pass can’t match, in not much more wall-clock time.

---

Pattern 4: Agents with isolation

When agents need to actually modify files — not just read them — you want them in isolation so they don’t step on each other.

You do this with isolation: 'worktree':

# refactor-parallel

Refactor the three subsystems in parallel without conflicts.

## Instructions
Use the Agent tool with isolation: worktree for each agent:

- Agent 1: Refactor the authentication module (src/auth/)
- Agent 2: Refactor the billing module (src/billing/)  
- Agent 3: Refactor the notification module (src/notifications/)

Each agent works in its own git worktree. After all three complete, 
report a summary of changes so they can be reviewed and merged manually.

Each agent gets a fresh copy of the repo, makes its changes, and you review them separately. No conflicts, no agents clobbering each other’s work.

This is expensive (more API calls, more time) but for genuinely independent large changes, it’s the right tool.

---

Pattern 5: The “verify your own work” agent

This is a pattern I use before any significant push: a skill that makes Claude double-check itself.

# verify-change

Verify that the recent change does what it's supposed to.

## Steps
1. Read the most recent commit message to understand what was intended
2. Spawn an independent agent with this prompt:
   "You are a skeptical senior engineer. Look at the diff from the last commit.
    Find 3 things that might be wrong, incomplete, or that the original developer
    probably didn't test. Be specific — file names and line numbers."
3. For each finding from the skeptical agent, assess: is it a real problem or a false positive?
4. Report: confirmed problems (with suggested fixes), false positives (with explanation), 
   and a final "ship it" / "don't ship" verdict.

The trick here is the independent agent with a different persona. When you ask Claude to review its own work, it tends to rationalize. When you ask a separate agent, playing the role of a skeptic, to find problems — it finds them.

This mimics code review. You wrote it, someone else read it. The adversarial framing gets better results than “please check your work.”

---

Pattern 6: Skills with progressive context loading

For skills that work on large codebases, loading everything at once burns context. Instead, build skills that start narrow and go deep only where needed:

# explain-module

Explain how a module works to someone unfamiliar with it.

## Process
1. Ask the user which module (if not specified in the command)
2. Read only the module's index file first
3. Form an initial hypothesis about what it does
4. Read only the files that are unclear from the index
5. Ask one clarifying question if something is genuinely ambiguous
6. Produce a 3-paragraph explanation:
   - What it does (one paragraph)
   - How it fits into the broader system (one paragraph)
   - The one thing you need to understand to change it safely (one paragraph)

Never read every file. Read enough to explain it well.

The key instruction: “never read every file.” Without that, Claude will try to be thorough and read 40 files for a 3-paragraph explanation. Tell it to be strategic.

---

Building your agent library

Once you’ve got a few skills working, you start to see patterns. Here’s how I think about building a skill library that compounds over time:

Start with your pain points, not best practices. What do you actually do repeatedly that Claude currently gets wrong or you have to explain every time? That’s your first skill. Not “deploy” because deploy is obvious. But “this project’s specific deploy with the 3 edge cases that always trip people up.”

One skill per concern. A skill that does code review AND generates a changelog AND deploys is three skills that happen to be triggered together. Keep them separate. They’ll stay useful longer.

Write for your future self, not your current self. The best skills I have are the ones where I documented why something works a certain way, not just what to do. Three months later I don’t remember why the migration skill skips the index step. But if the skill says “skipping index creation here because we do it separately in prod via a zero-downtime migration pattern,” I instantly remember.

Version your skills like code. Skills are just .md files. They go in git. Review changes to them the same way you’d review changes to a config file. They’re that important.

Iterate aggressively. The skill file is the spec. When the output doesn’t match what you wanted, update the spec. This is faster than any other development loop I’ve worked with. Change the file, type the command, see the result, repeat.

---

The agent architect mindset

Here’s the mental model that changed how I use this system:

Think of Claude Code as a runtime, not an assistant. You write programs (skills) that run on this runtime. The programs can spawn sub-programs (agents). The sub-programs can produce structured outputs that feed into each other.

Most people write prompts. Power users write skills. Skill architects write systems.

The difference in practice:

Approach	What you type	What you get
Prompt	”Review this code for security issues”	One pass, one response
Skill	/security-review	Structured output, consistent format, shareable
Agent system	/release-check	Three agents in parallel, synthesized report, CI-ready

The same task — reviewing code for security issues — produces dramatically different results at each level. Not because Claude is smarter. Because the system you built is smarter.

---

The skill I actually use every day

To make this concrete — here’s a real skill I use constantly:

# pr

Prepare a pull request for the current branch.

## Steps
1. Run `git log main..HEAD --oneline` to see what's in this branch
2. Run `git diff main...HEAD --stat` to see what files changed
3. Read the changed files that aren't obvious from their names
4. Write a PR description with:
   - **What changed** (bullet points, max 5)
   - **Why** (one sentence — the motivation, not the implementation)
   - **How to test** (what to actually click or run to verify it works)
   - **Notes** (edge cases, things to watch for, things intentionally not done)
5. Print the description in a code block so it's easy to copy

Don't include "Generated with Claude" or any AI attribution in the PR.
Don't ask what the PR is for — read the git log and figure it out.

The last two lines are the important ones. They prevent the two behaviors that made me stop using earlier versions of this.

That’s the pattern for all good skills: tell Claude what to do, and tell it the one or two things it will definitely do wrong if you don’t say something.

---

Where to go from here

Skills compound. The more you build, the more you see where skills are missing, and the faster you build them.

The fastest way to build your library:

1. Every time you type something to Claude more than twice, turn it into a skill
2. Every time you get output you didn’t want, update the skill
3. Every time a project has a unique process, give it a project skill

Six months in, you’ll have 20-30 skills and an agent setup that makes your setup feel like a completely different tool than what most people are using.

That’s the 100%.