@tea-agent/loop-agent 0.1.0

package/skills/loop-agent/references/pi-subagent-assisted-mode.md

@@ -0,0 +1,83 @@
+# Pi Subagent Assisted Mode
+
+loop-agent task 启用 `piSubagentMode`、在 analyze/plan/spec/retrospective 内需要 read-only scout/planner/reviewer subagents，或配置 project-local agents/prompts 时使用本文。
+
+## Pi Subagent Assisted Mode
+
+`task.json` 支持可选字段 `piSubagentMode`，用于 step 级 `subagent` tool delegation：
+
+| Mode | analyze | plan | spec | implement | retrospective | verify |
+|------|---------|------|------|-----------|----------------|--------|
+| `off`（默认） | read only | read only | read only | +write/edit/bash | read only | read only |
+| `analyze-plan` | **+subagent** | **+subagent** | **+subagent** | 同 off | 同 off | 同 off |
+| `full` | **+subagent** | **+subagent** | **+subagent** | 同 off | **+subagent** | 同 off |
+
+### 何时启用
+
+在 `task.json` 设 `piSubagentMode: "analyze-plan"` 或 `piSubagentMode: "full"` 当：
+- task 涉及大规模 codebase 阅读，适合 parallel scout agents
+- analysis 或 planning 需多角度调查（如跨模块比较实现）
+- retrospective review 适合独立 reviewer subagent（`full` mode）
+
+### step 内使用 `subagent` 的指引
+
+subagent 可用时，**仅用于 read-only task**：
+- **Parallel scout**：dispatch 多个 subagent 同时搜索/阅读不同区域
+- **Chain**：一个 subagent scout，另一个基于发现 planning
+- **Reviewer**：用 subagent 在定稿前 review analysis/plan
+
+**不要**用 subagent 做 writing、editing 或执行命令。subagent 输出仅 advisory；务必 verify 并将发现并入自己的输出。**不要**把 subagent 结果当作权威 state 或 artifact source。
+
+### 前置条件
+
+- Pi runtime 环境须有 `subagent` tool（经 Pi subagent extension 加载）
+- 推荐用 Pi 自带 example 文件安装：
+
+```bash
+mkdir -p ~/.pi/agent/extensions/subagent ~/.pi/agent/agents ~/.pi/agent/prompts
+
+ln -sf /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/examples/extensions/subagent/index.ts ~/.pi/agent/extensions/subagent/index.ts
+ln -sf /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/examples/extensions/subagent/agents.ts ~/.pi/agent/extensions/subagent/agents.ts
+
+for f in /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/examples/extensions/subagent/agents/*.md; do
+  ln -sf "$f" ~/.pi/agent/agents/$(basename "$f")
+done
+
+for f in /usr/local/lib/node_modules/@earendil-works/pi-coding-agent/examples/extensions/subagent/prompts/*.md; do
+  ln -sf "$f" ~/.pi/agent/prompts/$(basename "$f")
+done
+```
+
+- 最小 smoke check：
+
+```bash
+pi -p --no-session --no-context-files --no-skills --tools subagent "Reply with exactly OK."
+```
+
+  预期输出：`OK`
+- mode 按 task opt-in；默认 `off` 保持向后兼容
+- 任何 mode 下 `implement` 都不给 `subagent`（防止 nested multi-writer）
+
+### 内置 Project-Local Agents 与 Prompts
+
+本 repo 提供 `.pi/agents/` 与 `.pi/prompts/` 模板，供 `piSubagentMode` 使用：
+
+**Agents**（`.pi/agents/`）
+
+| Agent | Role | Model |
+|-------|------|-------|
+| `loop-agent-scout` | Read-only recon：code、tests、docs、governance | `cursor/composer-2.5` |
+| `loop-agent-planner` | Implementation planning：最小可执行 plan | `cursor/composer-2.5` |
+| `loop-agent-reviewer` | Strict review：scope drift、verification gap、contract break | `cursor/composer-2.5` |
+| `loop-agent-worker` | General execution：bounded implementation 与 fix | `cursor/composer-2.5` |
+
+**Prompt Templates**（`.pi/prompts/`）：输入 `/loop-agent-*` 调用
+
+| Template | Flow |
+|----------|------|
+| `loop-agent-scout-and-plan` | scout → planner chain |
+| `loop-agent-analyze-wide` | 3 parallel scouts → analysis |
+| `loop-agent-review-only` | 独立 review plan/implementation/verification |
+| `loop-agent-implement-and-review` | worker → reviewer → worker loop |
+
+传 `agentScope: "both"` + `confirmProjectAgents: false` 以访问 repo-local agents。

package/skills/loop-agent/references/post-implementation-and-patterns.md

@@ -0,0 +1,44 @@
+# 实现后处理与常见模式
+
+用于 post-verify handoff、多 item PRD 处理、fast bounded task、快速 status 检查与 Pi timeout 处理。
+
+## 实现后处理
+
+DAG run、promotion、closeout 和最终验证完成后：
+1. 检查 git diff 确认预期变更
+2. 用 git commit 并 push
+3. 用户说「继续」时，跑 `status` 看 task 是否 `completed`，再创建下一个 task
+
+## 常见模式
+
+### 处理多 item PRD
+```
+1. new-task <id>-r1  → 准备 source → dag run-task → dag validate → run-dag → promote/closeout
+2. new-task <id>-r2  → 重复
+3. ...
+```
+
+### Bounded task 路径
+```
+1. new-task <id>
+2. 写 source/需求.md + source/执行约束.md
+3. dag run-task <id> --profile auto --strict-models --output <temp-dir>/<id>-dag.json
+4. dag validate --dag <temp-dir>/<id>-dag.json --strict-models --strict-governance
+5. run-dag --dag <temp-dir>/<id>-dag.json --cwd <repo-root>
+6. promote-run / closeout / final verification
+```
+
+`<temp-dir>` 表示平台原生临时目录；实际命令中使用 macOS/Windows 本机路径。
+
+**关键**：实现 work 由 DAG node 和 executor 执行；main session 负责审 DAG、审 writeSet、跑验证和 handoff。
+
+### 跨所有 task 快速 status
+```bash
+loop-agent stats
+```
+
+### 处理 pi timeout
+- 默认每 step timeout 现为 30 分钟 — 通常足够
+- pi step 仍 timeout 时，用 `stats` 看 duration 分布
+- Bash tool call 应用宽松 timeout：analyze/plan 300s，implement 480s+，verify/retrospective 240s+
+- 失败时优先读 `dag report` / `dag doctor`，再决定 repair DAG、bounded Cursor fix 或暂停

package/skills/loop-agent/references/task-workflow.md

@@ -0,0 +1,84 @@
+# Task Workflow 规则
+
+本文只保留 legacy task 目录和 source material 的读取规则。历史顺序式 `run analyze|plan|spec|implement|verify|auto|loop|continue` 工作流已经移除，不再作为 micro、fallback 或 compatibility 执行路径。
+
+## 当前执行入口
+
+所有需要可恢复、可验证、可交接的实现工作都走 DAG 路径：
+
+```bash
+loop-agent new-task <task-id> "Task Title"
+loop-agent dag run-task <task-id> --profile auto --strict-models --output <temp-dir>/<task-id>-dag.json
+loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --strict-governance
+loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd <repo-root>
+```
+
+`<temp-dir>` 表示平台原生临时目录。实际文件路径必须兼容 macOS 和 Windows；只有 repo refs、JSON/Markdown 证据 refs 和 glob 约定默认使用 `/`。
+
+当目标仓库是 loop-agent 本仓库时，`loop-agent` 命令必须来自 npm 上已发布的安装包。首次安装或有意升级可用 `@tea-agent/loop-agent@latest`，但一次自举任务启动后不要中途升级控制器，并记录 `npm list -g @tea-agent/loop-agent --depth=0` 显示的实际版本。不要用当前工作区的 `npm link` 或 `npm run dev` 控制会改动 CLI、DAG runtime、executor、package metadata 或 build output 的任务；源码开发和 focused debugging 才使用 `npm run dev -- <args>`。
+
+低风险的一行修正文档或配置时，可以由 main session 做 surgical patch，但仍必须记录 scope 并运行对应验证命令。
+
+## Source Materials
+
+`new-task` 后至少维护：
+
+```text
+.harness/tasks/<task-id>/
+  source/
+    需求.md
+    执行约束.md
+  task.json
+```
+
+- `需求.md` 写清目标、验收标准和非目标。
+- `执行约束.md` 写清允许文件、禁止改动、硬约束和验证命令。
+- 若 `docs/` 已有权威 plan/spec/PRD，应在 `需求.md` 引用或摘要，避免 task source 与 repo status source 分叉。
+
+## Task State
+
+当前 task 状态由 DAG-oriented read model 推导：
+
+- source readiness
+- DAG draft
+- latest DAG run
+- promotion
+- closeout
+- loop state
+- legacy workflow snapshot
+
+旧 `.workflow_state.json` 只能作为兼容读取输入，不是新任务 next action 或完成状态的权威来源。
+
+## Repo Adapters
+
+loop-agent 自动检测所在 repo，并按目标 repo 的 `harness.json` 与治理根目录选择验证入口。跨目录操作时显式传入目标仓库：
+
+```bash
+loop-agent --repo-root /path/to/target-repo <command>
+```
+
+## Task Config
+
+新任务不应写入旧 `flow` 字段。常用字段是：
+
+- `taskId`
+- `title`
+- `complexity`
+- `allowedPaths`
+- `forbiddenPaths`
+- `hardConstraints`
+- `verifyCommands` / adapter verification settings
+- `dagFallbackReason`，仅用于记录为何某个长期 loop 缺少 DAG round evidence
+
+## Verification
+
+完成声明必须来自新鲜验证证据。按目标 repo 的 `docs/verification-matrix.md` 选择最小证明命令；loop-agent 自身常用：
+
+```bash
+npm run typecheck
+npm test
+bash scripts/check-repo.sh
+bash scripts/ci.sh
+```
+
+Windows 上通过 Git Bash 或配置好的兼容 Bash 运行 `scripts/*.sh`；不要把 POSIX 路径假设写入 CLI、模板或 task source。

package/skills/loop-agent/references/verification-and-failure-handling.md

@@ -0,0 +1,74 @@
+# Verification 与失败处理
+
+选择 verify strategy knobs、解读 verify 结果、决定失败后是否继续，或 closeout workflow/runtime/docs/skill 变更时使用本文。
+
+## Verify strategy 与 completion audit
+
+### Verify 始终在本地跑
+`verify` step 跑确定性命令（check-repo.sh + tests + typecheck）。**不**调用 pi。因此快且可靠。
+
+### Verify strategy knobs
+需要更紧的 verify 控制时，用 task-level config：
+```json
+{
+  "verifyPreset": "auto",
+  "verifyMode": "parallel",
+  "verifyRetryCount": 0,
+  "verifyFailFast": false
+}
+```
+
+- `verifyPreset`：`auto | quick | standard | full`
+  - `auto`：`small -> quick`，`medium -> standard`，`large -> full`
+- 默认 `parallel`
+- 命令争抢共享资源时用 `serial`
+- `verifyFailFast` 仅在 `serial` mode 有意义
+- retry 保持小；用于 flaky 环境问题，不要掩盖真实失败
+
+### Verify 后的 goal completion audit
+- 有 active task goal 且 `verify` 通过时，loop-agent 跑 goal completion audit。
+- 若 `source/需求.md` 仍有未勾 checklist（`- [ ]`），task **不会**以 completed 结束。
+- 若确定性 requirement coverage audit 发现未覆盖需求，task **不会**以 completed 结束。
+- `explicitly_out_of_scope` 需求（如 `## 非目标` 下）**不算** coverage gap。
+- 独立 audit 报告用 `handoff coverage <task-id> [--json|--markdown]`。
+- task status、source/artifacts、DAG outcome、verification 记录可能 drift 时用 `dag reconcile-tasks --glob '<pattern>' [--json|--markdown]`。默认仅报告；`--patch` 不能伪造 verification evidence。
+
+### Verify 默认保存进度
+`verify` 成功后，loop-agent 默认：
+
+1. 在当前 task scope 内选文件
+2. 跑 `git add`
+3. 创建 commit 保存已验证进度
+
+默认行为：
+
+- `autoCommitAfterVerify: true`
+- commit message：`chore(task): save verified progress for <taskId>`
+
+`task.json` 可选覆盖：
+
+```json
+{
+  "autoCommitAfterVerify": false,
+  "autoCommitMessage": "docs(workflow): save verified progress"
+}
+```
+
+最佳实践：保持 `allowedPaths` 准确。auto-commit 用 task path 约束，避免把无关 dirty 文件扫进 progress commit。
+
+### 失败处理
+
+child agent 失败时：
+
+- **业务/测试失败**：让 child agent 在同一 task bounds 内修复
+- **Workflow runtime 失败**（如 `loop-agent` runtime 问题、部分 artifact 生成、输出聚合 crash）：保持 task contract，但允许 main agent 或 child agent 在同一 scoped implementation 内手动完成，仍跑 `verify`
+- **意外残留**（tmp 文件、探索性 mock、scratch 输出）：handoff 前删除
+
+### Closeout 规则
+workflow/runtime/docs/skill 变更结束时：
+```bash
+loop-agent docs audit
+loop-agent handoff check <task-id>
+```
+
+active exec plan 实质完成时，用 `docs archive` 归档并更新 active/completed 索引，勿留 stale active status。

package/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
+---
+
+# Requesting Code Review
+
+Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Use the code reviewer template** (`code-reviewer.md` in this skill directory):
+
+**Placeholders:**
+- `{DESCRIPTION}` - Brief summary of what you built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do (contract, exec plan, or requirements)
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code reviewer subagent]
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/exec-plans/active/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Harness Workflow
+
+**After each work chunk (Plan → Contract → Implement → Verify → Handoff):**
+- Review after Implement, before Verify
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Before merge / Handoff:**
+- Review before declaring complete
+- Verify against contract acceptance criteria
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md

package/skills/requesting-code-review/code-reviewer.md

@@ -0,0 +1,168 @@
+# Code Reviewer Prompt Template
+
+Use this template when dispatching a code reviewer subagent.
+
+**Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
+
+```
+Task tool (general-purpose):
+  description: "Review code changes"
+  prompt: |
+    You are a Senior Code Reviewer with expertise in software architecture,
+    design patterns, and best practices. Your job is to review completed work
+    against its plan or requirements and identify issues before they cascade.
+
+    ## What Was Implemented
+
+    {DESCRIPTION}
+
+    ## Requirements / Plan
+
+    {PLAN_OR_REQUIREMENTS}
+
+    ## Git Range to Review
+
+    **Base:** {BASE_SHA}
+    **Head:** {HEAD_SHA}
+
+    ```bash
+    git diff --stat {BASE_SHA}..{HEAD_SHA}
+    git diff {BASE_SHA}..{HEAD_SHA}
+    ```
+
+    ## What to Check
+
+    **Plan alignment:**
+    - Does the implementation match the plan / requirements?
+    - Are deviations justified improvements, or problematic departures?
+    - Is all planned functionality present?
+
+    **Code quality:**
+    - Clean separation of concerns?
+    - Proper error handling?
+    - Type safety where applicable?
+    - DRY without premature abstraction?
+    - Edge cases handled?
+
+    **Architecture:**
+    - Sound design decisions?
+    - Reasonable scalability and performance?
+    - Security concerns?
+    - Integrates cleanly with surrounding code?
+
+    **Testing:**
+    - Tests verify real behavior, not mocks?
+    - Edge cases covered?
+    - Integration tests where they matter?
+    - All tests passing?
+
+    **Production readiness:**
+    - Migration strategy if schema changed?
+    - Backward compatibility considered?
+    - Documentation complete?
+    - No obvious bugs?
+
+    ## Calibration
+
+    Categorize issues by actual severity. Not everything is Critical.
+    Acknowledge what was done well before listing issues — accurate praise
+    helps the implementer trust the rest of the feedback.
+
+    If you find significant deviations from the plan, flag them specifically
+    so the implementer can confirm whether the deviation was intentional.
+    If you find issues with the plan itself rather than the implementation,
+    say so.
+
+    ## Output Format
+
+    ### Strengths
+    [What's well done? Be specific.]
+
+    ### Issues
+
+    #### Critical (Must Fix)
+    [Bugs, security issues, data loss risks, broken functionality]
+
+    #### Important (Should Fix)
+    [Architecture problems, missing features, poor error handling, test gaps]
+
+    #### Minor (Nice to Have)
+    [Code style, optimization opportunities, documentation polish]
+
+    For each issue:
+    - File:line reference
+    - What's wrong
+    - Why it matters
+    - How to fix (if not obvious)
+
+    ### Recommendations
+    [Improvements for code quality, architecture, or process]
+
+    ### Assessment
+
+    **Ready to merge?** [Yes | No | With fixes]
+
+    **Reasoning:** [1-2 sentence technical assessment]
+
+    ## Critical Rules
+
+    **DO:**
+    - Categorize by actual severity
+    - Be specific (file:line, not vague)
+    - Explain WHY each issue matters
+    - Acknowledge strengths
+    - Give a clear verdict
+
+    **DON'T:**
+    - Say "looks good" without checking
+    - Mark nitpicks as Critical
+    - Give feedback on code you didn't actually read
+    - Be vague ("improve error handling")
+    - Avoid giving a clear verdict
+```
+
+**Placeholders:**
+- `{DESCRIPTION}` — brief summary of what was built
+- `{PLAN_OR_REQUIREMENTS}` — what it should do (plan file path, task text, or requirements)
+- `{BASE_SHA}` — starting commit
+- `{HEAD_SHA}` — ending commit
+
+**Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```

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*