Dev Workflow

25-point code quality checklist covering structure, errors, security, performance, and testing. Use before commits or when reviewing code.

Compact the current conversation into a handoff document so a fresh agent can pick up the work.

Relentless round-based interview that stress-tests a plan before building. Maps the plan as a design tree and works it in rounds, asking every unblocked question at once with a recommended answer for each, until nothing is left silently assumed.

Build a throwaway prototype to answer a design question. Use when sanity-checking whether a state model or logic feels right, or exploring what a UI should look like, before committing the decision to real code.

Rewrite engineer-to-engineer content for leadership audiences — VPs, directors, PMs, release managers. Shapes for the channel: JIRA comment, Slack post, standup note, email, or meeting talking-points. Use after post-mortem or any technical update that needs to flow up the org.

Outsider-perspective deep review of a plan, PR, design doc, or code change — questions intent first (should this exist?), then traces the actual code path end-to-end to verify the change does what it claims. Use for serious PR reviews, design audits, or second opinions. Lighter pre-commit checks use `review` instead.

Research a question against high-trust primary sources and capture the findings as a cited Markdown file. Use when a topic needs researching, docs or API facts gathered, or reading legwork delegated to a background agent.

Write the canonical engineering record of a fixed bug — root cause, mechanism, fix, validation, and how it slipped through. Use after a debug session lands a validated fix, before closing the bug.

Create and edit Claude Code skills with TDD methodology. Use when creating or editing skills. Test with subagents before deployment, iterate until bulletproof.

Review feature spec files with 3 focused agents — spec quality (business+correctness+ambiguity), completeness (missing scenarios+safety+testability), and buildability (compatibility+blockers+traceability). Sequential by default.

Smart git operations — commit messages, branch management, PR creation with summaries. Use for any git workflow.

Use when facing 2+ independent problems (different test files, unrelated bugs, separate subsystems) that can be investigated in parallel without shared state — covers the dispatch decision, the actual Claude Code parallelism mechanism, prompt construction, and integration after agents return

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

Collaborative refinement of rough ideas into clear requirements/designs through systematic questioning. Use when requirements are vague or exploring architectural options.

Shared vocabulary for designing deep modules — module, interface, depth, seam, adapter. Use when designing or improving a module's interface, deciding where a seam goes, hunting for deepening opportunities, or making code more testable.

Build and sharpen a project's domain model — challenge terms, resolve them into a glossary, and record hard-to-reverse decisions as ADRs. Use when codebase terminology is fuzzy or contested, when writing or editing a glossary, or when recording an architectural decision.

OWASP Top 10 vulnerability detection. Use PROACTIVELY for code handling user input, auth, APIs, payments, or sensitive data.

Systematic debugging framework — opens every session by reciting the 4-mantra block (reproduce, trace the fail path, falsify the hypothesis, cross-reference breadcrumbs), then applies multi-layer investigation. Use when diagnosing bugs, flaky tests, unknown failures, or cross-component issues.

Plan new features using spec-driven workflow — auto-picks Quick (single plan.md) or Full (3-file EARS spec) mode. Use when creating features, writing requirements, or designing architecture.

Use when about to claim work is complete, fixed, passing, or ready to commit/PR — requires running verification commands and reading fresh output before any success claim. Evidence before assertions, always.

Strict RED-GREEN-REFACTOR enforcement with no exceptions. Use when implementing features or fixing bugs. No production code without a failing test first.

Execute spec-driven implementation — auto-detects Quick (plan.md) or Full (tasks.md) mode and runs step-by-step with verification. Use when implementing a planned feature or running TDD tasks.