Agents

8 sub-agents, one job each.

Each agent works in its own context and comes back with a report, so your main conversation stays clean. Seven of them only read and run things; the code-simplifier is the one that edits. The feature and ship skills call them at the right step, or you can ask for one by name.

§01 · Where they fit

Before, after and around the code.

Before coding. code-explorer maps how the existing code works, and code-architect turns that into a blueprint you approve.
After it works. verifier runs the real checks and reports evidence, and code-simplifier cleans up only what this task changed.
Review. test-analyzer, silent-failure-hunter, security-reviewer and the optional frontend-reviewer each look at one kind of problem.

§02 · The agents

What each one does.

Each agent is written once and rendered into each tool’s own format, with read-only agents marked using the tool’s documented field.

`verifier`

A strict QA subagent that runs the real checks and reports evidence.

What it does: An agent that finds your project's format, lint, type-check, test and build commands, runs them, exercises the changed behavior, and reports PASS/FAIL with the actual output. It reads and runs things but does not edit code.
When it’s used: Before the agent says a task is done. /verify-change and /feature use it automatically.
Example: Use the verifier subagent to check this change.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`code-simplifier`

Cleans up working code without changing what it does.

What it does: An agent that goes over only the code changed in the current task. It removes dead code, duplication, needless abstraction and narration comments, then re-runs the checks.
When it’s used: After an implementation works and before review. /feature uses it (Claude Code's built-in /simplify is an alternative).
Example: Run the code-simplifier on what we just built.
Access: Edits code
Preset: Recommended and Everything

`security-reviewer`

A read-only security audit of the current change.

What it does: An agent that checks the diff for leaked secrets, injection, XSS, missing auth checks, path traversal, unsafe dependencies and similar issues, and reports only concrete findings.
When it’s used: For changes that touch auth, user input, APIs, files, secrets, payments or dependencies. /feature and /ship call it when relevant.
Example: Have the security-reviewer look at this diff.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`code-explorer`

Maps how existing code works before anything is changed.

What it does: A read-only agent that traces an area of the codebase end to end (entry points, data flow, key files, patterns to reuse) and reports back with file:line references, so the main conversation's context stays clean.
When it’s used: At the start of a feature or change in unfamiliar code. /feature runs it first.
Example: Use the code-explorer subagent to map how checkout works.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`code-architect`

Designs how a change should fit the codebase, before code is written.

What it does: A read-only agent that turns the task and the explorer's findings into one implementation blueprint: files to touch, interfaces, data flow, test plan, and build order in small verifiable slices. It recommends the simplest design that reuses existing patterns.
When it’s used: After exploring and before building anything beyond a trivial change. /feature uses it to draft the plan you approve.
Example: Have the code-architect design the CSV export.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`silent-failure-hunter`

Finds errors that get swallowed or hidden in the change.

What it does: A read-only reviewer that looks for empty catches, ignored error codes, unawaited promises, and fallbacks that make a failure look like success, and reports each with a concrete fix.
When it’s used: When reviewing changes with error handling, I/O, network, parsing, or async code. /feature and /ship call it when relevant.
Example: Run the silent-failure-hunter on this diff.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`test-analyzer`

Checks that the tests really prove the change works.

What it does: A read-only reviewer that maps every changed behavior to the tests that cover it, flags missing edge cases and error paths, and catches skipped, weakened or flaky tests.
When it’s used: Before declaring a change done or opening a PR. /feature and /ship call it on every change.
Example: Have the test-analyzer check coverage for this change.
Access: Read-only: it reports, it doesn’t edit
Preset: Recommended and Everything

`frontend-reviewer`

Reviews UI changes: design system, accessibility, states, responsiveness.

What it does: A read-only reviewer for UI changes. It checks the change follows the project's DESIGN.md or existing components, handles loading/empty/error states, is accessible and responsive, and doesn't hurt performance. With browser tools it also looks at the real screens.
When it’s used: When a change touches components, pages, styles, or client-side code. Pre-selected when the installer detects a frontend stack.
Example: Have the frontend-reviewer check the new settings page.
Access: Read-only: it reports, it doesn’t edit
Preset: Everything (opt-in)

§03 · Tools without sub-agents

The same review, done in place.

Some tools have no file-based sub-agents. For them, every agent’s instructions are installed in .agent-kit/agents/, and when a skill says “use the verifier agent”, the tool reads that file and does the work itself in a separate pass. Which tools work this way.