claudikins-kernel

Execute validated plans with isolated agents and two-stage review

Iterative planning with human checkpoints at every phase

Final shipping gate. PR creation, documentation updates, and merge with human approval.

Post-execution verification gate. Tests, lint, type-check, then see it working.

---

Output verification agent for /claudikins-kernel:verify command. SEES code working by running apps, curling endpoints, capturing screenshots, and executing CLI commands. This is the feedback loop that makes Claude's code actually work. Use this agent during /claudikins-kernel:verify Phase 2 to gather evidence that code works. The agent detects project type, chooses appropriate verification method, captures evidence, and reports structured results. <example> Context: Web app implementation complete, need to verify it renders correctly user: "Verify the login page renders and works" assistant: "I'll spawn catastrophiser to start the dev server, screenshot the login page, and test the flow" <commentary> Web verification. catastrophiser starts server, uses Playwright for screenshots, checks console for errors. </commentary> </example> <example> Context: API endpoints implemented, need to verify responses user: "Check if the auth endpoints work correctly" assistant: "Spawning catastrophiser to curl the auth endpoints and verify response shapes" <commentary> API verification. catastrophiser curls each endpoint, checks status codes, validates response bodies. </commentary> </example> <example> Context: CLI tool implemented, need to verify it runs user: "Make sure the CLI works as expected" assistant: "Spawning catastrophiser to run the CLI commands and capture output" <commentary> CLI verification. catastrophiser runs commands with various inputs, checks exit codes and stdout. </commentary> </example>

Code quality reviewer for /claudikins-kernel:execute command. Reviews code quality, patterns, and maintainability. This is stage 2 of two-stage review - it checks quality, NOT compliance (spec-reviewer handles that). Use this agent after spec-reviewer passes. The agent receives the implementation diff and reviews for quality issues, using confidence scoring to filter noise. <example> Context: Reviewing code quality after spec-reviewer passed user: "Code review task 3 implementation" assistant: "I'll use code-reviewer to assess the code quality and maintainability" <commentary> Second stage of review. code-reviewer uses opus for judgement calls about quality, not mechanical spec checking. </commentary> </example> <example> Context: Implementation passed spec but seems complex user: "The auth middleware passed spec review but looks complicated" assistant: "code-reviewer will evaluate the implementation for unnecessary complexity" <commentary> Quality assessment. Code might meet spec but be overly complex or hard to maintain. </commentary> </example> <example> Context: Checking for security issues in new endpoint user: "Review task 5 for security concerns" assistant: "code-reviewer will check for security vulnerabilities and proper error handling" <commentary> Security review. Even if spec is met, code might have injection vulnerabilities or other issues. </commentary> </example>

Merge conflict resolution agent for /claudikins-kernel:execute command. Analyses git merge conflicts and proposes resolutions. Read-only analysis with proposed patches - does not apply changes directly. Use this agent when merge conflicts are detected during batch merge phase. The agent examines both sides of the conflict, understands intent, and proposes a resolution for human approval. <example> Context: Merge conflict detected during batch merge user: "Conflict in src/services/user.ts during merge" assistant: "I'll use conflict-resolver to analyse the conflict and propose a resolution" <commentary> Merge phase conflict. Agent reads both versions, understands the changes, proposes unified resolution. </commentary> </example> <example> Context: Multiple files have conflicts user: "3 files have merge conflicts after batch 2" assistant: "conflict-resolver will analyse each conflict and propose resolutions" <commentary> Multiple conflicts. Agent handles each file, provides per-file resolution proposals. </commentary> </example> <example> Context: Semantic conflict where both changes are needed user: "Both branches added different functions to the same file" assistant: "conflict-resolver will determine how to combine both additions correctly" <commentary> Additive conflict. Both sides added code - agent proposes keeping both in logical order. </commentary> </example>

Code simplification agent for /claudikins-kernel:verify command. Performs an optional polish pass after verification succeeds. Simplifies code without changing behaviour - tests must still pass after each change. Use this agent during /claudikins-kernel:verify Phase 3 (optional) to clean up implementation. The agent identifies simplification opportunities, makes changes one at a time, verifies tests still pass, and reverts if they don't. <example> Context: Verification passed, code is functional but complex user: "The code works but could be cleaner, run a polish pass" assistant: "I'll spawn cynic to simplify the implementation while preserving behaviour" <commentary> Polish pass. cynic identifies unnecessary abstraction, inlines helpers, improves naming - all while keeping tests green. </commentary> </example> <example> Context: Implementation has dead code and unclear naming user: "Clean up the auth module before we ship" assistant: "Spawning cynic to remove dead code and improve clarity" <commentary> Cleanup task. cynic removes unused functions, renames unclear variables, flattens nesting. </commentary> </example> <example> Context: Code works but has over-engineered abstractions user: "This is way too complicated for what it does" assistant: "Spawning cynic to inline unnecessary abstractions" <commentary> Simplification. cynic inlines single-use helpers, removes wrapper classes, reduces indirection. </commentary> </example>

Use when running claudikins-kernel:outline, brainstorming implementation approaches, gathering requirements iteratively, structuring complex technical plans, or facing analysis paralysis with too many options — provides iterative human-in-the-loop planning with explicit checkpoints and trade-off presentation

Use when running claudikins-kernel:execute, decomposing plans into tasks, setting up two-stage review, deciding batch sizes, or handling stuck agents — enforces isolation, verification, and human checkpoints; prevents runaway parallelization and context death

Use when running claudikins-kernel:ship, preparing PRs, writing changelogs, deciding merge strategy, or handling CI failures — enforces GRFP-style iterative approval, code integrity validation, and human-gated merges

Use when running claudikins-kernel:verify, checking implementation quality, deciding pass/fail verdicts, or enforcing cross-command gates — requires actual evidence of code working, not just passing tests

20 hooks across 8 events