haiku-method 2.2.0

package/skills/composite/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: composite
+description: Create a composite intent combining stages from multiple studios with sync points
+---
+
+# Composite Intent
+
+Create a composite intent that runs stages from multiple studios in parallel with sync points.
+
+## Process
+
+1. Gather from the user:
+   - Work description
+   - Studio selection (MUST select 2+ studios — use `haiku_studio_list` to get available studios)
+   - Stage selection per studio
+   - Sync points between studios
+
+2. Present studio selection as a multi-select question via `ask_user_visual_question`. At least 2 required.
+
+3. For each selected studio, show its stages and let the user pick which to include.
+
+4. Ask where studios need to synchronize. Suggest sync points based on stage produce/require chains.
+
+5. Create the intent with composite frontmatter:
+```yaml
+composite:
+  - studio: {studio1}
+    stages: [stage1, stage2]
+  - studio: {studio2}
+    stages: [stage1, stage2]
+sync:
+  - wait: [studio1:stage2]
+    then: [studio2:stage2]
+```
+
+6. Report the created intent with studio/stage overview.

package/skills/dashboard/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: dashboard
+description: Show active intents and their status overview
+---
+
+# Dashboard
+
+Call `haiku_dashboard` to get the current intent status overview. Present the result to the user.

package/skills/gate-review/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: gate-review
+description: Pre-delivery code review with multi-agent fix loop
+---
+
+# Review
+
+Call `haiku_review` to compute the diff and get review instructions. Follow the returned instructions to spawn review agents and process findings.

package/skills/ideate/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: ideate
+description: Surface adversarially-filtered improvement ideas from the codebase
+---
+
+# Ideate
+
+Analyze the codebase and surface high-impact improvement ideas that survive adversarial scrutiny.
+
+1. **Scope** — If a focus area is given, analyze that. Otherwise analyze the full codebase (prioritize high-churn areas).
+2. **Identify** opportunities: Performance, Security, Maintainability, Test Coverage, DX.
+3. **Adversarial filter** — Argue against each idea on cost, prematurity, complexity, alternatives, risk.
+4. **Present** survivors with: one-line description, impact, effort (low/med/high), strongest argument against, verdict (do it / park it). Also list discards with reasons.
+5. **Next steps:** Elaborate (`/haiku:start`), deep-dive (`/haiku:ideate <sub-area>`), or discard.
+
+Be ruthless — five strong ideas beat twenty weak ones. Zero ideas is valid if nothing survives.

package/skills/migrate/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: migrate
+description: Migrate legacy AI-DLC intents to H·AI·K·U format
+---
+
+# Migrate
+
+Convert legacy `.ai-dlc/` intents to `.haiku/` format.
+
+1. Scan `.ai-dlc/` for intents. If a specific slug is given, migrate that one. Otherwise list and ask.
+2. Run `haiku migrate <slug>` to perform the migration.
+3. After migration, suggest `/haiku:pickup <slug>` to continue execution.

package/skills/operate/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: operate
+description: Manage operations — list, execute, deploy, monitor, and teardown operational tasks
+---
+
+# Operate
+
+Manage operational tasks defined in studio operation templates.
+
+## Process
+
+1. If a specific operation is requested, load it from the studio's `operations/` directory and execute it.
+2. Otherwise, list available operations from the active intent's studio.
+3. Check `.haiku/intents/*/operations/` for intent-specific operation specs.
+
+## Modes
+
+- **No arguments:** List all operations across all intents
+- **With intent slug:** Show status table for that intent's operations
+- **With intent + operation:** Execute a specific operation
+- **With --deploy:** Generate deployment manifests
+- **With --status:** Show health and overdue operations
+- **With --teardown:** Remove deployments (preserves specs)
+
+For agent-owned operations, execute the companion script. For human-owned operations, present the checklist and track completion.

package/skills/pickup/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: pickup
+description: Resume an active H·AI·K·U intent — pick up where you left off
+---
+
+# Resume an Intent
+
+## Process
+
+1. **Advance the lifecycle** — Call `haiku_run_next` (no args). The workflow engine resolves the intent automatically:
+   - If you're on a `haiku/<slug>/main` or `haiku/<slug>/<stage>` branch → uses that slug.
+   - If there's exactly one active intent on disk → uses it.
+   - If there are multiple and no branch match → the tool returns the list of slugs for you to disambiguate, then re-call with `haiku_run_next { intent: "<slug>" }`.
+
+2. **Follow the instructions** — The tool returns the next action and detailed instructions. Execute them.
+
+## Notes
+
+- If no active intents exist, suggest starting a new one with `/haiku:start`
+- The `haiku_run_next` tool handles all workflow engine logic AND intent resolution — no intent-list call needed in the common case.

package/skills/pressure-testing/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: pressure-testing
+description: Adversarial challenge prompt for hat definitions using Evaluation-Driven Development
+---
+
+# Pressure Testing
+
+Adversarially test hat definitions using Evaluation-Driven Development (RED-GREEN-REFACTOR).
+
+## Process
+
+1. If no hat specified, list available hats from `$CLAUDE_PLUGIN_ROOT/studios/software/stages/*/hats/` and ask the user to pick one.
+
+2. Load the hat definition file.
+
+3. **Design Pressure Scenario:**
+   - Combine 3+ pressure types (time, sunk cost, authority, economic, exhaustion, social, pragmatic)
+   - Target the hat's most important constraints
+   - Present scenario to user for approval
+
+4. **RED Phase** (baseline without anti-rationalization table):
+   - Run scenario with a subagent that has hat instructions minus anti-rationalization table
+   - Document verbatim: decisions made, rationalizations used, sections violated
+
+5. **GREEN Phase** (full hat definition):
+   - Run same scenario with full hat definition
+   - Agent MUST cite specific hat sections, acknowledge temptations
+   - PASS if correct decision citing hat sections; FAIL if rationalized past them
+
+6. **REFACTOR Phase:**
+   - If GREEN failed: capture rationalization, add to anti-rationalization table, re-run
+   - If GREEN passed: document that hat held under pressure
+
+7. Commit artifacts to `.haiku/pressure-tests/`

package/skills/quick/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: quick
+description: Quick mode for small tasks — single-stage intent with auto-advance
+---
+
+# 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.
+
+## 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.
+
+## 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.

package/skills/refine/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: refine
+description: Refine intent, unit, or upstream stage outputs mid-execution
+---
+
+# Refine
+
+1. Call `haiku_intent_list` to find the active intent.
+2. Use `ask_user_visual_question` to ask what to refine: intent-level spec, specific unit, or upstream stage output.
+3. For stage-scoped refinement: use `haiku_studio_stage_get` and `haiku_unit_list` to read current state, create new units, run hat sequence for new units only.
+4. After refinement: re-queue affected units (set status: pending), commit changes.

package/skills/reflect/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: reflect
+description: Analyze a completed H·AI·K·U intent cycle and produce reflection artifacts
+---
+
+# Reflect
+
+1. Call `haiku_intent_list` to find the intent. If multiple, ask the user which one.
+2. Call `haiku_reflect { intent: "<slug>" }` — the tool returns metrics and analysis instructions.
+3. Follow the returned instructions.

package/skills/repair/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: repair
+description: Scan intents for metadata issues, auto-apply safe fixes, push to all intent branches, and open PRs for merged branches
+---
+
+# Repair
+
+Call `haiku_repair` to scan intents for metadata issues. The MCP tool auto-applies the fixes it can do mechanically; remaining issues need agent or user attention.
+
+## Default Behavior (Git Repo)
+
+In a git repository, `haiku_repair` (with no arguments) scans **every** intent branch (`haiku/<slug>/main`) sequentially via temporary worktrees. For each branch:
+
+1. Scans the intent for metadata issues
+2. Auto-applies safe fixes (title trim, legacy field rename, missing-field defaults, studio alias migration)
+3. Commits the fixes with a `repair: ...` message
+4. Pushes the commit to `origin/<branch>`
+5. If the branch was already merged into mainline (`main` or `master`), opens a PR/MR back to mainline carrying the repair commit
+6. Reports any remaining issues that need agent attention
+
+The loop is sequential because some fixes may require user input — the agent processes branches one at a time and can pause for interaction.
+
+## Args
+
+- `intent: <slug>` — repair a single intent in the current working directory only (skips multi-branch mode)
+- `apply: false` — scan without applying fixes (returns the issue report only)
+- `skip_branches: true` — force cwd-only mode even in a git repo
+
+## Auto-Applied Fixes (Mechanical)
+
+The MCP tool applies these without asking — they have no judgment component:
+
+- **Overlong/multiline titles** — trimmed to a one-liner using `deriveIntentTitle`; the full original description is preserved as a paragraph in the body
+- **Legacy `created` field** → renamed to `created_at`
+- **Missing `created_at`** — defaulted from file mtime
+- **Missing `mode`** — defaulted to `continuous`
+- **Stages mismatch** — updated to match the studio's stage definition
+- **Legacy `studio: software`** → migrated to `application-development` (the canonical name); aliases continue to resolve
+- **Missing stage completion records** — for stages before `active_stage` with no `state.json` or non-completed status, synthesizes `state.json` with `status: "completed"`. Fixes migrated intents that cause the workflow engine to reset backwards.
+- **Date repair from git** — `created_at`, `started_at`, and `completed_at` are derived from git commit history (first commit date, last commit date) when they don't match the frontmatter values.
+
+## Issues Returned to Agent (Need Judgment)
+
+These come back as remaining issues — handle them interactively:
+
+- **Missing `studio`** — needs the user to pick one
+- **Missing `status`** — needs to be inferred from state files or asked
+- **Invalid `active_stage`** — needs review of stage progression
+- **Stage `state.json` invalid status** — needs the right status set
+- **Unit filename pattern violations** — rename units explicitly
+- **Unit missing `inputs:`** — declare upstream artifact paths
+- **Completed but not merged** — intent marked `completed` but branch is not merged into mainline. Either merge the branch or downgrade status to `active`.
+
+## Workflow
+
+1. Call `haiku_repair` (no args) — scans every branch, applies what it can, pushes, opens PRs
+2. Read the multi-branch report
+3. For each branch with **remaining issues**, address them in the worktree path noted in the report (or check out the branch locally)
+4. Commit your manual fixes and push
+5. If a branch is now clean and was already merged, open a PR/MR back to mainline manually
+
+## Checks Performed
+
+- Missing/invalid intent fields (title, studio, stages, status, mode)
+- Overlong / multiline titles (titles must be ≤80 chars, single line)
+- Stage state consistency and active_stage validity
+- Unit file naming convention (`unit-NN-slug.md`)
+- Unit required fields (type, status)
+- **Unit inputs validation** — every unit must have a non-empty `inputs:` field declaring upstream artifacts it references. Units without inputs will block execution.

package/skills/report/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: report
+description: Submit feedback or a bug report to the H·AI·K·U team
+---
+
+# Feedback
+
+1. Ask the user what feedback they'd like to share — what happened, what they expected, and any steps to reproduce.
+2. Summarize their feedback into a clear, actionable issue report. Do NOT submit their words verbatim — synthesize it into a structured summary with context (what they were doing, what went wrong, what the expected behavior was).
+3. Ask the user if the summary looks good before submitting.
+4. Call `haiku_report` with the synthesized `message`. Optionally include `contact_email` and `name` if the user provides them.

package/skills/reset/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: reset
+description: Reset an intent — delete all state and recreate from the same description
+---
+
+# Reset Intent
+
+1. Call `haiku_intent_list` to find the intent. If multiple active, ask the user which one.
+2. Call `haiku_intent_reset { intent: "<slug>" }` — the tool asks for confirmation via elicitation, preserves the title and description, deletes all state, and returns instructions to recreate.
+3. Follow the returned instructions to call `haiku_intent_create` with the preserved `title` and `description`. If the preserved title looks auto-truncated (ends in `…` or is a mid-sentence fragment), rewrite it as a crisp 3–8 word summary before calling — don't re-save a broken title.

package/skills/revisit/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: revisit
+description: Revisit an earlier stage or phase to address issues
+---
+
+# Revisit
+
+Return to a specific stage or phase to address issues found during execution. Revisit happens via the feedback path: log one or more `stage_revisit` feedback items at the target stage, then call `haiku_run_next`. The pre-tick gate sees the new findings and reroutes the cursor.
+
+## Process
+
+1. **Find the active intent.** Call `haiku_intent_list`. If multiple are active, ask the user which one.
+
+2. **Confirm the target stage and reasons.** Ask the user (a) which stage to revisit (default: the current `active_stage`) and (b) what should change. Each reason becomes one feedback item — short, actionable, scoped to a single concern.
+
+3. **Log a stage_revisit feedback for each reason.** For each reason:
+
+   ```
+   haiku_feedback {
+     intent: "<slug>",
+     stage: "<target-stage>",
+     title: "<one-line summary>",
+     body: "<what's wrong, what should change, any file:line refs>",
+     origin: "agent",
+     resolution: "stage_revisit"
+   }
+   ```
+
+   The `resolution: "stage_revisit"` is what tells the pre-tick gate to reroute the cursor on the next tick. Without it, the FB just sits in the stage's pending list and the gate keeps the agent on the current stage.
+
+4. **Drive the lifecycle.** Call `haiku_run_next { intent: "<slug>" }`. The pre-tick gate sees the new stage_revisit FBs and emits a `revisited` action that reroutes the cursor to the target stage's elaborate phase. The agent picks up from there and addresses each finding as part of the next iteration.
+
+## Why this shape
+
+- **One pattern, not two.** Every "I want to change the workflow" expression — agent-blocked, reviewer-rejected, user-typed — flows through the same surface: write a feedback finding, call run_next, the pre-tick gate routes. There is no separate "revisit verb."
+- **Audit trail.** Each reason becomes a durable on-disk feedback record showing exactly why the rewind happened and what needs to change. Future debugging gets the full why.
+- **Consistent with the agent's contract.** The agent's universe is "receive instruction, do what it says, call run_next" — no extra workflow-routing tools. Revisit isn't special.
+
+## Quick reference
+
+| What you want | Tool calls |
+|---|---|
+| User wants to revisit current stage | `haiku_feedback {..., resolution: "stage_revisit"}` × N → `haiku_run_next` |
+| User wants to revisit an earlier stage | `haiku_feedback {stage: "<earlier>", ..., resolution: "stage_revisit"}` × N → `haiku_run_next` |
+| Agent is blocked, needs upstream rework | Same — log a stage_revisit FB at the upstream stage, call run_next |

package/skills/scaffold/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: scaffold
+description: Scaffold custom H·AI·K·U artifacts — studios, stages, hats, providers
+---
+
+# Scaffold
+
+Create custom H·AI·K·U artifact templates. Ask the user which type and name.
+
+- **Studio:** `.haiku/studios/{name}/STUDIO.md` + `stages/` directory
+- **Stage:** `.haiku/studios/{studio}/stages/{name}/STAGE.md` + `hats/` and `review-agents/` dirs. Add to parent studio's stages list.
+- **Hat:** `.haiku/studios/{studio}/stages/{stage}/hats/{name}.md` with Focus, Produces, Reads, Anti-patterns. Add to parent stage's hats list.
+- **Provider:** `.haiku/providers/{name}.md` copied from `$CLAUDE_PLUGIN_ROOT/providers/{category}.md` as template.

package/skills/seed/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: seed
+description: Plant, track, and surface forward-looking ideas at the right moment
+---
+
+# Seeds
+
+Call `haiku_seed` with an optional `action` ("list", "plant", "check"). Follow the returned instructions.
+
+Default action is "list".

package/skills/setup/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: setup
+description: Configure H·AI·K·U for this project — auto-detect VCS, hosting, CI/CD, and providers
+---
+
+# Setup
+
+Configure `.haiku/settings.yml` by auto-detecting the environment and confirming with the user.
+
+1. **Detect:** VCS (`git`/`jj`), hosting (remote URL), CI/CD (workflow files), default branch.
+2. **Providers:** Use ToolSearch to discover available MCP providers for ticketing, spec, design, comms.
+3. **Confirm:** Present detected settings via `ask_user_visual_question`. Allow adjustments.
+4. **Configure providers:** For each confirmed provider, collect required config from `$CLAUDE_PLUGIN_ROOT/schemas/providers/{type}.schema.json`.
+5. **Workflow tuning:** Ask about mode, granularity, default studio, review agents, etc.
+6. **Write:** Save `.haiku/settings.yml` preserving existing fields. Commit.
+7. **Done:** Display summary. Suggest `/haiku:start`.

package/skills/start/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: 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
+---
+
+# Start a New Intent
+
+## Process
+
+1. **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).
+
+2. **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.
+
+3. **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.
+     - Good: `"Add archivable intents"`, `"Migrate auth to OAuth2"`, `"Fix mobile nav overflow"`
+     - Bad: `"Add archivable intents to H·AI·K·U. Users need a way to soft-hide completed,…"`
+     - Bad: `"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.
+
+   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.
+
+## 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

package/skills/studios/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: studios
+description: Browse available H·AI·K·U studios grouped by category with help links into each studio definition
+---
+
+# Studios
+
+Browse the studio portfolio — every lifecycle template available in this
+project, grouped by category, with direct links to each studio's definition.
+
+## What to do
+
+1. Call `haiku_studio_list` to get the full list of studios. The response
+   includes, for each studio: `name`, `slug`, `aliases`, `description`,
+   `category`, `stages`, `source` (`plugin` or `project`), `path` (directory),
+   and `studio_md` (absolute path to STUDIO.md — the canonical definition).
+
+2. Group the studios by `category` and present them as a Markdown portfolio.
+   Inside each category, sort alphabetically by canonical `name`.
+
+3. For each studio, render:
+   - **Name** (with slug in parens if different), and `[project]` tag if
+     `source === "project"`
+   - One-line description
+   - Stage count or stage list if short (≤5 stages)
+   - A help link to the studio definition: render as a Markdown link using
+     the `studio_md` path, labelled "definition"
+   - Aliases, if any (so users know all the ways to invoke the studio)
+
+4. If the user asks to drill into a studio, call `haiku_studio_get` with the
+   name, slug, alias, or dir — any of them resolves. For a specific stage,
+   use `haiku_studio_stage_get`.
+
+## Example output shape
+
+```markdown
+## engineering
+
+- **Application Development** (`appdev`) — Lifecycle for web, mobile, and desktop applications · 6 stages · [definition](/abs/path/to/STUDIO.md)
+  - aliases: `software`
+- **Game Development** (`gamedev`) — Lifecycle for games · 5 stages · [definition](/abs/path/to/STUDIO.md)
+- **Hardware Development** (`hwdev`) — Lifecycle for hardware products · 6 stages · [definition](/abs/path/to/STUDIO.md)
+- **Library Development** (`libdev`) — Lifecycle for libraries, SDKs, CLI tools · 4 stages · [definition](/abs/path/to/STUDIO.md)
+
+## go-to-market
+...
+```
+
+## Notes
+
+- Always include the help link (`studio_md`) — discoverability is the whole
+  point of browse. Users should be able to click through to read any studio's
+  full definition.
+- Project studios (`source: project`) override plugin studios of the same
+  name. Surface this clearly with a `[project]` tag so users know they're
+  looking at a customization.
+- Do not filter or omit studios. If there are 20+, show all of them — the
+  user asked to browse.

package/skills/triggers/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: triggers
+description: Poll configured providers for events that should create intents or advance gates
+---
+
+# Triggers
+
+Poll configured providers for events that should create intents or advance gates.
+
+## Process
+
+1. Read provider configuration from `.haiku/settings.yml`
+2. Load last poll timestamp from `.haiku/trigger-poll.json`
+3. For each configured provider (filtered by category if specified):
+   - Query for events since last poll
+   - Match events against studio trigger declarations
+   - Check if events satisfy any await gates on active intents
+4. Report findings:
+   - New intent suggestions from matched triggers
+   - Gate advancements for await gates now satisfied
+   - State sync for provider changes to active intents
+5. Update poll timestamp
+6. If running interactively, ask for confirmation before creating intents or advancing gates
+7. If no providers configured, suggest configuring them in `.haiku/settings.yml`

package/skills/unarchive/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: unarchive
+description: Unarchive an intent — restore a previously archived intent to default lists
+---
+
+# Unarchive Intent
+
+1. If no slug was provided, call `haiku_intent_list { include_archived: true }`, filter to entries where `archived` is true, and ask the user in plain prose which intent to unarchive.
+2. Call `haiku_intent_unarchive { intent: "<slug>" }` — the tool clears the `archived` flag and returns instructions.
+3. Follow the returned instructions and report the result.

package/skills/version/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: version
+description: Show the running H·AI·K·U MCP binary version and plugin version
+---
+
+# Version
+
+Call the `haiku_version_info` tool to retrieve version information.
+
+Display both:
+- **MCP version** — the version baked into the running binary at build time
+- **Plugin version** — the version from `plugin.json` on disk
+
+If a pending update is reported, mention it to the user.