Menu
Rebuild a corrupted drift baseline, relocate misplaced worktrees, or open PRs against mainline for already-merged intent branches
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Quick mode for small tasks — single-stage intent with auto-advance
Start a new H·AI·K·U intent — describe what you want to accomplish and the system creates a structured lifecycle for it
Full autonomous workflow — elaborate, plan, build, review, and deliver in one command
Open the SPA review pane for an intent so the user can browse units, feedback, stage artifacts, and outputs. Non-blocking on the workflow — leaves feedback that the engine picks up on the next tick. Use whenever the user wants to "see," "open," "show," or "look at" the current intent or a specific stage.
Reverse-engineer an existing feature into H·AI·K·U intent artifacts
Zero-ceremony single-unit execution — run one task directly through a stage's hat loop without intent or workflow scaffolding
Based on SOC occupation classification
| name | haiku-repair |
| description | Rebuild a corrupted drift baseline, relocate misplaced worktrees, or open PRs against mainline for already-merged intent branches |
Call haiku_repair for one of the three remaining v4 recovery paths.
haiku_repair under v4 is narrow. Use it for:
.haiku/worktrees/ at the agent's cwd instead of the primary repo root. After upgrading, the misplaced worktrees still exist and confuse the engine. Repair migrates them via git worktree move for clean trees; dirty ones are reported for manual resolution.Do not run /haiku:haiku-repair to "fix a wedge" on a v4 intent that won't advance. The fixes it once did under v3 — synthesizing state.json, validating active_stage, enforcing status: completed/active on units — are no-ops on v4 intents. v4 derives stage position from disk (unit FM + branch topology), has no state.json, and uses iterations + approval stamps instead of unit-level status enums. The v0→v4 migrator runs in-band at haiku_run_next time and handles every schema-shape concern.
If a v4 intent won't advance, the right diagnostic is the loop-guard diagnostic in haiku_run_next's response (writes to $TMPDIR/haiku-prompts/{session_id}/loop-guards.log and surfaces a diagnostic: line in the error body). Paste that into a bug report — don't run /haiku:haiku-repair hoping it'll patch something.
In a git repository, haiku_repair (no args) scans every intent branch via temp worktrees, applies the narrow fixes above, pushes, and opens PRs when applicable. The loop is sequential because some fixes need user input.
intent: <slug> — repair a single intent in the current working directory only (skips multi-branch mode)apply: false — scan without applying fixes (returns the report only)skip_branches: true — force cwd-only mode even in a git repohaiku_repair with the specific concern (drift baseline / worktree / mainline-PR) — passing intent: <slug> if scoped to one intent.If the report is empty on a v4 intent, that's the expected outcome. Repair has nothing to do — the engine handles state in-band.