Menu
Start a new H·AI·K·U intent — describe what you want to accomplish and the system creates a structured lifecycle for it
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
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
Admin tools for unsticking corrupt intents — force a stage complete, set intent fields, reset drift, mutate feedback. Every mutation requires user confirmation via the SPA picker.
Based on SOC occupation classification
| name | haiku-start |
| description | Start a new H·AI·K·U intent — describe what you want to accomplish and the system creates a structured lifecycle for it |
If the user starts the intent with a referenced file — a spec, a doc, a screenshot, a path like ~/Downloads/spec.pdf, or a dragged-in attachment — read it and synthesize its relevant substance directly into the description and context you author below. NEVER store, quote, or reference the file's path in any field. An absolute path leaks the user's machine layout, and the external file won't travel with the intent — the intent must stand on its own from its own text. The path is throwaway; the synthesized content is the durable record. (Read PDFs/images natively; capture what they say, not where they live.)
Prelaborate — If the user's description is short (under 2 sentences) or vague, ask 2-3 targeted questions via AskUserQuestion to understand scope, desired outcome, and constraints. Fold answers into a richer description (3-5 sentences).
Quick context scan — Glance at the project structure (2-3 tool calls max) to understand the tech stack and project purpose. This informs studio selection later.
Right-size it — the escape hatch (do this BEFORE creating an intent). A full multi-stage intent is the right container for a feature. It is overkill for a bug fix, a typo, a config tweak, a copy change, or a small localized refactor — work where the whole lifecycle (design → build → review across stages) costs more than the change itself. Assess what the user actually described and pick the lightest container that fits:
If it's clearly feature-class, skip straight to step 4 — don't interrupt a real feature with a downgrade prompt. Otherwise, surface the lighter path with AskUserQuestion, recommended option FIRST (so accepting is one tap), and let the user keep the heavier path if they want the tracking:
<bug fix / small task> — how do you want to run it?"Route on the answer:
haiku_zap { task: "<the task, in one or two sentences>" } and follow its returned message verbatim (see /haiku:haiku-zap). Stop here — the rest of this skill doesn't apply.haiku_run_next and lock the mode to quick the way /haiku:haiku-quick does (haiku_select_mode { options: ["quick"] } after studio selection). The user chose quick here, so locking it honors their choice — you are not dictating the mode.Write the title and description, then create the intent — You must produce BOTH:
title: A crisp 3–8 word summary, ≤80 chars, single line, no trailing period. Write it deliberately as a human-readable name for the intent. Do NOT pass a truncated description or the first sentence of a paragraph.
"Add archivable intents", "Migrate auth to OAuth2", "Fix mobile nav overflow""Add archivable intents to H·AI·K·U. Users need a way to soft-hide completed,…""Implement a new system to allow users to mark intents as" (mid-sentence truncation)description: The prelaborated narrative (2–5 sentences) covering scope, motivation, and constraints. This is the richer context, not a title.slug: Kebab-case identifier (max 40 chars). Usually derived from the title.context: Summary of key decisions and constraints from the conversation.studio_candidates (REQUIRED): The 2–4 studios that best fit what you just described — this pre-narrows the studio picker so the user isn't scrolling the whole registry on every intent. Call haiku_studio_list first to see the studios with their descriptions, then pick the closest matches (canonical name, slug, or alias all resolve). You have the description in context right now — this is the one moment you can do a semantically-aware pick. The picker shows your shortlist first and keeps the rest behind a "Show all studios…" expansion, so narrowing is never lossy — there's no downside to narrowing, so always do it. If you call haiku_intent_create without it, the tool rejects the call and tells you to fetch haiku_studio_list and retry; don't guess studio names, fetch the list.The title and description are distinct fields — the tool does NOT derive one from the other. Writing a lazy title (e.g. the first chunk of the description) will be rejected.
Do NOT pass mode, stages, or studio. Those fields are engine-managed and chosen by the user via the picker. studio_candidates is a hint that pre-narrows that picker — it does not lock the studio, and the user still makes the final pick. The tool's input schema does not accept mode/stages/studio; trying to pass them will fail validation.
Follow the tool's instructions — The tool will direct you to call haiku_run_next, which then drives the elicitation chain in order:
haiku_select_studio — user picks the studio.haiku_select_mode — user picks the mode (continuous, discrete, autopilot, quick).haiku_select_stage — fires only when mode == quick, user picks the single stage to run.