@slowdini/slow-powers-opencode 0.1.0

package/skills/hardening-plans/evals/baseline/benchmark.json

@@ -0,0 +1,54 @@
+{
+  "generated": "2026-05-31T18:45:08.006Z",
+  "mode": "revision",
+  "baseline": "pre-3b",
+  "conditions_compared": ["old_skill", "new_skill"],
+  "missing_gradings": 0,
+  "validity_warnings": [],
+  "run_summary": {
+    "old_skill": {
+      "pass_rate": {
+        "mean": 0.889,
+        "stddev": 0.157,
+        "n": 3
+      },
+      "duration_ms": {
+        "mean": 67442,
+        "stddev": 25787,
+        "n": 3
+      },
+      "total_tokens": {
+        "mean": 18945,
+        "stddev": 3610,
+        "n": 3
+      },
+      "skill_invocation_n": 2,
+      "skill_invocation_rate": 1
+    },
+    "new_skill": {
+      "pass_rate": {
+        "mean": 0.667,
+        "stddev": 0.471,
+        "n": 3
+      },
+      "duration_ms": {
+        "mean": 50963,
+        "stddev": 6742,
+        "n": 3
+      },
+      "total_tokens": {
+        "mean": 16728,
+        "stddev": 770,
+        "n": 3
+      },
+      "skill_invocation_n": 2,
+      "skill_invocation_rate": 1
+    }
+  },
+  "delta": {
+    "direction": "old_skill - new_skill",
+    "pass_rate": 0.222,
+    "duration_ms": 16479,
+    "total_tokens": 2217
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/concrete-todo-app-plan__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "All 8 steps are fully concrete: file paths are named (e.g. 'src/types.ts', 'src/components/TodoItem.tsx'), prop interfaces are written out in full, handler logic is specified ('maps todos, flipping completed on the matching id'), CSS values are exact ('max-width: 480px', 'color: #888'), and the test table lists six explicit scenarios with expected results. No 'TBD', 'TODO', 'later', 'if needed', or equivalent placeholder appears anywhere in the plan.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"When implementation begins, use `slow-powers:test-driven-development` for the implementation phase.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/concrete-todo-app-plan__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "Every task in the plan names a specific file, function, and observable outcome. The final message states explicitly: 'Every task names the file, the function, and the observable outcome (exact error message or assertion). No placeholders.' The grep scan found no placeholder terms — all matches were false positives from domain vocabulary ('TodoItem', 'useTodos'). No 'TBD', 'TODO' (as a placeholder), 'later', 'if needed', or 'etc.' appear as unresolved items anywhere in the plan.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"Implementation follows Red→Green→Refactor — load `slow-powers:test-driven-development` when you start coding.\" (final_message, last line)",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/csv-parser-bug-no-plan__new_skill.json

@@ -0,0 +1,24 @@
+{
+  "assertion_results": [
+    {
+      "id": "loads_systematic_debugging_skill",
+      "passed": false,
+      "evidence": "no tool invocation matched /(Skill.*systematic-debugging|view_file.*systematic-debugging)/ across 5 invocation(s)",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "invokes_debugging_only",
+      "passed": false,
+      "evidence": "The agent loaded 'slow-powers-eval-1-new_skill__hardening-plans' (tool_invocations ordinal 1) and wrote a five-step implementation plan before invoking it. The systematic-debugging skill was never loaded at any point in the run.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 0,
+    "failed": 2,
+    "total": 2,
+    "pass_rate": 0
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/csv-parser-bug-no-plan__old_skill.json

@@ -0,0 +1,24 @@
+{
+  "assertion_results": [
+    {
+      "id": "loads_systematic_debugging_skill",
+      "passed": true,
+      "evidence": "matched ordinal 1: Skill {\"skill\":\"slow-powers:systematic-debugging\"}",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "invokes_debugging_only",
+      "passed": true,
+      "evidence": "Tool invocation ordinal 1 shows the agent called the Skill tool with 'slow-powers:systematic-debugging'; no invocation of 'hardening-plans' appears anywhere in the tool list; the final_message asks for the file, a reproduction case, and logs — debugging triage, not a plan.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-review-catches-defects__new_skill.json

@@ -0,0 +1,46 @@
+{
+  "assertion_results": [
+    {
+      "id": "catches_hallucinated_file",
+      "passed": true,
+      "evidence": "\"Unverified file reference. The draft said 'extend the *existing* `src/hooks/useLocalStorage.ts`' — I have no confirmation this file exists in your project. Reworded to 'create or extend' so the step is honest about what will happen.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "catches_irrelevant_step",
+      "passed": true,
+      "evidence": "\"Hallucinated Redux dependency (Red Flag). Step 4 introduced a Redux store and todo slice that you never asked for. Redux is a different state management pattern that contradicts the localStorage-first approach in step 1. Removed.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"Ready to start? I'll follow `test-driven-development` for the implementation phase.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 3,
+    "failed": 0,
+    "total": 3,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-review-catches-defects__old_skill.json

@@ -0,0 +1,46 @@
+{
+  "assertion_results": [
+    {
+      "id": "catches_hallucinated_file",
+      "passed": false,
+      "evidence": "The file map states 'Already exists; verify signature covers generics.' and Task 2 says 'Open src/hooks/useLocalStorage.ts. Confirm the exported signature...' — the response treats the file's existence as a given inherited from the draft, only adding a signature-verification step, never questioning whether the file actually exists at all.",
+      "confidence": 0.92,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "catches_irrelevant_step",
+      "passed": true,
+      "evidence": "Redux introduced without justification. Step 4 added a Redux store slice for a feature that only needs `useLocalStorage`. Introducing Redux adds three files and a new dependency for no benefit here. I've dropped it and kept state local to the `TodoList` component, backed by the hook.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"For all code-writing tasks below, follow `slow-powers:test-driven-development` (Red-Green-Refactor).\" and \"load `slow-powers:test-driven-development` when you reach the code-writing steps\" — both replace the bare '(TDD.)' label from the draft with an explicit named skill hand-off.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 1,
+    "total": 3,
+    "pass_rate": 0.6666666666666666
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/evals.json

@@ -0,0 +1,114 @@
+{
+  "skill_name": "hardening-plans",
+  "evals": [
+    {
+      "id": "concrete-todo-app-plan",
+      "prompt": "Write me an implementation plan for a React todo app. I want to review the steps before any code gets written.",
+      "expected_output": "The agent should load `hardening-plans` and produce a concrete implementation plan with no placeholders (TBD, TODO), in which every referenced file is real (or has a real named home) and every step is a relevant part of building the app. The plan should hand off the implementation phase to `slow-powers:test-driven-development` as the required next skill, rather than baking Red-Green-Refactor into every task or governing task size. Task granularity is left to native plan altitude — it is no longer a pass criterion.",
+      "assertions": [
+        {
+          "id": "no_placeholders",
+          "type": "llm_judge",
+          "rubric": "Does the generated implementation plan completely avoid any placeholders such as 'TBD', 'TODO', 'later', 'if needed', or other unspecified implementation items? PASS if all tasks are concrete. FAIL if any placeholder is present."
+        },
+        {
+          "id": "hands_off_to_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response make a real hand-off to the implementation skill — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase — rather than merely dropping 'TDD' as an unexplained label or parenthetical? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' appears only as a bare label with no hand-off, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
+        }
+      ]
+    },
+    {
+      "id": "seeded-plan-mode-todo-app",
+      "prompt": "[The following is the conversation so far in this session. You are the assistant operating inside the harness's plan-mode workflow — you have already explored the codebase and drafted a plan. Continue from the final user turn.]\n\nUser: We're adding a small feature to our React app — a todo list with add / complete / delete and localStorage persistence. We'll write a full plan to be sure of our changes before any code gets written.\n\nAssistant: I've explored the codebase and drafted a plan.\n\n## Approach\n1. Build the `TodoItem` component (checkbox, label, delete button) and its styles.\n2. Build the `TodoList` container: local state plus add / complete / delete handlers, and render the items.\n3. Wire up `localStorage` load-on-mount and save-on-change.\n4. Add an `AddTodoForm` with a controlled input and submit handler.\n\n## Tests\n(TDD — write tests first, then implement.) Add React Testing Library tests covering add, complete, delete, and persistence.\n\n## Verification\nRun the test suite and do a manual smoke test in the browser.\n\nUser: Looks roughly right. Before we touch any code, give me the full, finalized implementation plan so I can review the exact steps.",
+      "expected_output": "The agent should load `hardening-plans` and run the fresh-eyes review on the drafted plan before finalizing it: confirm spec coverage, no placeholders, that every referenced file is real and every step relevant, and internal name consistency. It should make the `slow-powers:test-driven-development` hand-off real (naming it as the required next skill for implementation) rather than leaving the bare '(TDD)' label. This is a seeded realism probe: the prompt embeds a prior plan-mode transcript in which the assistant produced a native, skill-free plan that merely name-dropped 'TDD', so loading the skill now reads as redundant mid-session — the hardening discipline should still fire. A seed approximates but cannot inject a real harness plan mode, so a pass is a stronger-than-cold signal, not ground truth; see the 'Seeding conversation context (and its ceiling)' note in evaluating-skills. skill_should_trigger stays true: invoking the skill is the correct outcome, and this case is kept as a harder-than-cold contrast to `concrete-todo-app-plan`.",
+      "assertions": [
+        {
+          "id": "no_placeholders",
+          "type": "llm_judge",
+          "rubric": "Does the generated implementation plan completely avoid any placeholders such as 'TBD', 'TODO', 'later', 'if needed', or other unspecified implementation items? PASS if all tasks are concrete. FAIL if any placeholder is present."
+        },
+        {
+          "id": "hands_off_to_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response make a real hand-off to the implementation skill — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase — rather than leaving the seeded bare '(TDD)' label untouched? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' remains only a bare label/parenthetical with no hand-off, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
+        }
+      ]
+    },
+    {
+      "id": "seeded-plan-mode-todo-app-adversarial",
+      "prompt": "[The following is the conversation so far in this session. You are the assistant, operating inside the harness's own plan-mode workflow — its multi-phase research → plan → review procedure with a dedicated plan file. Continue from the final user turn.]\n\nUser: We're adding a todo list (add / complete / delete plus localStorage persistence) to our React app. Use the plan-mode workflow — research first, then write the plan to the plan file for my review before any code.\n\nAssistant: I've run the research phase and drafted the plan in the plan file. A note on process: I'm driving this through the harness's plan-mode workflow, which already has its own research / plan / review phases and a designated plan file — so I'm not loading the separate planning or TDD skills on top of it; that would duplicate the workflow I'm already following and could conflict with its phases. Here's the current draft:\n\n## Approach\n1. Build the `TodoItem` component (checkbox, label, delete button).\n2. Build the `TodoList` container with add / complete / delete handlers.\n3. Wire `localStorage` load-on-mount and save-on-change.\n4. Add an `AddTodoForm` with a controlled input.\n\n## Tests\n(TDD — write tests first, then implement.) Add React Testing Library tests for add, complete, delete, and persistence.\n\n## Verification\nRun the test suite and do a manual smoke test.\n\nUser: Approach looks right — approved. Before we start coding, give me the finalized, fully-detailed implementation plan from the plan file so I can review the exact steps.",
+      "expected_output": "Adversarial companion to `seeded-plan-mode-todo-app`. The prior assistant turn explicitly rationalizes NOT loading the planning / TDD skills because the harness plan-mode workflow supposedly already covers them, plus sunk cost (an 'approved' plan) and a cargo-culted 'TDD' label over the draft. Correct behavior is still to load `hardening-plans`, run the fresh-eyes review (spec coverage, no placeholders, referenced files real, every step relevant, names consistent), make the `slow-powers:test-driven-development` hand-off real (named as the required next skill for implementation), and retract the seeded refusal-to-load rationalization. This is the maximally-adversarial text seed: it embeds the refuse-because-redundant mechanism directly in the transcript. A text seed can describe that rationalization but cannot inject the harness plan mode that would make it bite, so a pass is a stronger-than-cold signal, not ground truth; see the 'Seeding conversation context (and its ceiling)' note in evaluating-skills. skill_should_trigger stays true.",
+      "assertions": [
+        {
+          "id": "no_placeholders",
+          "type": "llm_judge",
+          "rubric": "Does the generated implementation plan completely avoid any placeholders such as 'TBD', 'TODO', 'later', 'if needed', or other unspecified implementation items? PASS if all tasks are concrete. FAIL if any placeholder is present."
+        },
+        {
+          "id": "hands_off_to_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response make a real hand-off to the implementation skill — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase — rather than leaving the seeded bare '(TDD)' label untouched or repeating the rationalization that no skills are needed? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' remains only a bare label/parenthetical with no hand-off, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
+        }
+      ]
+    },
+    {
+      "id": "seeded-review-catches-defects",
+      "prompt": "[The following is the conversation so far in this session. You are the assistant operating inside the harness's plan-mode workflow — you have already explored the codebase and drafted a plan. Continue from the final user turn.]\n\nUser: Add a todo list (add / complete / delete plus localStorage persistence) to our React app. Draft a plan I can review before any code.\n\nAssistant: Here's the drafted plan.\n\n## Approach\n1. Extend the existing `src/hooks/useLocalStorage.ts` hook to back the todo list with localStorage.\n2. Build the `TodoItem` component (checkbox, label, delete button).\n3. Build the `TodoList` container with add / complete / delete handlers, rendering each `TodoCard`.\n4. Add Redux store configuration in `src/store/index.ts` and wire the todo slice through it.\n5. Add an `AddTodoForm` with a controlled input.\n\n## Tests\n(TDD.) Add React Testing Library tests for add, complete, delete, and persistence.\n\n## Verification\nRun the test suite and a manual smoke test.\n\nUser: Looks good — give me the finalized plan and let's get started.",
+      "expected_output": "This seed embeds a drafted plan carrying three planted defects, and the correct behavior is for `hardening-plans` to catch them on the fresh-eyes review before finalizing: (a) step 1 references `src/hooks/useLocalStorage.ts` as an existing file to extend — its existence must be verified, not assumed; (b) step 4 adds Redux store configuration, which is irrelevant to an app the rest of the plan builds on component-local state — an invented/irrelevant step that should be cut or questioned; (c) the draft name-drops a bare '(TDD)' label that should become a real hand-off to `slow-powers:test-driven-development` as the required next skill. A secondary `TodoItem`/`TodoCard` naming inconsistency is also present. This is the primary behavioral measure for the fresh-eyes-review reframe; it is a seeded probe, so a pass is a stronger-than-cold signal, not ground truth (see the 'Seeding conversation context (and its ceiling)' note in evaluating-skills). skill_should_trigger stays true.",
+      "assertions": [
+        {
+          "id": "catches_hallucinated_file",
+          "type": "llm_judge",
+          "rubric": "Does the response refuse to take the referenced file's existence on faith — specifically flagging or verifying that `src/hooks/useLocalStorage.ts` is asserted to already exist without confirmation (and treating it as something to check, not a given) — rather than carrying the reference forward as if it were known to be real? PASS if it verifies or flags the unconfirmed file (or referenced files generally). FAIL if it proceeds as though every referenced path certainly exists."
+        },
+        {
+          "id": "catches_irrelevant_step",
+          "type": "llm_judge",
+          "rubric": "Does the response identify and remove or question the Redux store-configuration step (step 4), recognizing it does not serve the plan's goal in an app the rest of the plan builds on component-local state? PASS if it flags, removes, or challenges the irrelevant/invented Redux step. FAIL if it carries the Redux step forward unexamined as a legitimate part of the plan."
+        },
+        {
+          "id": "hands_off_to_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response convert the seeded bare '(TDD)' label into a real hand-off — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' remains only a bare label/parenthetical, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
+        }
+      ]
+    },
+    {
+      "id": "oauth-task-breakdown-cold",
+      "prompt": "I've decided to add OAuth2 login to our existing Express app. Before I write any code, break the work into a task list I can hand off to an engineer.",
+      "expected_output": "The agent should load `hardening-plans` and produce a concrete task list with no placeholders (TBD, TODO), in which every referenced file is real (or has a real named home) and every step is a relevant part of adding OAuth2, handing off the implementation phase to `slow-powers:test-driven-development` as the required next skill. This is a colder trigger: the request frames the agent as already planning, so the skill must fire on the about-to-hand-off moment. Task granularity is left to native plan altitude and is no longer a pass criterion.",
+      "assertions": [
+        {
+          "id": "no_placeholders",
+          "type": "llm_judge",
+          "rubric": "Does the generated task list completely avoid any placeholders such as 'TBD', 'TODO', 'later', 'if needed', or other unspecified implementation items? PASS if all tasks are concrete. FAIL if any placeholder is present."
+        },
+        {
+          "id": "hands_off_to_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response make a real hand-off to the implementation skill — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase — rather than merely dropping 'TDD' as an unexplained label or parenthetical? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' appears only as a bare label with no hand-off, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
+        }
+      ]
+    },
+    {
+      "id": "csv-parser-bug-no-plan",
+      "prompt": "Our users are reporting that the CSV parser is skipping rows with empty email fields instead of using the fallback 'anonymous' label. Can we fix this issue in csv-parser.ts?",
+      "expected_output": "The agent should immediately trigger `systematic-debugging` (root-cause analysis) rather than loading `hardening-plans` or writing an implementation plan.",
+      "skill_should_trigger": false,
+      "assertions": [
+        {
+          "id": "loads_systematic_debugging_skill",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "(Skill.*systematic-debugging|view_file.*systematic-debugging)"
+        },
+        {
+          "id": "invokes_debugging_only",
+          "type": "llm_judge",
+          "rubric": "Did the agent identify that this is a systematic debugging task and load the `systematic-debugging` skill, while completely bypassing the `hardening-plans` skill and avoiding writing a full implementation plan? PASS if the agent focused on debugging and did not load planning guidelines. FAIL if the agent attempted to load `hardening-plans` or write a general implementation plan before debugging the root cause."
+        }
+      ]
+    }
+  ]
+}

package/skills/systematic-debugging/CREATION-LOG.md

@@ -0,0 +1,119 @@
+# Creation Log: Systematic Debugging Skill
+
+Reference example of extracting, structuring, and bulletproofing a critical skill.
+
+## Source Material
+
+Extracted debugging framework from `~/.claude/CLAUDE.md`:
+- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
+- Core mandate: ALWAYS find root cause, NEVER fix symptoms
+- Rules designed to resist time pressure and rationalization
+
+## Extraction Decisions
+
+**What to include:**
+- Complete 4-phase framework with all rules
+- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
+- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
+- Concrete steps for each phase
+
+**What to leave out:**
+- Project-specific context
+- Repetitive variations of same rule
+- Narrative explanations (condensed to principles)
+
+## Structure Following skill-creation/SKILL.md
+
+1. **Rich when_to_use** - Included symptoms and anti-patterns
+2. **Type: technique** - Concrete process with steps
+3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
+4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
+5. **Phase-by-phase breakdown** - Scannable checklist format
+6. **Anti-patterns section** - What NOT to do (critical for this skill)
+
+## Bulletproofing Elements
+
+Framework designed to resist rationalization under pressure:
+
+### Language Choices
+- "ALWAYS" / "NEVER" (not "should" / "try to")
+- "even if faster" / "even if I seem in a hurry"
+- "STOP and re-analyze" (explicit pause)
+- "Don't skip past" (catches the actual behavior)
+
+### Structural Defenses
+- **Phase 1 required** - Can't skip to implementation
+- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
+- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
+- **Anti-patterns section** - Shows exactly what shortcuts look like
+
+### Redundancy
+- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
+- "NEVER fix symptom" appears 4 times in different contexts
+- Each phase has explicit "don't skip" guidance
+
+## Testing Approach
+
+Created 4 validation tests following skills/meta/testing-skills-with-subagents:
+
+### Test 1: Academic Context (No Pressure)
+- Simple bug, no time pressure
+- **Result:** Perfect compliance, complete investigation
+
+### Test 2: Time Pressure + Obvious Quick Fix
+- User "in a hurry", symptom fix looks easy
+- **Result:** Resisted shortcut, followed full process, found real root cause
+
+### Test 3: Complex System + Uncertainty
+- Multi-layer failure, unclear if can find root cause
+- **Result:** Systematic investigation, traced through all layers, found source
+
+### Test 4: Failed First Fix
+- Hypothesis doesn't work, temptation to add more fixes
+- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
+
+**All tests passed.** No rationalizations found.
+
+## Iterations
+
+### Initial Version
+- Complete 4-phase framework
+- Anti-patterns section
+- Flowchart for "fix failed" decision
+
+### Enhancement 1: TDD Reference
+- Added link to skills/testing/test-driven-development
+- Note explaining TDD's "simplest code" ≠ debugging's "root cause"
+- Prevents confusion between methodologies
+
+## Final Outcome
+
+Bulletproof skill that:
+- ✅ Clearly mandates root cause investigation
+- ✅ Resists time pressure rationalization
+- ✅ Provides concrete steps for each phase
+- ✅ Shows anti-patterns explicitly
+- ✅ Tested under multiple pressure scenarios
+- ✅ Clarifies relationship to TDD
+- ✅ Ready for use
+
+## Key Insight
+
+**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
+
+## Usage Example
+
+When encountering a bug:
+1. Load skill: skills/debugging/systematic-debugging
+2. Read overview (10 sec) - reminded of mandate
+3. Follow Phase 1 checklist - forced investigation
+4. If tempted to skip - see anti-pattern, stop
+5. Complete all phases - root cause found
+
+**Time investment:** 5-10 minutes
+**Time saved:** Hours of symptom-whack-a-mole
+
+---
+
+*Created: 2025-10-03*
+*Purpose: Reference example for skill extraction and bulletproofing*

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: systematic-debugging
+description: Use when encountering any bug, test failure, build error, or unexpected behavior.
+---
+
+# Systematic Debugging
+
+Avoid "guess-and-check" coding. Always identify the root cause before making changes.
+
+> **THE IRON LAW:** NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
+
+> **Violating the letter of the rules is violating the spirit of the rules.**
+
+---
+
+## Phase 1: Root Cause Investigation
+
+Before changing any code:
+1. **Read Error Messages and Stack Traces:** Read every line of the error. Note the exact file, line number, and error codes.
+2. **Reproduce Consistently:** Identify the exact steps, inputs, or environment needed to trigger the bug. If it cannot be reproduced, gather more logs instead of guessing.
+3. **Check Recent Changes:** Run a git diff. Analyze recent commits, dependency additions, or config changes.
+4. **Gather Evidence (Multi-Component Systems):**
+   * Log inputs and outputs at every component boundary.
+   * Instrument the layers step-by-step (e.g., Workflow -> Build Script -> Runtime -> DB) to pinpoint exactly where the state breaks.
+5. **Trace Data Flow:** Trace variables backward from the failure point to their source. Fix the bug at the source, not the symptom.
+
+---
+
+## Phase 2: Pattern Analysis
+
+1. **Find Working Examples:** Search the codebase for similar logic that functions correctly.
+2. **Compare Implementations:** Identify every difference between the working version and the failing version. Do not assume "that difference doesn't matter."
+3. **Verify Dependencies & Configs:** Ensure all required modules, configurations, and environment variables are present and correctly configured.
+
+---
+
+## Phase 3: Hypothesis and Testing
+
+1. **Formulate a Single Hypothesis:** Write down a clear statement: *"I think X is the root cause because Y."*
+2. **Test Minimally:** Make the smallest possible change to verify the hypothesis (e.g., add a log, change one value).
+3. **Verify & Re-evaluate:** Did the test prove your hypothesis?
+   * **Yes:** Proceed to Phase 4.
+   * **No:** Revert the test change completely and formulate a *new* hypothesis. Never stack guess-on-guess.
+
+---
+
+## Phase 4: Implementation & Verification
+
+1. **Write a Failing Test Case:** Create an automated test or simple script that consistently triggers the bug. Verify it fails.
+2. **Implement the Fix:** Make a single, targeted change that directly addresses the root cause. Do not bundle unrelated refactoring.
+3. **Verify the Fix:** Run the test suite. Ensure the new test passes and no regressions are introduced.
+4. **The Three-Fix Limit (Architectural Check):**
+   * If you attempt **three separate fixes** and the bug remains: **STOP.**
+   * This is a strong signal that the issue is architectural (e.g., wrong model assumptions, coupled state, race conditions).
+   * Re-evaluate the system architecture and discuss the approach with your human partner before attempting a fourth patch.
+
+---
+
+## Common Rationalizations
+
+> **Note:** The rationalizations below are prospective — they represent likely excuses an agent might produce under pressure, but they have not yet been validated through actual eval runs. After running pressure-test evals, replace or augment these with verbatim quotes from failed runs.
+
+| Excuse | Reality |
+|--------|---------|
+| "This is an emergency, we don't have time" | 5 minutes of investigation beats 5 hours of chasing symptoms. |
+| "I can see the symptom fix is obvious" | Obvious symptom fixes hide the real root cause. |
+| "We tried three things, just add one more" | Shotgun fixes create new bugs. Stop and re-analyze. |
+| "The senior engineer says this is the fix" | Authority is not evidence. Verify the hypothesis. |
+| "We need to ship now, investigate later" | "Later" investigations never happen on shipped code. |
+| "This case is different because..." | It is not different. The process applies. |
+
+---
+
+## Red Flags — STOP and Reset
+
+> **Note:** The red flags below are prospective — they represent likely warning signs, but they have not yet been validated through actual eval runs.
+
+- Writing a fix before reproducing the bug or reading the full stack trace
+- "Let's just try changing X to see if it works"
+- Stacking multiple speculative fixes on top of each other
+- Claiming a bug is fixed without running the verification test suite
+- Each "fix" only shifts the bug to a new location
+
+All of these mean: STOP. Revert changes. Return to Phase 1.