@iamu-dev/iamu 0.2.0-beta.9 → 0.3.0-beta.0

package/dist/templates/skills/iamu-new.md

@@ -1,6 +1,6 @@
 ---
 name: iamu-new
-description: Draft a scenario or standalone persona from a specific intent — create the situation + persona + brief, or scaffold a standalone persona into the casting panel. Use when the user already knows WHAT or WHO to test. If they're exploring what or who to test or need suggestions, use iamu-propose first.
+description: Use when creating or authoring a new scenario, persona, or situation narrative with a known testing intent, or when the user wants to test a specific user flow or situation.
 generatedBy: __IAMU_VERSION__
 ---
 
@@ -8,8 +8,8 @@ You are a brainstorming partner, not a form filler. Your job is to help the user
 
 **You bring:**
 - Understanding of the domain from `iamu/context.yml` (actors, jurisdiction, regulations if applicable)
-- Knowledge of the codebase from prior exploration (what features exist, what flows are built)
-- Awareness of the gap between "what the product supports" and "what real users actually need to do"
+- What the product is for, from `iamu/context.yml` and `iamu/capabilities/` (titles and descriptions)
+- Awareness of what real users actually need to do, whether or not the product supports it today
 
 **The user brings:**
 - Knowledge of which area they want to test (or nothing — you propose)
@@ -17,6 +17,8 @@ You are a brainstorming partner, not a form filler. Your job is to help the user
 
 Scenarios are written in **problem-space only** — they describe human situations, not UI flows. No screen references, no button names, no feature names. The scenario says "a shift leader needs to hand off open incidents under time pressure" — the walkthrough discovers whether the product supports that.
 
+**Drafting is not staging.** Do not read the product's source code, routes, `iamu/testability.md` or `iamu explore` output while drafting, and do not decide entry pages, starting data, accounts or mocks. Knowing what the product already does pulls a draft toward what was built and away from what the person needs. Getting the product into the state a situation needs happens when the scenario first runs: `iamu-run` stages it (start page, expected data, approximation guidance, which account the persona uses) before the walk.
+
 **Methodology prompts:** Before drafting, read the methodology files. These contain the quality standards for each artifact:
 - `iamu/.prompts/persona.md` — how to write a durable persona
 - `iamu/.prompts/outline.md` — how to write a situation outline
@@ -45,68 +47,105 @@ Determine the mode based on `$ARGUMENTS` and user intent:
      iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --json
      ```
   5. Write the persona's background narrative and test expectations as the markdown body.
-  6. If `iamu/context.yml` has an `access` mechanism, set the persona's `access` field to match an existing product account/role.
-  7. Run `iamu validate --all`.
-  8. Summarize: persona created in `iamu/personas/<slug>.md`. Prompt user: "You can now pair `<slug>` with a scenario draft via `iamu-new`, or propose situations for them via `iamu-propose`." Stop here for standalone persona requests.
+  6. Run `iamu validate --all`.
+  7. Summarize: persona created in `iamu/personas/<slug>.md`. Prompt user: "You can now pair `<slug>` with a scenario draft via `iamu-new`, or propose situations for them via `iamu-propose`." Stop here for standalone persona requests.
+
+- **Fast-Path Scenario mode** (when intent, topic, or a candidate from `iamu-propose` is provided or referenced from conversational context, e.g. `iamu-new "checkout friction"`, "let's do candidate 2", "draft that", "option 1"):
+  If the user refers to a candidate proposed in the current session, resolve that candidate's details directly from the conversation history.
+  Do NOT drag the user through multiple question modals. Skip Step 2 entirely!
+  Jump directly to Step 3 and present the **Complete Scenario Spec-Sheet** (Situation + Bound Persona + Evaluation Checkpoint + Walker Brief) for **1-click / 1-key acceptance**.
 
-- **Scenario mode** (e.g. `iamu-new "checkout friction"`, or no `$ARGUMENTS`):
-  Proceed through steps 2–7 below.
-  Inspect `iamu/personas/` (`iamu list personas`) first. If personas already exist in the casting panel (e.g. seeded during `iamu-setup`), deliberately frame scenario seeds around those existing cast members to build longitudinal test history, rather than inventing new personas.
-  If the user gives a direction, ground it in the codebase: what capabilities exist in this area? What flows are built? This helps you propose scenarios that test what's actually there, not what's imagined.
+- **Exploratory Scenario mode** (no arguments or broad exploration):
+  Proceed through Step 2 (Propose complete scenario bundles) and Step 3.
+  Inspect `iamu/personas/` (`iamu list personas`) first. If personas already exist in the casting panel (e.g. seeded during `iamu-setup`), deliberately frame scenario proposals around those existing cast members to build longitudinal test history, rather than inventing new personas.
+  If the user gives a direction, ground it in the domain: who in `context.yml` deals with this, how often, under what pressure, and what goes wrong for them? Propose what those people need to get done, not what the product happens to offer.
 
-### 2. Propose scenario seeds
+### 2. Propose Complete Scenario Bundles (Exploratory Mode)
 
-Propose 2–3 scenario seeds as scannable numbered cards. Do NOT use multi-column markdown tables with full prose sentences (they wrap awkwardly and break borders in terminal viewports). If personas exist in `iamu/personas/`, explicitly indicate which existing cast member pairs with each seed concept.
+Present 2–3 scannable scenario proposals. Each proposal MUST bundle the situation narrative, bound persona (prioritizing existing cast members), and human evaluation checkpoint:
 
 ```
-1. <Title> (<Type> · <existing persona slug or context actor>)
+1. <Title> (<Primary Capability>)
+   • Persona: <Persona Name> (<Role>) — Reused from cast / New candidate
    • Tension: <1 concise sentence on the human or organizational tension>
-   • Stress-tests: <What this reveals about the product>
+   • Evaluation Checkpoint: "<Concrete binary yes/partial/no question>"
 
-2. <Title> (<Type> · <existing persona slug or context actor>)
+2. <Alternative Title> (<Capability>)
+   • Persona: <Alternative Persona Name> (<Role>)
    • Tension: <1 concise sentence>
-   • Stress-tests: <What this reveals about the product>
-
-3. <Title> (<Type> · <existing persona slug or context actor>)
-   • Tension: <1 concise sentence>
-   • Stress-tests: <What this reveals about the product>
+   • Evaluation Checkpoint: "<Concrete binary question>"
 ```
 
-Ask the user: "Which seed should we develop (1–3), or suggest another angle?"
+**Interactive Decision:**
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - Question: "Scaffold this scenario for walkthrough?"
+  - Options:
+    1. "[Recommended] Scaffold '<Bundle 1 Title>' as <Persona 1 Name>"
+    2. "Switch persona: Walk as <Alternative Persona Name> (<Role>)"
+    3. "Select alternative: '<Bundle 2 Title>' as <Persona 2 Name>"
+    4. "Customize situation, checkpoint, or brief"
+- Otherwise (in CLI or text-only environments):
+
+Scaffold this scenario for walkthrough?
+  1. [Recommended] Scaffold '<Bundle 1 Title>' as <Persona 1 Name>
+  2. Switch persona: Walk as <Alternative Persona Name> (<Role>)
+  3. Select alternative: '<Bundle 2 Title>' as <Persona 2 Name>
+  4. Customize situation, checkpoint, or brief
 
-### 3. Develop the situation
+Reply '1' to scaffold [default], select 2-3, or type adjustments:
 
-Once the user picks a direction (e.g. "1"), draft the situation concisely.
+*Execution Flow:*
+- **Selecting Option 1 (or hitting Enter):** Proceed IMMEDIATELY to Step 6 (Persist everything). Zero intermediate question modals.
+- **Selecting Option 2:** Present the persona switcher (Step 4) then persist.
+- **Selecting Option 3:** Swap primary bundle and prompt to persist.
+- **Selecting Option 4 / typing adjustments:** Expand into Step 3 to refine details before persisting.
 
-Do NOT ask an open-ended question like "What should this walkthrough focus on?" and then immediately answer it yourself in the same turn. Instead, propose an opinionated research focus question and one concrete binary (yes/partial/no) human checkpoint directly in the draft for the user to confirm or adjust.
+### 3. Develop the situation (Scenario Spec-Sheet)
 
-Do NOT use markdown blockquote syntax (`>`), which renders as stray `|` pipe characters in terminal frontends. Keep the narrative capped at 2–3 punchy sentences (problem-space only, zero UI terms).
+In Fast-Path mode or when customizing, present the complete scenario as a structured, scannable Spec-Sheet before creating anything. Every field shown here is written verbatim to disk on confirmation:
 
-Present the draft to the user as a structured, scannable block **before creating anything**:
+Do NOT output markdown header hashes (`#`, `##`, `###`) or markdown blockquote syntax (`>`), which render as stray hashes or `|` pipe characters in terminal frontends. Keep the narrative capped at 2–3 punchy sentences (problem-space only, zero UI terms).
 
 ```
-### Situation Draft: <Name>
+Scenario Spec-Sheet: <Outline Title>
 
-Narrative: <2–3 sentences describing the human situation, time pressure, or physical reality without mentioning software UI>
-Tension: <Legitimate colliding needs or "None">
-Focus Question: <Proposed research focus question, e.g. "Can a frontline worker submit an urgent slip hazard report in under 60 seconds without abandoning floor duties?">
-Human Checkpoint: <Concrete binary yes/partial/no question scored at evaluation>
+Situation & Stakes:
+  Narrative:    <2–3 sentences problem-space only, zero UI terms>
+  Tension:      <Colliding needs in X vs Y format or "None">
+  Evaluation Checkpoint: <Concrete binary yes/partial/no question scored at evaluation>
 
 Roles with Stakes:
-• <Role 1>: <Stake>
-• <Role 2>: <Stake>
+  • <Role 1>: <Stake>
+  • <Role 2>: <Stake>
+
+Persona & Brief:
+  Persona:      <Existing slug from panel OR new candidate: Name (Role)>
+  Friction:     <Diagnostic friction trigger and bounce risk>
+  Walker Brief:
+    "<First-person brief in persona voice (2–3 sentences). Describes what they intend to achieve before touching the product. Written verbatim to scenario markdown body.>"
+```
 
-Execution Preconditions (resolved at iamu-run):
-• Assumed State: <What records/data should exist, e.g. "Department with existing risk register containing open hazards">
-• Squint Guidance: <How the walker should approximate if exact records are missing, e.g. "If no packaging hazard exists, select any physical safety hazard and proceed with delegation">
-• Reachable Surface: <Entry route matched against iamu/testability.md, e.g. "/incidents/new">
+**Interactive Draft Confirmation:**
+- If your environment provides an interactive user-prompt tool, invoke it:
+  - Question: "Scaffold scenario '<Outline Title>'?"
+  - Options:
+    1. "[Recommended] Scaffold scenario and prepare walkthrough"
+    2. "Switch persona: Walk as <Alternative Persona> (<Role>)"
+    3. "Adjust situation, checkpoint, or brief"
+- Otherwise (in CLI or text-only environments):
 
-If the situation requires an un-mocked endpoint or missing data fixture to be walkable, offer to scaffold the missing MSW handler (e.g. in `src/mocks/handlers.ts`) or fixture file directly in the codebase before finalizing.
-```
+Scaffold scenario '<Outline Title>'?
+  1. [Recommended] Scaffold scenario and prepare walkthrough
+  2. Switch persona: Walk as <Alternative Persona> (<Role>)
+  3. Adjust situation, checkpoint, or brief
+
+Reply '1' to scaffold [default], select 2, or type adjustments:
 
-Ask the user: "Ready to test this draft, or would you like to refine the focus question, preconditions, or circumstances? (Enter to accept, or type adjustments)"
+*Selecting Option 1 or hitting Enter proceeds IMMEDIATELY to Step 6 (Persist everything).*
 
-### 4. Pick or propose personas
+### 4. Pick or swap personas (on demand)
+
+Triggered only when the user selects "Switch persona", when exploring standalone personas, or when no existing persona fits:
 
 **Check existing personas first:**
 Inspect `iamu/personas/` (`iamu list personas`). If an existing persona in the casting panel is a natural fit for this situation, propose them first to build longitudinal test history:
@@ -124,7 +163,14 @@ If no existing persona fits, or if testing an uncovered perspective is needed, p
    • Why this tests something different: <Unique perspective or workflow divergence>
 ```
 
-The user picks one (or more — each becomes a separate scenario). "New" to propose different candidates. "Skip" to save as draft without a persona.
+**Interactive Persona Selection:**
+- If your environment provides an interactive user-prompt tool, invoke it with the candidates:
+  - Question: "Which persona should walk this scenario?"
+  - Options:
+    1. "[Recommended] Bind existing persona: <slug> (<role>)" (if one fits)
+    2. "Create candidate: <Name> (<Role>)"
+    3. "Leave as draft (no persona bound yet)"
+- Otherwise, prompt: "Pick a persona (1–N), 'new' to propose candidates, or 'skip' to save as draft without a persona."
 
 ### 5. Classify into capabilities
 
@@ -145,36 +191,36 @@ Use CLI commands to scaffold entities with valid frontmatter. The CLI generates
 
 **1. Capability** (only if new):
 ```bash
-iamu new capability --name "Incident Reporting" --description "What staff can do when something goes wrong on shift" --json
+iamu new capability --name "Incident Reporting" \
+  --description "What staff can do when something goes wrong on shift" \
+  --area "Operations" \
+  --json
 ```
+Leave `--paths` out: route prefixes are product structure, not part of the situation. Without them, `iamu explore coverage` matches pages whose first path segment equals the capability slug; add `paths` to the capability file later, outside drafting, if that groups the area's pages wrong.
 
 **2. Outline** (the situation — problem-space, no UI references):
 ```bash
-iamu new outline --name "Busy shift handoff" --json
-```
-After creation, use Edit to add fields to the frontmatter: `primary_capability`, `narrative`, `tension`, `human_tests`, `situation_roles`. The outline body stays empty.
-
-Example frontmatter to add via Edit:
-```yaml
-primary_capability: incident-reporting
-narrative: "A shift leader needs to hand off a set of open incidents..."
-human_tests:
-  - id: ht-1
-    question: "Could the incoming leader act immediately without asking clarifying questions?"
+iamu new outline --name "Busy shift handoff" \
+  --capability incident-reporting \
+  --additional-capabilities team-access \
+  --tension "Incident details are fragmented across multiple logs while shift time expires" \
+  --narrative "A shift leader needs to hand off a set of open incidents to the incoming supervisor." \
+  --human-test "Could the incoming leader act immediately without asking clarifying questions?" \
+  --json
 ```
+The `--capability`, `--additional-capabilities`, `--tension`, `--narrative`, and repeatable `--human-test` flags populate outline frontmatter directly. The outline body stays empty. If specialized fields like `situation_roles` are needed, edit the generated frontmatter.
 
 **3. Persona** (if user picked a new persona to scaffold):
 ```bash
 iamu new persona --name "Maria Gomez" --role "Site Safety Coordinator" --disposition "Time-pressured, prefers physical paper over complex forms" --json
 ```
-The `--role` and `--disposition` flags populate frontmatter directly. If `iamu/context.yml` has an `access` mechanism, also set the persona's `access` to the account, role, or switcher key that matches this persona in the product — check what users the product actually has rather than inventing one; leave it out if nothing fits and say so. Write the persona's background narrative and test expectations as the markdown body.
+The `--role` and `--disposition` flags populate frontmatter directly. Leave `access` out — which product account the persona uses is decided when the scenario is staged in `iamu-run`. Write the persona's background narrative and test expectations as the markdown body.
 
 **4. Scenario** (the binding):
 ```bash
-iamu new scenario --name "maria-gomez--busy-shift-handoff" --outline busy-shift-handoff --persona maria-gomez [--entry /path/on/the/product] [--state-description "<Assumed state description>"] [--state-approximation "<Squint guidance for walker>"] --body "<First-person brief in persona voice (3–5 sentences)>" --json
+iamu new scenario --name "maria-gomez--busy-shift-handoff" --outline busy-shift-handoff --persona maria-gomez --body "<First-person brief in persona voice (3–5 sentences)>" --json
 ```
-When the situation begins on a specific page (the persona follows a link from a video, an email, a search result), add `--entry /path/on/the/product` — the run starts there instead of the home page.
-`--outline` is required. `--persona` is optional (omit for drafts). Pass `--state-description` and `--state-approximation` if preconditions were defined in step 3 to populate the scenario's `state:` frontmatter automatically.
+`--outline` is required. `--persona` is optional (omit for drafts). Do not pass `--entry` or the `--state-*` flags here: where the walk starts and what data it needs are set when `iamu-run` stages the scenario. If the situation begins somewhere specific (the persona follows a link from an email, a video, a search result), say so in the narrative or brief in the persona's words; staging turns that into a start page.
 
 For drafts (no persona): omit `--persona`, omit `--body`.
 
@@ -200,7 +246,7 @@ Run `iamu validate --all` to verify all entities before reporting done.
 
 - **Brainstorm, don't fill forms.** Propose varied seeds. Challenge assumptions. The best scenarios are ones the user hadn't considered.
 - **Problem-space only.** Scenarios describe human situations — never UI, screens, buttons, or features. The walkthrough discovers whether the product supports the situation.
-- **Ground in the codebase.** Use your knowledge of what the product actually does to propose scenarios that stress-test real capabilities. But keep the scenario language product-agnostic.
+- **Ground in the domain, not the codebase.** Start from what the persona's week demands. A situation the product cannot support yet is a good scenario: the walk shows the gap with evidence.
 - **Present before creating.** Show situation, personas, and capability to the user before writing files.
 - **Scenario vocabulary.** Say "scenario" in output, never "outline" or "capability."
 - **Multiple personas surface different problems.** A manager, a field worker, and an auditor will find completely different issues in the same situation. Propose personas that test the product differently, not personas that are cosmetically varied.
@@ -209,4 +255,4 @@ Run `iamu validate --all` to verify all entities before reporting done.
 - **Capability is quiet.** High-confidence matches fire silently.
 - **Slug references are load-bearing.** Write referenced entities before the entities that reference them.
 - **Validate before done.** Always run `iamu validate --all` after writing entities.
-- **Use CLI for scaffolding.** `iamu new <type>` creates valid frontmatter with UUIDs. Use Edit to add additional fields and body content after scaffolding.
+- **Use CLI for scaffolding.** `iamu new <type>` creates valid frontmatter with UUIDs. Pass flags (`--role`, `--disposition`, `--capability`, `--tension`, `--human-test`) directly instead of manual YAML editing.

package/dist/templates/skills/iamu-propose.md

@@ -1,6 +1,6 @@
 ---
 name: iamu-propose
-description: Suggest scenarios or personas for testing. Use BEFORE iamu-new when the user wants to know what or who to test — e.g. "what should we test?", "propose new personas", "who else should we test with?", "suggest scenarios for checkout", "propose personas".
+description: Use when the user asks what or who to test, requests scenario or persona suggestions, seeks brainstorming on test coverage, or asks "what should we test next?".
 generatedBy: __IAMU_VERSION__
 ---
 
@@ -25,15 +25,13 @@ Every persona candidate must have **diagnostic friction**:
 
 ## Prerequisites
 
-Before starting, check that `iamu/context.yml` exists and has content. If it is missing or empty, stop:
-
-> No project context found. Run `iamu-setup` first — proposals need domain grounding to avoid shallow thinking.
+Before starting, check that `iamu/context.yml` exists and has content. If it is missing or empty, stop and inform the user: "No project context found. Run `iamu-setup` first — proposals need domain grounding to avoid shallow thinking."
 
 If context is thin (few actors, sparse notes), say so upfront — "your context has few actors and sparse notes; proposals will be shallow. Consider enriching context first."
 
 ## Steps
 
-### 1. Load domain context & testability boundaries
+### 1. Load domain context
 
 Read `iamu/context.yml`. Extract and hold:
 - **Domain + industry** — what world does this product operate in?
@@ -41,20 +39,19 @@ Read `iamu/context.yml`. Extract and hold:
 - **Governed_by** — regulations and standards (if applicable). These create structural tensions in regulated domains.
 - **Notes body** — extended context, often containing workflow descriptions, pain points, organizational dynamics.
 
-Read `iamu/testability.md` (if present) to enforce execution boundaries:
-- **Reachable surfaces:** Ground candidates in reachable routes. Avoid proposing scenarios for product areas with no navigable surfaces.
-- **Untestable boundaries:** Strictly avoid proposing scenarios in flows documented as untestable (e.g. un-mocked live payment gateways, SMS dispatch, third-party SSO).
-- **Mocks & Fixtures:** Note which candidates require existing database seeds or mock handlers.
+**Stay in the problem space.** Proposals come from the domain, not from the product's code, routes, pages or test setup. Do not read source files, `iamu/testability.md`, or `iamu explore` output while proposing, and never put a route, URL or screen into a candidate. Whether and how a situation can be set up in the product is decided when it first runs (`iamu-run` stages it), not here — a situation the product cannot support is worth walking: the persona hitting that wall is the finding.
 
 ### 2. Load existing coverage
 
 Read existing entities to understand what's already been tested:
-- `iamu/capabilities/` — what product areas exist?
-- `iamu/outlines/` — what situations are already drafted?
+- `iamu/capabilities/` — what product areas exist? Use each capability's title and description only; its `paths` are route prefixes and stay out of proposals.
+- `iamu/outlines/` — what situations are already drafted, and which capability each one covers?
 - `iamu/scenarios/` — what's already bound to personas?
 - `iamu/personas/` — who do we already have in our casting panel?
 
-Build a coverage picture: which capabilities have scenarios? Which actors from `context.yml` lack personas? Where are the gaps?
+**Find untested product areas.** A capability no outline names (as `capability` or in `additional_capabilities`) is an area no persona has been near. Treat it as a prompt for the domain question — "who in this domain needs what this area is for, and when?" — never as a place to send a persona.
+
+Build a coverage picture: which capabilities have scenarios? Which actors from `context.yml` lack personas? Which kinds of situation (routine, deadline, handover, mistake to correct) are missing? Where are the gaps?
 
 ### 3. Determine focus
 
@@ -62,7 +59,7 @@ Four entry paths based on `$ARGUMENTS`:
 
 - **Persona / Tester panel** (e.g. `iamu-propose "personas"`, `"who else should we test with?"`, `"propose new personas"`) — analyze which actors from `context.yml` lack personas in `iamu/personas/`. Focus proposals on creating durable, diagnostically biased personas for uncovered roles.
 - **Area or capability** (e.g. `iamu-propose "employee provisioning"`) — focus proposals on this area. Match against capabilities and context actors/workflows.
-- **Open-ended** (e.g. `iamu-propose`, `iamu-propose "what's missing?"`) — analyze coverage gaps across both scenarios and persona diversity. Prioritize uncovered capabilities and actors without personas.
+- **Open-ended** (e.g. `iamu-propose`, `iamu-propose "what's missing?"`) — analyze coverage gaps across scenarios and persona diversity. Prioritize untested product areas and actors without personas.
 - **Specific tension** (e.g. `iamu-propose "what happens when the safety coordinator disagrees with HR?"`) — use as seed but ground in context. Verify the tension is real (do these actors and dynamics exist in the domain?).
 
 ### 4. Present candidates (Numbered Cards)
@@ -77,21 +74,29 @@ Lead with existing coverage using clickable links, then render the candidates:
 Existing coverage: <N> scenarios ([<slug1>](iamu/scenarios/<slug1>.md), ...). Uncovered areas: <gaps>.
 
 1. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. billing-invoicing>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
 2. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. team-access>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
 3. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. incident-response>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
-Next action:
-  Type 1, 2, or 3 to scaffold via iamu-new
-  Or describe adjustments (e.g. "make #2 more time-pressured", "explore <area>")
-```
+**Interactive Candidate Selection:**
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - Question: "Which scenario candidate would you like to scaffold?"
+  - Options:
+    1. "[Recommended] Scaffold '<Candidate 1 Title>' (<Actor>)"
+    2. "Scaffold '<Candidate 2 Title>' (<Actor>)"
+    3. "Scaffold '<Candidate 3 Title>' (<Actor>)"
+- Otherwise (in CLI or text-only environments):
+Reply '1' to scaffold [default], select 2-3, or describe adjustments:
 
 #### B. When proposing Personas:
 
@@ -111,16 +116,22 @@ Existing personas: [<slug1>](iamu/personas/<slug1>.md), ... Uncovered roles from
 3. <Name> (<Actor role>)
    • Friction & Biases: <Specific friction triggers, skepticism, and bounce risks>
    • Key Expectations & Vocabulary: <Domain terms and spec requirements>
-
-Next action:
-  Type 1, 2, or 3 to scaffold via iamu-new
-  Or describe adjustments
 ```
 
+**Interactive Persona Selection:**
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - Question: "Which persona would you like to add to the casting panel?"
+  - Options:
+    1. "[Recommended] Add <Name 1> (<Actor role>)"
+    2. "Add <Name 2> (<Actor role>)"
+    3. "Add <Name 3> (<Actor role>)"
+- Otherwise (in CLI or text-only environments):
+Reply '1' to add [default], select 2-3, or describe adjustments:
+
 Ground rules for generation:
 
 - **Start from the actor's week, not the feature list.** What does this person actually do on a Tuesday? What goes wrong? What requires judgment?
-- **Use authentic domain vocabulary.** Speak in the language of the domain and the product UI (e.g., "skyddsombud" rather than generic "safety representative"), avoiding abstract test jargon.
+- **Use authentic domain vocabulary.** Speak in the language of the domain (e.g., "skyddsombud" rather than generic "safety representative"), avoiding abstract test jargon.
 - **Prefer mundane frequency over dramatic edge cases.** The scenario that happens every week reveals more than the one that happens once a year.
 - **Structural tensions come from the domain, not from product limitations.** A real tension: "the regulation requires immediate reporting but the coordinator handles 3 sites." A fake tension: "the CSV upload has a 50-row limit."
 - **Never mention the product, its UI, its features, or its limitations.** The scenario exists in the domain. The product encounter happens during the walkthrough.
@@ -130,9 +141,9 @@ Ground rules for generation:
 
 ### 5. Selection and Handoff
 
-- **User picks a scenario candidate** → hand off to `iamu-new` with the selected candidate's situation as the intent seed. Provide the full context (actor, regulatory surface, why-interesting) so `iamu-new` can ground its outline generation.
-- **User picks a persona candidate** → hand off to `iamu-new` with candidate profile (name, role, disposition, vocabulary, friction triggers). `iamu-new` can scaffold the persona standalone into `iamu/personas/` or pair them with a situation draft.
-- **User refines** → regenerate or adjust the comparison table, re-applying the philosophy tests.
+- **User picks a scenario candidate (e.g. "1" or Enter)** → Immediately invoke `iamu-new` in **Fast-Path Scenario Mode** passing the selected candidate title, actor, primary capability slug (`--capability`), tension, and evaluation checkpoint as structured arguments. Do NOT allow `iamu-new` to restart seed brainstorming. It must present the single Scenario Spec-Sheet directly for instant 1-click persistence.
+- **User picks a persona candidate** → Immediately invoke `iamu-new` in **Standalone Persona Mode** with the candidate's name, role, disposition, and friction triggers to scaffold directly into `iamu/personas/<slug>.md`.
+- **User refines** → regenerate candidates applying the requested adjustments.
 - **User rejects all** → ask what domain area or actor they want to explore. Loop back to step 4.
 
 ## Guidelines