mikkihugo

Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.

Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.

Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.

Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.

Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.

Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.

Use when resuming work in this repo after a pause or starting a fresh session on in-flight changes. Reconstruct the current state, open risks, relevant files, completed verification, and next actions.

Use for any repo behavior change. Purpose and consumer first, failing test before code, then component-appropriate lint, build, and evidence. Hand off to implementation waves only when the slice is too broad for one focused change.

Use when a request needs product/design exploration, unclear requirements, multiple viable approaches, UI/UX choices, or new behavior whose intent is not yet bounded.

Use when 2+ independent tasks, failures, research lanes, exploration lanes, or path-scoped investigations can run without shared state, shared files, or sequential dependency.

Use when executing a written implementation plan inline in the current session with checkpoints and verification.

Use when adding or changing a capability surface such as a public function, API, command, prompt, workflow, schema/helper, policy, or reusable instruction.

Use when implementation is complete, verification passes, and the remaining decision is how to integrate, merge, PR, clean up, or finish the branch.

Use when creating or revising docs, plans, records, PR text, handoffs, or other prose that should be sparse, direct, and low-context.

Use when changing prompt templates, AGENTS.md, CLAUDE.md, MCP/tool instructions, skills, governance docs, or any instruction surface where verbosity, duplicated doctrine, hidden exemptions, unclear provenance, or weak enforcement could affect agent behavior.

Use when making or evaluating any behavior, plan, prompt, skill, code, test, or operational change that needs purpose, proof, consumer, or falsifier clarity.