samjwillis97

Use when starting a new feature, design change, or architecture decision. Explores approaches and tradeoffs before planning or coding. NEVER skip this for non-trivial work.

Use when executing an implementation plan. Each step is delegated to a fresh subagent for isolated context, then reviewed before proceeding. Do NOT execute plans inline — use subagents.

Use when implementation is complete and you need to decide how to integrate the work - guides completion by presenting structured options for merge, PR, or cleanup

Use when creating implementation plans. Breaks work into small, verifiable steps with exact file paths and verification commands. Use after brainstorming approval.

Use when you receive code review feedback (from a reviewer subagent, /review command, or human). Guides proper processing of feedback without dismissing or cherry-picking.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing features or fixing bugs to determine whether tests should be written. Context-aware - scouts existing test infrastructure before deciding. Not all code needs tests.

Use before claiming any work is complete. Ensures actual verification evidence exists - tests run, builds pass, behavior confirmed. No hedging.

Use when authoring or updating HttpCraft YAML configs, including requests, chains, profiles, and variable structures.

Use when executing HttpCraft from terminal against an existing config, including command discovery, request execution, and runtime flag selection.

Use when navigating between repositories, switching or creating branches, cloning repositories into the local workspace tree, finding local workspaces, reading code in other repos, or researching across multiple codebases. Also use when the user references repos by owner/repo/branch patterns.