@iamu-dev/iamu 0.2.0-beta.1 → 0.2.0-beta.10

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

@@ -1,192 +1,270 @@
 ---
 name: iamu-setup
-description: Set up a project for iamu — scaffold the iamu/ tree, capture domain context, and seed primary personas. Stops after context and initial personas; use iamu-new to draft scenarios next.
+description: Set up a project for iamu — scaffold the iamu/ tree, capture domain context, seed primary persona, and draft inaugural scenario. Ready to run immediately via iamu-run.
 generatedBy: __IAMU_VERSION__
 ---
 
-Set up a project for scenario-driven walkthroughs — all local, no cloud required. Scaffolds an `iamu/` tree under your project root, analyzes the repo to compose a project-context summary, persists that context to `iamu/context.yml`, seeds 1–2 baseline personas to the casting panel, and optionally links to Iamu cloud. Stops there. Scenario creation belongs to `iamu-new`.
+Set up a project for scenario-driven walkthroughs — all local, no cloud required. Scaffolds an `iamu/` tree under your project root, analyzes the repo to compose a project-context summary, persists context to `iamu/context.yml`, seeds 1 primary persona into `iamu/personas/`, and drafts 1 inaugural scenario into `iamu/scenarios/`. Ready to run immediately with `iamu-run`.
 
 Model reminder (internal — users never type these): `capability → scenario → run → finding`. A scenario is the runnable thing — a situation narrative bound to a persona. Capabilities are optional labels that group scenarios. `iamu-new` creates scenarios; `iamu-run` executes them; `iamu-findings` reviews results.
 
 What this skill does, end to end:
 
 - **Scaffold** — `iamu/` tree on disk via `iamu init`. No login, no cloud.
-- **Understand** — read the repo to identify domain, primary user archetypes, and any applicable regulations (if present).
-- **Capture & Seed** — persist to `iamu/context.yml` and scaffold 1–2 primary personas into `iamu/personas/` (or defer if user prefers).
+- **Understand** — read the repo to identify domain, primary user archetypes, reachable routes, and testability.
+- **Propose & Scaffold Baseline** — present a single unified briefing: domain narrative, primary persona, and inaugural scenario. On confirmation ("yes"), scaffold `context.yml`, `testability.md`, persona, outline, and scenario to disk.
+- **Next Action** — point directly to `iamu-run <scenario>` with copy-pasteable execution command.
 - **Cloud (optional)** — offer to link to Iamu cloud for sharing / teams / managed runs via `iamu auth login`. User can accept, skip, or defer.
 
-This skill does NOT create capabilities, situation outlines, or scenarios. That is what `iamu-new` is for. Setup = context + casting panel seeding.
-
 $ARGUMENTS
 
 ## Steps
 
 ### 1. Scaffold the iamu/ tree
 
-Run `iamu init` in the terminal. Pass a project name when the user names one explicitly; otherwise the tool derives it from the directory basename.
-
-```
-iamu init [project-name]
-```
-
-The command scaffolds `iamu/config.json`, entity subdirs, `.runs/`, `.cache/`, `.gitignore`.
-
-- If `iamu/` was already present, existing files are not overwritten. Treat as success and continue.
-- Error containing "legacy `.iamu/` layout" → tell the user to remove the legacy directory, then re-run.
-
-On fresh scaffold, introduce iamu first:
+Check whether `iamu/config.json` already exists:
 
-> **iamu** tests your product as realistic personas and reports what works, what doesn't, and how to fix it. I'll analyze your codebase now to understand the domain and propose primary personas.
-
-On re-run (already scaffolded), skip the intro — the user knows what iamu is.
+- **If already scaffolded (`iamu/config.json` exists):** Do not re-run `iamu init`. Introduce the step concisely and proceed directly to Step 2:
+  > Analyzing your codebase now to map the domain, primary persona, and first test scenario.
+- **If not yet scaffolded:** Run `iamu init [project-name]` in the terminal (pass a project name if the user named one explicitly; otherwise omit). The command scaffolds `iamu/config.json`, entity subdirs, `.runs/`, `.cache/`, `.gitignore`.
+  Introduce iamu first:
+  > **iamu** tests your product as realistic personas and reports what works, what doesn't, and how to fix it. I'll analyze your codebase now to map the domain and prepare your first test scenario.
+- **Error containing "legacy `.iamu/` layout"** → tell the user to remove the legacy directory, then re-run.
 
 ### 2. Understand the project
 
-Explore the codebase automatically — do NOT ask the user what files to read. Build a **project-context summary** (3–6 sentences) the downstream skills will use as grounding. Read the following files when present:
-
-- `README.md`, `CLAUDE.md`, `agents.md`
-- Package manifests — `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`
-- Routes, API schemas, navigation, components, auth/user models
-- `docs/`, OpenAPI / JSON / GraphQL schemas, `src/`-style source directories
-- `.env.example`
-
-Extract these key dimensions:
-
-1. **Domain** — what does this product do, in one phrase (mandatory).
-2. **Jurisdiction** — country / region (optional — only include if evident from codebase/locale/terms or if legal frameworks apply).
-3. **Regulations (`governed_by`)** — specific compliance frameworks (AFS 2023:2, GDPR, HIPAA, ISO 27001, etc.). **Strictly optional:** only extract if the repo explicitly references legal or compliance standards. Most software is not in a regulated domain; do NOT invent or guess regulations for standard SaaS/apps.
-4. **Primary Personas** — determine the 1–2 most important user archetypes that stress-test this product (e.g. End User / Consumer vs. Admin / Operator, or First-Timer vs. Power User). Propose:
-   - Name and Role
-   - Disposition / perspective (patience level, tech literacy, primary friction triggers)
+Explore the codebase automatically — do NOT ask the user what files to read. Extract domain and environment facts strictly from code:
+
+1. **Framework & Dev Server Port Detection:**
+   - Inspect package manifests: `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`.
+   - Read framework configs to reliably extract default dev ports:
+     - `vite.config.*` / `svelte.config.*` → default port 5173
+     - `astro.config.*` → default port 4321
+     - `next.config.*` / Rails / Remix → default port 3000
+     - `wrangler.toml` / `wrangler.json` (Cloudflare Workers/Pages)
+     - `docker-compose.yml`
+   - Read `.env`, `.env.development`, `.env.local` for `PORT`, `VITE_PORT`, `NEXT_PUBLIC_APP_URL`.
+   - If unsure, check port reachability on common ports (3000, 5173, 8080, 4321).
+2. **Reachable Entry Route:**
+   - Scan page directories: `app/**/page.tsx`, `pages/**/*.tsx`, `src/routes/**/*.svelte`, React Router `routes.ts`/`App.tsx`.
+   - Pick a concrete static route (e.g. `/incidents/new`, `/cart`, `/checkout`), NOT an unresolved parameterized path (`/projects/:id`) unless seed fixture IDs are known.
+3. **Auth & Persona Access:**
+   - Inspect auth route guards (`middleware.ts`, ProtectedRoute, session hooks).
+   - Identify dev bypass (`MOCK_AUTH`), test accounts/fixtures, persona switcher, or public access.
+4. **Domain Narrative & Cast:**
+   - Read `README.md`, `CLAUDE.md`, docs, OpenAPI / JSON schemas, user models.
+   - Extract 1 primary protagonist and 2 secondary actors from real user roles.
+   - **STRICT REGULATION RULE:** Never infer regulations from industry keywords. Only include `governed_by` if the codebase explicitly references specific legislation or statutory standards. Non-regulated software is the default — omit `governed_by` entirely if absent.
+5. **Primary Persona Rigor:**
+   - Follow `iamu/.prompts/persona.md`: no generic marketing adjectives ("tech-savvy", "coffee lover"). Ground in working physical reality, time pressure, and concrete diagnostic friction / bounce conditions. True whether the product exists or not.
+
+Synthesize the project into a cohesive, substantive narrative (1–2 paragraphs):
+- What the product fundamentally is, its primary domain, and who uses it.
+- Key user journeys and operational characteristics (e.g. mobile floor use, audit deadlines).
+- Market and geography (only if evident).
+
+Audit testability and target environment:
+Inspect `package.json` dev scripts, existing mock harnesses (MSW, seed scripts), auth route guards (`middleware.ts`, ProtectedRoute, session hooks), and page/route directories (`app/`, `src/routes/`). Use these findings to populate `iamu/testability.md`.
+
+**If there is no code (greenfield, design phase, or test sandbox):** do NOT interrogate the user with a multi-part survey or ask for dev auth plumbing. Ask for a single entry point:
+> No local codebase detected. To seed context, provide one of:
+> - A target URL (staging, production, or docs — e.g., `https://app.example.com`)
+> - A one-sentence description of what this product does
+> - Or type `"sandbox"` to seed a pre-configured B2B SaaS demo
+
+**Autonomous Enrichment:**
+- **URL provided:** Fetch or search public marketing/docs for that site. Automatically extract the substantive narrative, core user journeys, and key actors.
+- **One-sentence summary provided:** Immediately expand into a full substantive narrative using domain knowledge.
+- **"sandbox" provided:** Seed a standard B2B SaaS narrative with Admin and End-User roles.
+
+### 3. Present Unified Baseline Proposal (Single Confirmation Gate)
+
+Present the discovered domain context, 1 primary persona, and 1 inaugural scenario in a single scannable briefing.
+
+Do NOT wrap the briefing in a markdown code fence (` ``` `). Output normal markdown so the user's terminal formats bolding and layout cleanly.
+Do NOT split this into multiple sequential permission questions. Present the complete baseline package at once:
+
+Discovered Project Context:
+  Domain:       <domain name, e.g. workplace safety management>
+  Scope:        <Jurisdiction or "Standard Web App / Unregulated">
+  Cast:         <Primary Protagonist> (protagonist), <Secondary Actor 1>, <Secondary Actor 2>
+  Target:       <target_url, e.g. http://localhost:5173> (Dev Command: `<dev_command, e.g. pnpm dev>`)
+  Auth Access:  <How walker assumes role, e.g. "Dev persona switcher" or "Public">
+
+<1 cohesive paragraph: what the product fundamentally is, who actually uses it, and its core operational reality. No marketing fluff, no hedging, and no tech stack trivia.>
+
+Baseline Test Proposal (WYSIWGW Spec-Sheet):
+  Persona:      <Name> (<Role / Title>)
+                • Reality: <Working context, physical habits, tenure>
+                • Friction: <Diagnostic friction, skepticism, bounce trigger>
+  Situation:    <Outline Title>
+                • Tension: <Core problem-space tension in X vs Y format — no UI button names>
+                • Evaluation Checkpoint: <Concrete binary yes/partial/no question for evaluator>
+  Walk Surface: Entry: `<entry_path>` | Target: `<target_url>`
+  Walker Brief: "<2–3 sentence first-person test brief that will be written verbatim to disk. States immediate intent and constraints before opening tool. Zero UI terminology.>"
 
-Also collect silently (write to `context.yml` but do NOT present for confirmation):
-- **Actors** — all identified roles and their responsibilities.
-- **Glossary** — domain-specific terms (helps persona language fidelity).
-- **Access** — if the project documents how to switch user or role in a dev or test environment (a persona switcher, seeded accounts, a storage key), record that mechanism as `access`. It is what lets a walkthrough run as the persona instead of as whoever happens to be signed in. Never record passwords or tokens — name where they live.
-
-Do NOT collect architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
-
-**If there is no code (greenfield, design phase):** ask the user: what does this project do, who are the users, what domain, and are there any specific regulations?
-
-**Present a short proposal for confirmation:**
-
-```
-Your project: <domain> (<jurisdiction if known>)
-[Regulations: <reg1>, <reg2>]  <-- omit line entirely if none
-
-Proposed primary personas:
-  1. <Name> (<Role>) — <Key disposition & perspective>
-  2. <Name> (<Role>) — <Key disposition & perspective>
-
-Confirm context & scaffold these personas? (yes / edit / suggest-others / skip-personas)
-```
-
-Wait for the user to confirm or correct before writing. The user only needs to verify domain and choose whether to accept, edit, suggest alternative personas, or defer persona creation.
+---
 
-### 3. Capture domain context and scaffold personas
+**Interactive Decision:**
+Prompt the user to confirm or adjust the baseline:
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - Question: "Scaffold this iamu test baseline?"
+  - Options:
+    1. "[Recommended] Scaffold baseline and prepare first walkthrough"
+    2. "Switch perspective: Walk as <Secondary Actor 1 Name> (<Role>)"
+    3. "Adjust domain context, target URL, or persona details"
+- Otherwise (in CLI or text-only environments), present them as an enumerated list:
 
-Persist the step-2 summary as structured fields so every scenario draft and walkthrough loads the same grounding. Downstream skills auto-read this file.
+Scaffold this iamu test baseline?
+  1. [Recommended] Scaffold baseline and prepare first walkthrough
+  2. Switch perspective: Walk as <Secondary Actor 1 Name> (<Role>)
+  3. Adjust domain, target URL, or persona details
 
-1. Check existing state by reading `iamu/context.yml` directly.
+Press Enter to accept [1], select 2, or tell me what to adjust:
+(Treat empty Enter or return as Option 1)
 
-2. **Branch on what you find:**
+### 4. Scaffold the Test Suite Atomically
 
-   - **Empty / not present** → synthesize structured fields from step 2 and write `iamu/context.yml` with your file-editing tool (not a shell heredoc — it avoids permission prompts).
-   - **Present but thin** (missing domain) → show what's missing and offer to fill it. User picks **refine** or **replace**.
-   - **Present and complete** (domain set) → show summary and ask "Use as-is, refine, or replace?" Default is **skip**.
+When the user selects Option 1 (or confirms):
 
-3. **Write `iamu/context.yml`**:
+1. **Write `iamu/context.yml`**:
+   Derive the structured frontmatter fields (`domain`, `actors`, `jurisdiction`, `governed_by`) from the confirmed text, and write `iamu/context.yml` with your file-editing tool. Put structured fields in frontmatter and the substantive narrative in the markdown body below the `---`:
 
    ```yaml
    ---
    schema_version: 1
-   domain: e-commerce storefront
-   # jurisdiction: EU / US          # optional
-   # governed_by:                    # strictly optional - omit if not regulated
-   #   - name: GDPR
+   domain: workplace safety management
+   # jurisdiction: Sweden / EU          # optional
+   # governed_by:                       # strictly optional - omit if not regulated
+   #   - name: AFS 2023:2
    #     authority_level: regulation
    actors:
      - name: Store Admin
        role: Manages catalog, inventory, and order fulfillment
      - name: First-Time Buyer
        role: Explores products, adds to cart, and checks out
-   glossary:
-     - term: SKU
-       definition: Stock Keeping Unit
+     - name: Customer Support Agent
+       role: Handles order discrepancies, refunds, and customer inquiries
    access: >-
      No login in dev. In the page, set localStorage "dev_persona" to the
      persona's access value and reload.
    ---
+
+   <The substantive 1–2 paragraph project description and core user journeys>
    ```
 
    Rules:
    - `domain` — one line. Mandatory.
+   - Body markdown (below `---`) — substantive description and user journeys. Downstream skills read this as extended grounding.
    - `jurisdiction` — optional. Only if evident or relevant.
-   - `governed_by[]` — strictly optional. Order by authority (legislation > regulation > standard > company_policy > guideline > informational). Specific names, not categories. Omit entirely if no regulations apply.
-   - `actors[]` — all identified roles and their responsibilities.
-   - `glossary[]` — domain terms only. Thin is better than padded with generic terms.
-   - `access` — optional. Only what the docs actually say; leave it out rather than guess. `iamu-run` fills it in on the first walk if it is missing.
+   - `governed_by[]` — strictly optional. Order by authority. Omit entirely if no regulations apply.
+   - `actors[]` — all identified roles and their responsibilities. Keep secondary roles here so context has cast depth.
+   - `access` — optional. Only what the docs actually say; leave it out rather than guess.
    - Do NOT add `industry` or `architecture` — these don't affect walkthroughs.
 
-4. **Scaffold confirmed personas (unless `skip-personas` selected):**
+2. **Write `iamu/testability.md`**:
+   Scaffold the target environment, dev command, auth strategy, reachable surfaces, mock harnesses, and untestable boundaries discovered from the code:
 
-   Always use the CLI to scaffold valid persona entities with schema-compliant UUIDs, slugs, and timestamps:
-   ```bash
-   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --json
-   ```
+   ```markdown
+   ---
+   target_url: http://localhost:3000
+   dev_command: <detected dev script, e.g. pnpm dev or pnpm dev:mock>
+   auth_strategy: <dev_switcher | interactive | test_accounts | public>
+   harnesses:
+     - <detected harnesses, e.g. msw, seed>
+   ---
 
-   Then open the created file (`iamu/personas/<slug>.md`) and write 2–4 sentences of background narrative into the markdown body below the frontmatter, detailing their technical habits, patience level, and specific friction triggers.
+   # Project Testability & Environment
 
-   If `iamu/context.yml` has an `access` mechanism, set the persona's `access` field in frontmatter to match an existing product account/role.
+   ## Target & Run Instructions
+   - Command: <dev command>
+   - Base URL: <target_url>
 
-   Run `iamu validate --all`.
+   ## Auth & Access Boundary
+   - <How a walker becomes this persona in dev or test mode>
 
-5. Confirm: "Context saved and personas seeded in iamu/personas/. Run `iamu-new` to draft your first scenario." (or "Context saved. Run `iamu-new` to draft your first scenario." if personas were skipped).
+   ## Reachable Surfaces
+   - <List discovered routes/entry points, e.g. /login, /dashboard, /incidents>
 
-### 4. Offer cloud link (optional)
+   ## Mocks & Data Fixtures
+   - <List existing MSW mock files, DB seed scripts, or fixture directories>
 
-Check the current state first:
+   ## Untestable Boundaries (Do Not Walk)
+   - <List un-mocked external dependencies, e.g. live Stripe charges, SMS 2FA, external SSO>
+   ```
 
-```bash
-iamu auth status --json
-```
+   Keep `context.yml` strictly about domain reality (which the Walker subagent reads), and `testability.md` strictly about developer testability and execution boundaries (which orchestrator skills read).
 
-- **`cloud_linked: true`, `authenticated: true`** → already linked. Say so in one line with the dashboard link from `iamu open --print` and skip the offer.
-- **`cloud_linked: true`, `authenticated: false`** → the project is linked but this machine has no credentials, so nothing will push. Offer `iamu auth login`; it restores credentials for the same project without asking which one.
-- **`cloud_linked: false`** → ask once:
+3. **Scaffold Primary Persona**:
+   Scaffold 1 primary protagonist into `iamu/personas/<persona-slug>.md` using the CLI:
+   ```bash
+   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<2-4 sentence narrative detailing technical habits, patience level, and specific friction triggers>" [--access "<account-or-role>"] --json
+   ```
 
-  > Want to link this project to Iamu Cloud? Every walkthrough then gets a shareable report link (screenshots and step replay), your team can triage findings together, and teammates can queue requests for you. Everything keeps working locally; `iamu auth disconnect` unlinks.
+4. **Scaffold Situation Outline**:
+   Scaffold the inaugural outline into `iamu/outlines/<outline-slug>.md` using the CLI:
+   ```bash
+   iamu new outline --name "<Outline Title>" --tension "<Core Tension>" --human-test "<Concrete yes/partial/no evaluation question>" --narrative "<2-3 sentence problem-space narrative without UI terms>" --json
+   ```
 
-Three outcomes:
+5. **Scaffold Bound Scenario**:
+   Bind the persona and outline into `iamu/scenarios/<persona-slug>--<outline-slug>.md` using the CLI:
+   ```bash
+   iamu new scenario --name "<persona-slug>--<outline-slug>" --outline "<outline-slug>" --persona "<persona-slug>" --entry "<entry_path>" --body "<Persona's first-person test brief describing what they intend to achieve>" --json
+   ```
+
+6. **Validate all entities**:
+   ```bash
+   iamu validate --all
+   ```
+
+7. **Present Completion & Immediate Next Action**:
+   Render the visual scaffolding tree and provide the direct command to run the walkthrough:
 
-- **Yes** → link it (below).
-- **Skip** → local-only project stays local-only. User can connect later by re-running `iamu-setup` or running `iamu auth login` directly.
-- **Later** → same as skip. No state change.
+   ```text
+   ✓ Scaffolding complete:
 
-**Linking:**
+     iamu/
+     ├── context.yml          [domain: <domain>]
+     ├── testability.md       [target: <target_url>]
+     ├── personas/
+     │   └── <persona-slug>.md
+     ├── outlines/
+     │   └── <outline-slug>.md
+     └── scenarios/
+         └── <persona-slug>--<outline-slug>.md
 
-1. Run `iamu auth login` (add `--url <api-url>` only if the user names a self-hosted cloud). It opens the sign-in page in the user's browser and waits up to two minutes — tell the user to approve it there. Allow the command at least 150 seconds before your shell tool times out. If your shell cannot wait that long, or runs where no browser can open (remote or container session), ask the user to run `iamu auth login` in their own terminal and tell you when it is done.
-2. **Never pick the cloud project for the user.** In a non-interactive shell with existing cloud projects, login stops after sign-in and lists them as `iamu auth login --project <id>` lines plus `--project new`. Show that list, ask which project this repository belongs to, then re-run with their choice — the stored sign-in is reused, no second browser trip. Linking pushes every local persona, scenario and finding into the chosen project; a wrong guess leaks them into someone else's.
-3. On success the output ends with `Dashboard: <url>` and, when an agent host was detected, `iamu-sync MCP server registered`. Relay both in two lines: the dashboard link, and that restarting the agent session loads the team tools (work requests, teammate-change alerts).
+   Next step:
+     Ensure your dev server is running on <target_url>, then run:
 
-If login fails (cloud unreachable, sign-in timed out), report the error in one line and continue — setup is complete without the cloud.
+       $ iamu-run <persona-slug>--<outline-slug>
+
+   Other commands when you're ready:
+   • iamu-new      Draft a scenario for a different product flow
+   • iamu-propose  Brainstorm high-risk workflows and blind spots
+   • iamu doctor   Diagnose test environment and target health
+   • iamu auth login  Link to Iamu Cloud to share run reports with your team (optional)
+   ```
 
-All three outcomes leave a usable local setup. Cloud is strictly additive.
+### 5. Cloud link (optional)
 
-### 5. How to use iamu from here
+Cloud linking is optional and non-blocking. It is recommended after executing your first walkthrough so you have run reports and findings to share.
 
-Close with one line pointing at the next step:
+If the user explicitly asks to link during setup:
+1. Tell the user: "Opening browser for Iamu Cloud login..." then run `iamu auth login`. Allow the command at least 150 seconds for the user to complete sign-in in their browser. If your shell cannot wait that long, or runs where no browser can open (remote or container session), ask the user to run `iamu auth login` in their own terminal and tell you when it is done.
+2. In a non-interactive shell with existing cloud projects, login stops after sign-in and lists them as `iamu auth login --project <id>` lines plus `--project new`. Show that list, ask which project this repository belongs to, then re-run with their choice.
+3. On success the output ends with `Dashboard: <url>` and registered MCP server.
 
-```
-Setup complete. Next: run iamu-new to draft your first scenario.
-```
+If login times out or fails:
+- "Your local project setup is 100% complete and fully functional. Personas, scenarios, outlines, and walkthroughs run locally without cloud."
+- Point to: `iamu-run <persona-slug>--<outline-slug>`.
 
 ## Guidelines
 
-- **Plumbing and casting panel seeding.** This skill scaffolds configuration and seeds 1–2 baseline personas. It does not draft situation outlines or scenarios — that belongs to `iamu-new`.
+- **Baseline is runnable immediately.** Setup scaffolds configuration, 1 primary persona, 1 outline, and 1 bound scenario. The project graduates from setup in a 100% runnable state.
+- **Clean terminal formatting.** Do not wrap agent briefings in markdown code fences (` ``` `). Use fixed column alignment for attributes and clean tree diagrams for generated files.
 - **Non-regulated software is the default.** Do not invent or force regulations (`governed_by`) on apps, developer tools, or consumer software. If the codebase has no compliance documentation, omit `governed_by` entirely.
 - **Explore automatically.** Read the codebase before asking the user anything. The user should only need to confirm or correct, not describe their own project from scratch.
-- **Context on disk is load-bearing.** Once step 3 writes `iamu/context.yml`, every downstream skill (`iamu-new`, `iamu-run`) auto-loads it. No need to pass `project_context` by hand.
-- **Handle re-runs gracefully.** An already-scaffolded project is a no-op on scaffold, a refresh on context/personas (if the user opts in), and a re-prompt on cloud link.
-- **Code-referenced vs inferred.** When drafting context in step 2, be explicit about which claims you read in the codebase vs which you inferred.
-- **Handle errors gracefully.** Unreachable file → note it, move on. Unreachable cloud (step 4) → report and let the user retry or defer.
+- **Context on disk is load-bearing.** Once step 4 writes `iamu/context.yml`, every downstream skill (`iamu-new`, `iamu-run`) auto-loads it.
+- **Handle re-runs gracefully.** An already-scaffolded project is a no-op on scaffold, a refresh on context/personas/scenarios (if the user opts in), and a re-prompt on cloud link.
+- **Handle errors gracefully.** Unreachable file → note it, move on. Unreachable cloud → report and let the user retry or defer.

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

@@ -21,24 +21,28 @@ $ARGUMENTS
 
 Do NOT use `find`, `grep`, or `cat` to dump raw `.md` files in `iamu/`. The CLI outputs clean, validated data.
 
-### 2. Format entity responses as compact tables
+### 2. Format entity responses with an executive tally and clickable links
 
-When the user asks for personas, scenarios, or findings, respond with a scannable Markdown table. Never dump full psychological profiles, vocabulary lists, or raw frontmatter unless the user explicitly asks for deep detail on one entity.
+When the user asks for project status, lead with an executive tally banner, followed by scannable tables with clickable markdown file links:
+
+```
+Project Status: <P> Personas · <S> Scenarios (<R> Tested, <U> Untested) · <F> Open Findings · <C> Capabilities
+```
 
 **Personas:**
 | Slug | Name | Role | Status |
 |---|---|---|---|
-| `elin-dahl` | Elin Dahl | Architect & first-time house owner in Falun | active |
+| [`elin-dahl`](iamu/personas/elin-dahl.md) | Elin Dahl | Architect & first-time house owner in Falun | active |
 
 **Scenarios:**
 | Slug | Persona | Outline | Status / Target |
 |---|---|---|---|
-| `replacing-windows` | `elin-dahl` | `measure-and-order` | ready |
+| [`replacing-windows`](iamu/scenarios/replacing-windows.md) | [`elin-dahl`](iamu/personas/elin-dahl.md) | [`measure-and-order`](iamu/outlines/measure-and-order.md) | ready |
 
 **Findings:**
-| # | Severity | Type | Finding | Status |
+| # | Severity | Type | Finding | File |
 |---|---|---|---|---|
-| 1 | CRITICAL | hinders | Submit fails opaquely on empty field | open |
+| 1 | CRITICAL | hinders | Submit fails opaquely on empty field | [`view`](iamu/findings/<slug>.md) |
 
 ### 3. Ignore internal templates
 
@@ -52,13 +56,16 @@ For a project-status question, add one line on the cloud from `iamu status --jso
 - **Linked, no credentials** → `Cloud: linked, but this machine has no credentials — iamu auth login.`
 - **Local-only** → `Cloud: local-only.` Nothing more; no upgrade pitch.
 
-### 5. Provide clear next steps
+### 5. Provide copy-pasteable next actions
+
+Conclude with exact copy-pasteable commands:
 
-Conclude with one concise action prompt:
-- To run a scenario: `iamu-run <scenario-slug>`
-- To propose new personas or scenarios: `iamu-propose`
-- To draft a persona or scenario directly: `iamu-new`
-- To review open findings or team requests: `iamu-findings`
-- To inspect reports: `iamu report`, or `iamu open` for the cloud dashboard (linked projects)
-- To share unpushed work with the team: `iamu sync` (linked projects)
+```
+Next actions:
+  iamu-run <scenario-slug>              # Run a walkthrough for this scenario
+  iamu-propose                          # Propose missing personas or scenarios
+  iamu-new                              # Draft a new scenario or persona
+  iamu-findings                         # Triage open findings
+  iamu open                             # Open project in cloud dashboard
+```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iamu-dev/iamu",
-  "version": "0.2.0-beta.1",
+  "version": "0.2.0-beta.10",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "UNLICENSED",
@@ -54,19 +54,22 @@
   "devDependencies": {
     "@types/node": "^22.0.0",
     "@vitest/coverage-v8": "^4.1.11",
+    "google-auth-library": "^11.1.0",
     "tsup": "^8.5.1",
     "typescript": "^5.8.0",
     "vitest": "^4.1.11",
-    "@iamu-dev/protocol": "0.1.0",
     "@iamu-dev/local-store": "0.1.0",
+    "@iamu-dev/protocol": "0.1.0",
     "@iamu/tsconfig": "0.1.0"
   },
   "scripts": {
-    "build": "tsup && tsc -b tsconfig.build.json --emitDeclarationOnly && node scripts/copy-assets.mjs",
+    "build": "tsup && tsc -b --force tsconfig.build.json --emitDeclarationOnly && node scripts/copy-assets.mjs",
     "clean": "node -e \"fs.rmSync('dist', { recursive: true, force: true }); fs.rmSync('tsconfig.tsbuildinfo', { force: true }); fs.rmSync('tsconfig.build.tsbuildinfo', { force: true })\"",
     "typecheck": "tsc --noEmit",
     "test": "vitest run",
     "test:coverage": "vitest run --coverage",
+    "eval:walkthroughs": "vitest run --config vitest.benchmark.config.ts",
+    "eval:gemini": "node dist/eval/gemini-eval-cli.js",
     "pack:dry-run": "npm pack --dry-run"
   }
 }