recursive-mode

Repository workflow orchestration skill for staged implementation, locked artifacts, late-phase receipts, and durable memory maintenance. Use when executing recursive-mode runs, resuming a run, locking a phase, or verifying locks.

Use when recursive-mode needs to route delegated audit, review, or bounded implementation work through external transports, CLIs, and models while preserving controller verification and fallback behavior.

Use after completed recursive-mode runs accumulate to extract durable experiential memory into `/.recursive/memory/`, then load it for later runs through the canonical loader.

Use when recursive-mode work may benefit from delegated audit, review, or bounded implementation support. This skill prioritizes analyst, planner, code-reviewer, memory-auditor, tester, and implementer roles, with mandatory self-audit fallback when subagents are unavailable.

Use when starting any recursive-mode requirement to set up an isolated git worktree. Required before implementation phases: create an isolated workspace, verify a clean baseline, and keep main/master clean.

Use when a recursive-mode requirement involves debugging a bug, test failure, or unexpected behavior. Insert Phase 1.5 between Phase 1 and Phase 2 to perform systematic root cause analysis before attempting any fixes. Trigger phrases: "debug", "investigate", "failing tests", "crash", "root cause".

Use when recursive-mode work needs a canonical delegated-review or audit handoff. Generates reproducible review bundles for Phase 3.5 code review, test review, or other delegated checks using the repo review-bundle scripts.

Approval-gated, repo-aware requirements/spec authoring for new recursive-mode runs. Use when the user wants help creating a plan, spec, scope, or requirements for work that does not yet have a run, especially prompts like "create a plan", "help me plan", "create a spec", "write requirements", or similar derivatives.

Use when implementing any code in recursive-mode Phase 3. Enforces strict RED-GREEN-REFACTOR discipline with The Iron Law - no production code without a failing test first. Trigger phrases: "implement this", "add feature", "fix bug", "write a failing test", "TDD".