recursive-debugging
recursive-debugging (Phase 1.5)
Overview
When a requirement involves fixing a bug or investigating unexpected behavior, ad-hoc fixes waste time and create new bugs. Systematic debugging finds the root cause before any fix is attempted.
Core Principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
The Iron Law for recursive-mode debugging:
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
Trigger examples
Tests are failing after the last change; debug itFix crash on empty inputInvestigate why the API returns wrong dataDo a root cause analysis before making changes
More from try-works/recursive-mode
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.
76recursive-tdd
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".
47recursive-subagent
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.
46recursive-worktree
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.
46recursive-review-bundle
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.
46recursive-spec
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.
37