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`.

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.