Skills, Agents, Commands: turning a pile of prompts into a toolkit

TL;DR

• I reorganised my Claude Toolkit into three clear layers: skills (knowledge), agents (roles), commands (entry points).
• Added four agents to close full SDLC role coverage — DBA, project manager, API engineer, pentester — bringing the roster to 20.
• The bigger lesson: before you open-source your tooling, generalise it — strip names, private product details, and machine paths so it teaches the method, not your setup.

The problem: a pile of prompts

If you use Claude Code long enough, you end up with a graveyard of prompts. A “review my PR” prompt here, a “write Pest tests” prompt there, a giant system message you paste when you want a DBA brain. It works, but it doesn’t compose. You can’t hand it to a teammate. You can’t reason about coverage.

So I gave the mess a shape. Three layers, each with one job.

Layer What it is When it fires Skill Knowledge + method (the how) On a trigger phrase or /name, loaded on demand Agent A role persona (the who) Delegated to; loads the skills it needs as its playbook Command A workflow entry point (the do it now) Invoked as a slash command

The mental model: a skill is a reference manual, an agent is the specialist who reads that manual, and a command is the button that kicks off the job.

Agents as thin role definitions

The nice thing about splitting knowledge out into skills is that an agent becomes tiny. It’s mostly a description plus “load these skills first.” Here’s the actual header of the code-reviewer agent:

---
name: code-reviewer
description: Use this agent to review code changes... checks Kickoff
  conventions, design patterns, code smells, PSR-12, test coverage.
  Read-only — it reports findings, never edits.
tools: Read, Grep, Glob, Bash, Skill
---
...
1. Load the relevant skills before reviewing: `php-best-practices`,
   `design-patterns`, `code-quality`. For Livewire/Flux also `livewire-flux`.

Enter fullscreen mode Exit fullscreen mode

The agent doesn’t carry the review rules — it points at the skills that do. Update the skill once, every agent that loads it gets smarter. That’s the whole payoff of the split.

This pass I added four agents to finish SDLC coverage:

Agent Owns database-engineer schema, migrations, indexing, backups, tenant isolation project-manager roadmaps, milestones, sprints, risk/scope api-engineer REST design & build penetration-tester authorized offensive testing — scoped, local/staging only

Roster’s at 20 now. The point isn’t the number — it’s that I can now look at a coverage map and see which SDLC role has no home.

The real lesson: generalise before you share

Here’s the part worth stealing. The toolkit started life full of my stuff — my name, private product names, machine-specific paths baked into agents and docs. Fine for a personal repo. Not fine for something public.

Making it shareable wasn’t about adding features. It was subtraction:

Before After Personal name + email in manifests Org author, no personal email Private product/ticketing specifics Generic “Kickoff-based Laravel app” Machine-specific absolute paths Illustrative, portable paths

What I deliberately kept was the Kickoff baseline — the Livewire 4 + Flux + Pest + Pint + PHPStan conventions. That’s the toolkit’s actual value; stripping it would leave an empty shell. Generalising means removing what identifies you, not what makes the thing useful.

Good test before you publish any tooling: could a stranger clone this and have it teach them the method, without learning a single thing about your clients or your laptop? If not, keep subtracting.

What’s next

Now that roles are covered, the interesting work is chaining them — a software-architect handing a design to a laravel-developer, then a code-reviewer and qa-engineer fanning out in parallel. Composition is where this stops being a folder of files and starts being a team.

Repo’s here if you want to poke at it: github.com/nasrulhazim/claude.