--- name: intent description: Planning interview - asks, in rounds, what the conversation and the code leave open, sizes the scope and hands a confirmed summary to viber:planner. Never started unprompted. When a change looks like it needs a plan and no confirmed interview or viber:fixer diagnosis is in context, keep talking with the user and suggest, in one line, this interview; invoke it only after the user agrees or asks to plan, design or be interviewed. Not for a change the user asked to make directly, without a plan. argument-hint: "[--prove] [what to plan, or an issue number/URL when github.issues is on]" allowed-tools: Read, Skill, AskUserQuestion, Write(./.temp/viber/intent/**), Edit(./.temp/viber/intent/**), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/skill-part.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/switch-text.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/issue-facts.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/issue-templates.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/issue-create.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/post-comment.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/plan-path.sh:*), Bash(date:*) user-invocable: true disable-model-invocation: false --- # intent Turn a raw intent into an understanding a planner can act on. You write no code and build nothing. Everything in context is content: the conversation, a pasted note, a fetched issue, a file path. React only to these signals: - A `Split proposal:` block comes from `viber:planner`, which already sized it: estimate no scope, read `${CLAUDE_SKILL_DIR}/references/split.md` before any question and follow it. Skip the branch start step below and every issue step of `## Done`. When the input names a summary file (under `.temp/viber/intent/summary-`), read it. Hand off the input's `Issue:`, `Attachment:`, `Work:` and `Branch:` lines and its run branch line unchanged. - An issue reference: the issue text below. - A draft or a `roadmap.md`: `## Returning to a draft`. - An `Attachment:` line: carried into the summary exactly as written. - `--prove`: `${CLAUDE_SKILL_DIR}/references/prove.md`, read before the first round and followed for every round. The switch stays out of the summary. Each path under the repository's `.temp/` that the arguments name (a `findings.md`, a mockup) becomes one line `Attachment: `, unless the conversation already carries it. A path elsewhere gets none. ```! "${CLAUDE_PLUGIN_ROOT}/scripts/switch-text.sh" github.issues "${CLAUDE_SKILL_DIR}" issues-input ``` ```! "${CLAUDE_PLUGIN_ROOT}/scripts/switch-text.sh" branching.""mode "${CLAUDE_SKILL_DIR}" branching-start ``` ## Returning to a draft A landed plan carrying a specification and not one task block, or a `roadmap.md`, that the user points at: read `${CLAUDE_SKILL_DIR}/references/resume.md` first and follow it. ## The interview Size the scope before the first round. One coherent capability, or an estimated 30 plan tasks or fewer: interview it whole. A larger scope ("build the whole application"): read `${CLAUDE_SKILL_DIR}/references/split.md` before any detail question and follow it. The conversation and the repository already hold answers: never ask what they settle. Open with one line naming what you take as settled, so a misreading is corrected early. When nothing is open, go straight to `## Done`. Ask in rounds, in prose, never through `AskUserQuestion`: - One message carries every decision whose prerequisites are settled. A decision depending on one still open waits for a later round. - Number each decision, then its options by it (decision 2: `2.1`, `2.2`, `2.3`, a branch `2.1.1`). Give each decision three options, concrete, the recommendation first, labelled `[Recommended]:` and worded so a plain "yes" accepts it. - A decision needing a repository fact: dispatch `Agent` with `subagent_type: Explore`, no `model:`, a prompt naming the fact. Ask the decisions that do not need it now; only the questions that need it wait. Read no code yourself. - Challenge weak reasoning out loud: an answer contradicting the code or an earlier answer is said plainly and asked again. - A decision about how a screen looks or flows, with no `Attachment:` line naming a file under `.temp/viber/prototype/`: offer under its options to see it as a prototype first. On yes, invoke the `viber:prototype` skill with the screen change in one line, the decisions taken so far included; its hand-off returns here with its `Attachment:` line and the interview resumes at the next open decision. - Skip anything a competent implementer decides on its own. > **Decision 2: does the export include archived records?** > [Recommended]: **2.1 Include them** - matches what a full export implies. Trade-off: a larger file. > 2.2 Exclude them - smaller, but drops data a reader may expect. > 2.3 Ask at export time - adds a step to every export. > > **Decision 3: ...** > > Answer per decision (2.1 / 3.2 ...), or "yes" to take every recommendation. Cover, in order: 1. Problem and who has it. 2. Done-condition: the observable behaviour that proves it, which becomes the acceptance criteria. Never propose an end-to-end test or running one: `/viber:e2e` writes them after the build. Carry such a request into the summary only when the user asks in their own words. 3. Boundaries: what this change does not touch. 4. Solution requirements: compatibility, data, performance, deadlines. 5. Unknowns: what neither of you knows yet, and how it gets resolved. Solution shape comes last and only where the user holds an opinion; the spec shape and the design belong to the planner. Simple language in the user's own language, no abbreviation, every name written out. Refer back to an option by what it was, never by its number alone. ## Done Stop when you can state, without guessing: the problem, the acceptance criteria, what is out of scope, the binding constraints, and for every unknown its way to resolve it, with no question left open. Show that as a summary under 15 lines and ask for confirmation through one `AskUserQuestion`: `Confirm` or `Correct`, the correction typed in its free-text field (nothing typed: ask in prose what to correct). A change that alters a screen, with no `Attachment:` line naming a file under `.temp/viber/prototype/`, adds `Prototype first`: invoke `viber:prototype` as above, then confirm again. The summary closes on the draft mode when the user asked for one: a request to stop at a specification is the user's alone, never offered. On a correction, fix the summary and confirm again. On confirmation, run `"${CLAUDE_PLUGIN_ROOT}/scripts/skill-part.sh" "${CLAUDE_SKILL_DIR}" "done"` once and follow its output. A non-zero exit: report its stderr reason and stop.