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

TL;DR I restructured my Claude Toolkit into three distinct layers: skills, agents, and commands. Expanded the roster to 20 agents, covering the full SDLC role coverage with additions for DBA, project manager, API engineer, and pentester. Generalised the toolkit by stripping away personal names, private product details, and machine-specific paths to make it a generic instructional tool rather than a personalized setup.

The challenge: a growing mound of prompts. As you use Claude Code extensively, you accumulate prompts that don't compose well. It's difficult to hand the toolkit to a teammate or analyze its coverage. To address this, I organized the prompts into three layers, each with a specific function. Layer One represents the skills, which contain knowledge and methods.

Layer Two consists of agents, who are role personas that utilize the skills when triggered by a phrase or /name. Layer Three is the commands, which serve as workflow entry points to initiate tasks.

The agent's primary role is to act as a thin role definition, containing only a description and a list of skills to load before performing a task. Here's an example of a code-reviewer agent's header:

```yaml

name: code-reviewer

description: Use this agent to review code changes...

checks: Kickoff conventions, design patterns, code smells, PSR-12, test coverage.

read-only: true

tools: Read, Grep, Glob, Bash, Skill

```

Before loading relevant skills, such as `php-best-practices`, `design-patterns`, `code-quality`, and `livewire-flux`, the agent reports findings without altering anything. Each agent points to the appropriate skills, ensuring that updates to skills automatically improve all agents utilizing them.

In this update, I added four agents to complete the coverage of the software development lifecycle: database-engineer, project-manager, api-engineer, and pentester. The total agent count is now 20.

The main lesson is to generalise your tooling before sharing it. Initially, the toolkit was filled with personal information, such as names, private product specifics, and machine paths. This approach worked for a private repository but not for a public one. To make it shareable, I removed these identifying elements and focused on the core method.

The toolkit retains the Kickoff baseline – the conventions for Livewire 4, Flux, Pest, Pint, and PHPStan – which is the actual value of the toolkit. Stripping away these identifiers leaves a useful, generic framework. Before publishing any tooling, ask yourself if a stranger could clone the repository and learn the method without any knowledge of your clients or personal setup. If the answer is no, keep refining the toolkit.

The next step is to explore chaining agents – having a software architect hand off designs to a Laravel developer, followed by a code-reviewer and QA engineer working in parallel. This approach transforms a collection of files into a cohesive team. The repository containing the updated toolkit is available here: [github.com/nasrulhazim/claude](https://github.com/nasrulhazim/claude).