haiku-method 3.13.1 → 3.14.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "haiku-method",
-  "version": "3.13.1",
+  "version": "3.14.0",
   "description": "H·AI·K·U methodology — universal lifecycle orchestration with hat-based workflows, completion criteria, and automatic context preservation.",
   "homepage": "https://haikumethod.ai",
   "repository": {

package/schemas/intent.schema.json

@@ -43,8 +43,14 @@
 		},
 		"mode": {
 			"type": "string",
-			"enum": ["continuous", "discrete", "autopilot", "discrete-hybrid"],
-			"description": "Execution mode."
+			"enum": [
+				"continuous",
+				"discrete",
+				"autopilot",
+				"discrete-hybrid",
+				"quick"
+			],
+			"description": "Execution mode. Engine-managed via haiku_select_mode — never set directly by the agent."
 		},
 		"autopilot": {
 			"type": "boolean",

package/skills/change-mode/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: change-mode
+description: Change the execution mode of an active H·AI·K·U intent — dial up or dial back human involvement mid-flight
+---
+
+# Change Mode
+
+Change the execution mode of an in-flight intent. Use when:
+
+- The mode chosen at start no longer fits (e.g. `discrete` is too heavy for a small change, or `continuous` is too autonomous for high-risk work).
+- A teammate picked up an intent and wants different review semantics than the original owner.
+- An intent was created with the wrong mode and you need to correct it before too much state accumulates.
+
+## Process
+
+1. **Resolve the intent.** If no slug is in scope (current branch isn't a `haiku/<slug>/...` branch), ask which intent to change. Otherwise infer from the branch.
+
+2. **Call `haiku_select_mode`** with the intent slug. The tool elicits a mode value from the user. It will automatically:
+   - Hide `quick` from the picker if the intent has already started a stage (you cannot enter or leave `quick` mid-flight — it's single-stage by definition).
+   - Hide all options except the current mode if the intent is in `quick` and has started (no transition out is allowed).
+   - For non-quick destinations: write `mode` to intent.md and set `stages` to the studio's full stage list (idempotent — restoring the full list is safe even if it was already there).
+
+3. **Drive forward.** After the mode is picked, call `haiku_run_next { intent: "<slug>" }`. The workflow engine continues from wherever the intent currently is — mode changes don't reset stage progress.
+
+## Constraints
+
+- **No `quick` transitions mid-flight.** Quick mode is single-stage and chosen at intent creation only. Switching into quick would amputate the rest of the workflow; switching out would suddenly add stages the user never reviewed. The engine refuses both.
+- **Cannot change mode pre-studio.** If `studio` isn't set yet, the intent hasn't reached mode selection — use `/haiku:start` to drive the initial elicitation chain instead of this skill.
+
+## Notes
+
+- This skill never accepts a free-form mode value as an argument. Mode is engine-managed; the only way to set it is through `haiku_select_mode`'s elicitation.
+- `discrete-hybrid` is a derived mode, not directly selectable. The engine computes it from `continuous` + per-stage external gates.

package/skills/quick/SKILL.md

@@ -5,21 +5,22 @@ description: Quick mode for small tasks — single-stage intent with auto-advanc
 
 # Quick Mode
 
-A quick task is a regular intent restricted to a single stage. No special workflow engine mode — just `intent.stages: [<one-stage>]` as an allow-list, which the orchestrator's `resolveIntentStages` honors.
+A quick task is a regular intent in `quick` mode (single-stage). The workflow engine's elicitation chain handles studio + stage selection; the only difference vs `/haiku:start` is that mode is locked to `quick` (skipping the mode-elicit step).
 
 ## Process
 
 1. **Prelaborate briefly.** If the task description is vague, ask ONE clarifying question via `AskUserQuestion` with `options[]`. Otherwise skip.
 2. **Create the intent** with `haiku_intent_create`:
-   - `mode: "continuous"`
    - `title`: 3–8 words, ≤80 chars, single line. NOT a truncated description. Good: `"Fix login button padding"`. Bad: `"Fix login button padding on mobile because…"`
    - `description`: 2–5 sentences of context.
-3. **Pick the studio** with `haiku_select_studio`. The response includes `all_studio_stages`.
-4. **Ask the user which stage to run** using `AskUserQuestion` (NOT `ask_user_visual_question` — no visual artifact here). Pass `all_studio_stages` as `options[]`.
-5. **Restrict the intent to the chosen stage.** Direct-edit `intent.md` frontmatter to add `stages: [<chosen-stage>]`. This is an allow-list that narrows the studio's stage sequence — the workflow engine reads it via `resolveIntentStages` and filters out every other stage.
-6. **Drive the lifecycle** by calling `haiku_run_next { intent: "<slug>" }`. The workflow engine starts at the chosen stage, runs its phases (elaborate → review → execute → review → gate), and completes the intent when that stage's gate passes.
+   - **Do NOT pass `mode` or `stages`** — engine-managed. The tool will reject them.
+3. **Drive the lifecycle** by calling `haiku_run_next { intent: "<slug>" }`. The workflow engine routes to `select_studio` first; the agent calls `haiku_select_studio`.
+4. **After studio is selected**, the engine routes to `select_mode`. Call `haiku_select_mode { intent: "<slug>", options: ["quick"] }` — passing `options: ["quick"]` locks the mode without showing the picker (this is the only thing that distinguishes `/haiku:quick` from `/haiku:start`).
+5. **The engine then routes to `select_stage`.** Call `haiku_select_stage { intent: "<slug>" }` — this elicits a single stage from the studio's stage list.
+6. **Drive forward.** Each subsequent `haiku_run_next` advances through the pre-stage intent review and into the chosen stage.
 
 ## Guardrails
 
 - If the task needs multiple stages, stop and suggest `/haiku:start` instead — don't cram it into a single stage.
-- If the user's stage choice isn't in `all_studio_stages`, re-prompt with the real list.
+- The agent NEVER passes `mode` or `stages` directly to `haiku_intent_create`. Both are engine-controlled.
+- The user picks the stage via `haiku_select_stage`'s elicit — the agent does not pre-fill it unless the user already explicitly chose one in conversation, in which case pass `options: ["<chosen-stage>"]`.

package/skills/start/SKILL.md

@@ -22,10 +22,16 @@ description: Start a new H·AI·K·U intent — describe what you want to accomp
 
    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.
 
-4. **Follow the tool's instructions** — The tool will direct you to call `haiku_run_next`, which handles studio selection and begins the lifecycle.
+   **Do NOT pass `mode` or `stages`.** Those fields are engine-managed and chosen by the user via elicitation. The tool's input schema does not accept them; trying to pass them will fail validation.
+
+4. **Follow the tool's instructions** — The tool will direct you to call `haiku_run_next`, which then drives the elicitation chain in order:
+   1. `haiku_select_studio` — user picks the studio.
+   2. `haiku_select_mode` — user picks the mode (continuous, discrete, autopilot, quick).
+   3. `haiku_select_stage` — fires only when mode == `quick`, user picks the single stage to run.
+   4. The pre-stage intent review gate opens for the user's approval before any stage starts.
 
 ## Notes
 
-- Default to **continuous** mode (stages auto-advance)
-- Do NOT ask the user to pick a studio — the workflow engine handles studio selection via elicitation
-- If the user already provided a detailed description, skip prelaboration and go straight to step 3
+- **Never dictate mode or stages.** If the user mentions "discrete" or "single stage" or "just inception" in their description, that's *context for the user when they make the elicit choice* — pass it along into the description if it's load-bearing, but do not pre-set the field. The agent MUST let the user pick via elicitation.
+- Do NOT ask the user to pick a studio — the workflow engine handles studio selection via elicitation.
+- If the user already provided a detailed description, skip prelaboration and go straight to step 3.

package/studios/ARCHITECTURE.md

@@ -284,6 +284,10 @@ When all pre-advance checks pass, the tick emits one mainline action describing
 
 | Action | Meaning | What the agent does |
 |---|---|---|
+| `select_studio` | Studio not yet chosen on the intent | Call `haiku_select_studio` (elicits a studio from the user) |
+| `select_mode` | Studio chosen, mode not yet chosen | Call `haiku_select_mode` (elicits a mode: continuous, discrete, autopilot, quick). Mode is engine-managed — agents never set it directly. |
+| `select_stage` | Mode is `quick` and the single stage isn't picked yet | Call `haiku_select_stage` (elicits exactly one stage from the studio's stage list) |
+| `gate_review` (intent_review) | Pre-stage approval of the minimal intent — fires after studio + mode + (if quick) stage are set, before stage 0 begins | Surface the review URL to the user; call `haiku_await_gate` |
 | `start_stage` | First entry to a new stage | Acknowledge, retick |
 | `elaborate` | Stage is in elaborate phase | Collaborate with the user, draft units, record decisions |
 | `pre_review` | Pre-execute review of unit specs | Spawn review-agent subagents |
@@ -301,6 +305,8 @@ When all pre-advance checks pass, the tick emits one mainline action describing
 | `escalate` | Terminal — needs human intervention | Stop and surface to user |
 | `error` | Terminal — engine cannot proceed | Stop and surface to user |
 
+The pre-stage chain — `select_studio → select_mode → (quick? → select_stage) → intent_review (gate_review)` — is the only place orientation choices are made. The agent **never** writes `mode` or `stages` directly; both fields are FSM-driven (rejected by `haiku_intent_set` with `intent_field_engine_only`). `haiku_intent_create` does not accept `mode` or `stages` either — every orientation choice flows through real elicitation.
+
 The agent **never branches on action type for workflow-routing decisions**. They just follow the instruction the action's prompt builder rendered.
 
 ### 5.5 Properties this gives us