القائمة
Review what happened during implementation, visualize friction patterns, and reshape your harness — fix issues, adopt concepts, generate new skills. The reflection half of the harness loop.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Phase skill: fetch Linear ticket or parse task description into structured context
Phase skill: post-merge cleanup — merge the approved PR, verify Railway deploy, finalize Linear status, remove worktree
Universal state machine driver — reads state file, dispatches to phase skills, loops until workflow complete
Phase skill: TDD implementation — write tests first, then make them pass
Phase skill: create an implementation plan with TDD test strategy
Phase skill: run all quality checks — typecheck, tests, lint, format
| name | harness-retro |
| description | Review what happened during implementation, visualize friction patterns, and reshape your harness — fix issues, adopt concepts, generate new skills. The reflection half of the harness loop. |
| user-invocable | true |
Review real work, see where friction occurred, and reshape your harness. Fix harness issues, adopt new concepts when the evidence is clear, and generate codebase-specific skills.
Invoke with: /harness-retro
This is the reflection half of the harness loop:
/harness-setup (shape) → use generated skills (real work) → /harness-retro (reflect) → /harness-setup ...
Read from .harness/:
.harness/conversations/ — all conversation files from recent implementations. Extract: phase progress, decisions, discoveries, verification evidence, harness issues, metrics. Classify friction by phase — which phase skill was active when the issue occurred.HARNESS.md — current workflow, adopted concepts, generated skills..harness/retros/ — past retro results. Check: were previous findings addressed? Are issues recurring?If .harness/conversations/ is empty or sparse, note this — the retro is limited to git history and PR comments. Suggest that recording be added to the phase skills.
If enough conversation files exist (5+), look for patterns across rounds:
This cross-round analysis is what drives structural workflow changes (not just fixing individual issues). After 10+ implementations, prompt: "You have enough data for a big-picture analysis. Want to look at patterns across all rounds?"
Classify each finding:
| Category | Description | Action |
|---|---|---|
| Harness bug | Skill instruction is wrong/outdated/missing | Propose specific edit |
| Harness gap | Scenario the skill doesn't cover | Propose new section/step |
| Repeated issue | Known issue that happened again | Escalate — fix didn't work |
| Process improvement | Pattern that worked well | Propose codifying it |
| Not actionable | One-off, external dependency | Note for context |
Distinguish these during analysis:
When recording harness issues in conversation files, use this format:
### [Phase name] Brief title
- What happened: [attempt and failure]
- Root cause: [why skill was wrong]
- Workaround: [what you did instead]
- Suggested fix: [specific edit to phase skill]
- Turns wasted: [count]
For each finding:
### Finding N: [Brief title]
**Category:** harness bug | harness gap | repeated issue | process improvement | not actionable
**Phase:** [Which phase skill this occurred in — read from state file lifecycle[].skill]
**Evidence:** [What happened — be specific]
**Impact:** [Turns wasted / human interventions / quality degradation]
**Proposed fix:** [Exact phase skill file + section + change]
Phase-level classification makes fixes precise — "harness-verify step 3 should run coverage before E2E" instead of "step 14 in /implement should..."
Present the friction analysis in the terminal.
Show the state machine progression through phases with annotations from this round:
If multiple implementations happened, compare them to reveal cross-round phase patterns.
Map friction to the workflow:
Ask: "Does this match your experience? Anything I missed?" Wait for the user's response before proceeding.
For each finding that has a proposed fix (harness bug, harness gap, process improvement), present it individually and ask for a decision:
Finding: [Brief title] Phase: [which phase skill] What happened: [evidence — be specific] Proposed change: [exact edit to the phase skill] Recommendation: Apply / Skip
(apply / skip)
Wait for the user's answer before showing the next finding. Track which ones they approved.
Skip "not actionable" findings in this step — they'll appear in the summary.
For each concept with concrete friction evidence (max 2-3 per retro), present individually:
Suggestion: [Concept name] Friction observed: [specific incidents from this round] What would change: [which phase skills get augmented or generated] Recommendation: Adopt
(adopt / not now / not relevant)
Wait for the user's answer before showing the next suggestion.
Rules:
After all decisions are collected, output a brief summary:
Decisions: N findings reviewed, M approved. K concepts suggested, J adopted.
Applying changes now.
Apply only what the user approved:
For adopted concepts OR improvements to existing phase skills:
## Harness Context.harness/retros/YYYY-MM-DD-retro.mdHARNESS.md if the workflow changed: new concepts adopted, skills generated/updated, workflow steps added or removed. HARNESS.md should always reflect the current state./harness-setup to re-examine the workflow shape."pnpm build after pnpm install" — not "the skill should be clearer."