bossbuild 0.97.0

package/stages/L0-quickstart/template/.claude/skills/canvas/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: canvas
+description: Pressure-test an idea as a humane business — Ajesh Shah's Humane Product Canvas as the spine, with Lean/Lenny-style commercial prompts folded into each cell. Filled just-in-time (a few cells at a time), it's the Quickstart→MVP graduation gate. Usage - /canvas [IDEA-NNN]
+---
+
+# /canvas — pressure-test the idea (humanely)
+
+The just-in-time mentor that shows up once an idea has legs. Built on **the Humane Product Canvas
+(by Ajesh Shah)** — values-first — with sharp Lean/Lenny business prompts folded into each cell so
+the idea is both *humane* and *viable*.
+
+It is **a snapshot, not a final blueprint.** Answers evolve as insight grows. Don't rush to fill
+boxes — sit with the hard questions, sketch, talk, revisit. A half-filled canvas with a sharp
+riskiest-assumption beats a fully-filled canvas of guesses.
+
+When the canvas is reasonably filled and the **riskiest assumption has a validation plan**, the idea
+is ready to `boss unlock mvp`.
+
+## How to run it
+
+1. Pick the idea: `[IDEA-NNN]` if given, else the most active idea in `docs/ideas/`.
+2. Open (or create) `docs/ideas/IDEA-NNN-canvas.md` from the template below.
+3. **Don't interrogate.** Ask about 2-4 cells at a time, starting with the most uncertain. Pull
+   answers from the idea's "Current shape" + capture log; only ask what's missing.
+4. Leave `_(not yet)_` on anything unknown — blanks are honest signal, not failure. Re-run anytime.
+5. After each pass, name the **single riskiest assumption** and propose **one experiment this week**
+   to test it. Write both in. That's the heartbeat of incubation.
+6. When most cells are filled + the top risk has a validation plan, mark it **Done!** (below) — name
+   what became real — then offer `boss unlock mvp`.
+
+## The canvas template
+
+```markdown
+---
+id: IDEA-NNN-canvas
+type: canvas
+owner: pm
+status: drafting
+version: 0.1
+updated: {{today}}
+---
+
+# Humane Product Canvas — <Idea title>
+
+> A snapshot, not a blueprint. Revisit as insight grows.
+
+## 1 · Human Foundation
+_Who you serve, the tension they carry, the value you promise._
+
+| Cell | Humane prompt | Sharpen with |
+|---|---|---|
+| **People** | Who are you designing for & what matters to them? | Who *exactly* has the painful problem? Be specific — not "everyone." |
+| **Problem** | What real human tension are you solving? | Is it urgent, frequent, expensive, or emotionally painful? What do they use *today* instead (current alternatives)? |
+| **Promises** | What emotional / relational value will it deliver? | The sharp promise: "We help X do Y without Z." |
+
+## 2 · Product Expression
+_How it shows up in a life, how people engage, how it sustains itself._
+
+| Cell | Humane prompt | Sharpen with |
+|---|---|---|
+| **Story** | How does your product show up in someone's life? | What changed that makes this newly possible or urgent (insight / why now)? What's the smallest compelling workflow that solves it (solution)? |
+| **Modes of Engagement** | How do people interact with your product in a humane way? | Does it respect time, attention, autonomy, data? Why are you the right team/product to win (unique advantage)? |
+| **Business Model** | How will you sustain this without compromising your promise? | Who pays, how much, why is it worth it? How do the first 100 find you (acquisition)? What makes usage compound (growth loop)? |
+
+## 3 · Stewardship
+_Impact, risks, and the values that guide decisions._
+
+| Cell | Humane prompt | Sharpen with |
+|---|---|---|
+| **Metrics** | What does meaningful success look like — for people and planet? | Real pull: activation, retention, conversion, willingness to pay. **And the regenerative ones, weighted as seriously:** what people *learn* or gain in well-being, what makes the venture more *resilient* over time — growth that renews, not just extracts. |
+| **Risks & Harms** | What could unintentionally go wrong? Who might be harmed or excluded? | Rank the assumptions that could kill the idea. Be honest about harm at scale. |
+| **Build or buy?** _(for tool-shaped ideas)_ | Is the honest move to *build* this — or would using/buying something that already solves it serve the person better? | Only ask for internal-tool / process-automation ideas (Jason Fried, 2026: most people want the problem *gone*, not a system to maintain). For a genuine product venture, building **is** the move — skip this cell. The humane answer is sometimes "don't build it yourself." |
+| **Principles** | What values will guide your decisions? | The non-negotiables you'll hold even when it's costly. |
+
+## Incubation heartbeat
+- **Riskiest assumption:** _(the one most likely to be fatal and least proven)_
+- **Experiment this week:** _(the smallest test to prove/disprove it)_
+- **What result would change the plan?** _(decide before you run it)_
+```
+
+## Done! — the graduation moment
+
+When the canvas holds up — most cells filled with real answers (not `_(not yet)_` placeholders) and the
+**riskiest assumption has a validation plan** (an experiment + what result would change the plan) — the
+idea has crossed a real threshold: it's *done enough to build*. Most founders blow right past this and
+just start coding. Don't. This is the conscience's **affirming** voice — the counterpart to "what does
+this prove?" — and you mark it in two beats:
+
+1. **Arrival.** Name what became real. Where did they start, and what's solid now — a specific person, a
+   real tension, a sharp promise, the one bet that could sink it *with* a way to test it? Say it plainly
+   and let it land. This isn't praise; it's acknowledging the idea grew up.
+2. **Next doorway.** Point at what's next without rushing: `boss unlock mvp` brings the build tools and
+   the next mentors (architect, GTM). The canvas keeps — they're free to sit with it.
+
+In BOSS's voice (the warm register — still spare; tune by ear, don't paste verbatim):
+
+> *"Worth stopping here a second. You came in with 'an app that plans meals' — now there's a specific
+> person, a tension that's real, and the one bet that could sink it, with a way to test it this week.
+> That's the idea becoming real. When you're ready, `boss unlock mvp` brings the build tools. No rush —
+> the canvas keeps."*
+
+A threshold, not a finish line: "done" here means *ready for the next thing*, and the canvas keeps
+evolving as you learn. Never force it — a half-filled canvas with a sharp riskiest assumption is a fine
+place to sit; mark it Done only when it's genuinely earned, not as a box to tick.
+
+## Rules
+
+- Humane-first. The Risks & Harms cell is not optional polish — surface real harm honestly, even when inconvenient.
+- Just-in-time, not all-at-once. Blanks are data; never fabricate answers to look complete.
+- Snapshot, not blueprint — expect it to change; bump `version` when it meaningfully shifts.
+- The canvas informs the decision to build; it never replaces actually talking to the people you serve.
+- Credit the framework: Humane Product Canvas by Ajesh Shah.

package/stages/L0-quickstart/template/.claude/skills/comprehend/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: comprehend
+description: AI-native scaffold tailoring — read what BOSS can actually understand about this project (the captured idea, the source material, or the adopted repo) and tailor the scaffold to it non-destructively, plus seed the venture brain with an honest first read so the conscience has continuity from day one. Augments the deterministic template scaffold; never replaces it. Opt-in via `boss new --ai` / `boss adopt --ai`. Usage - /comprehend
+---
+
+# /comprehend — tailor the scaffold to what BOSS understands
+
+The deterministic scaffold (the `stages/L{0..3}` templates) is the same for every project — that's the
+point: it's the reversible, diffable base. `/comprehend` is the **augmentation**: it reads what's
+actually here and tailors that base to *this* venture, so BOSS starts from understanding instead of a
+generic copy.
+
+> **The guardrail (IDEA-022 Track 3 — read this first):** everything `/comprehend` does is **additive
+> and reversible** — plain-text writes the founder can diff and `git revert`. It **never** deletes or
+> rewrites the deterministic scaffold; it fills in placeholders and seeds the brain. A model-generated
+> scaffold you can't inspect is exactly what BOSS warns founders against. If it can't be diffed, it
+> doesn't ship. Run only when `aiNative` is set (`boss new --ai` / `boss adopt --ai`) or the founder
+> asks; otherwise the plain template is correct.
+
+## When to run it
+
+- Right after `boss new --ai <idea>` (once there's a captured idea / source) or `boss adopt --ai` (the
+  existing repo is the material).
+- Any time later, to re-tailor after the understanding has grown (it re-reads and updates, idempotent).
+
+## What it reads (what BOSS can honestly understand)
+
+In order of strength — use whatever exists, say what you used:
+1. **An adopted repo** (`boss adopt --ai`) — read the code, README, structure, deps (use the wide
+   context; this is the strongest signal). Infer what it is, who it's for, what stage it's at.
+2. **Captured idea + source** — `docs/ideas/*.md` + anything under `docs/source/` (`/import`/`/boss`
+   pulled it in).
+3. **Nothing yet** — if there's no idea and no repo, say so and stop: *"Nothing to comprehend yet —
+   run `/boss <your idea>` or `/import` first, then come back."* Don't invent understanding.
+
+## What it does (all additive, all reversible)
+
+1. **Fill the project overview** — replace the `_TBD_` overview placeholder in **`AGENTS.md`** (the
+   host-neutral file) with a real, honest 2–4 line read of what this is, who it's for, and the stage
+   it's at. Mark anything you're unsure of as an open question, not a claim.
+2. **Seed the venture brain** — write the *first* dated read into `.boss/brain/read.md` (create it):
+   a short, first-person, **honest** standing summary of what you understand and — crucially — **what
+   you don't know yet** (the questions a real conversation would answer). Then stamp it:
+   `boss brain record --headline "<one line>"`. This is what gives the conscience continuity from day
+   one (it can now voice *with* this read — IDEA-022 Track 4). Honor the brain's must-nots: no
+   flattery, no diagnosing the founder, no certainty the material doesn't support; if thin, say less.
+3. **Suggest the disciplines that fit** (recommend, don't auto-apply) — based on what you read, name
+   the 1–3 optional disciplines worth turning on, and why: AI in the path → `/ai-first-init`; UI
+   accumulating → `/design-tokens-init`; untrusted input / regulated data → opt into `secrets-guard` +
+   `/red-team`; a target user worth modeling → `/persona`. The founder confirms each.
+4. **Show your work** — end with a 3-line summary of exactly what you wrote (which files), so it's
+   obvious what to keep or revert. *"I tailored AGENTS.md's overview, seeded the brain with a first
+   read, and suggested `/ai-first-init`. All of it is in your working tree — diff or revert anything."*
+
+## Cohort-aware
+- `first-product` / `non-tech-founder` — plain language; frame it as "I read what's here and wrote down
+  what I understand — correct me where I'm wrong."
+- `eng-builder` / `returning-founder` — terse; lead with the inferred stage + the open questions; make
+  the diff-and-revert affordance explicit up front.
+- `domain-expert` — flag that domain stakes aren't fully in training data; your read is a starting
+  point, their expertise outranks it.
+
+## Rules
+
+- **Augment, never replace.** The deterministic scaffold is the base; you fill and seed, you don't
+  rewrite. Never touch the template skills/agents/hooks.
+- **Inspectable + reversible or it doesn't ship.** Everything is a plain-text write in the working
+  tree. Show what you wrote.
+- **Honest understanding only.** Read what's there; mark guesses as guesses; "I don't know yet" is a
+  valid (and valuable) output. No invented depth — that's the fortune-cookie failure the brain forbids.
+- **Recommend disciplines, don't impose them.** Principle #2 (just-in-time): suggest what fits, the
+  founder turns it on.

package/stages/L0-quickstart/template/.claude/skills/decide/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: decide
+description: Record a load-bearing decision as a durable DEC-NNN record — Context / Decision / Why / a cheap Falsifier (what would prove this wrong, and by when) / Consequences, stamped with who decided (founder vs AI-suggested-ratified vs AI-autonomous) and how reversible it is. The rationale future-you (and a cofounder who wasn't in the room) can read instead of guessing — and the falsifier makes finding out you were wrong cheap and scheduled. Lighter than an RFC, denser than a commit message. Usage - /decide <the decision, or describe it>
+---
+
+# /decide — the decision record
+
+Most decisions vanish. The diff shows *what* changed; the chat where you chose it scrolls away. Six
+weeks later someone — future-you, or a cofounder — finds the choice and faces two bad options: blindly
+accept it, or blindly change it. Neither knows *why*. A decision record fixes that: it captures the
+**reasoning**, not just the outcome.
+
+This is an ADR (architecture decision record), kept light. Use it for the calls that are **load-bearing
+or hard to reverse** — which idea to pursue, which stack, which market, how equity/ownership splits, a
+constraint you're committing to. Skip it for the small two-way-door choices you can undo in a minute
+(those belong in `/log` as a one-line note).
+
+## When to reach for it
+
+- A choice you'll be asked to justify later, or that you'd regret silently reversing.
+- A **one-way door** (Bezos): expensive or impossible to undo. These *always* deserve a record.
+- A decision a **cofounder** needs to see and could later want to discuss — ownership, direction, who
+  owns what. (In a team, the record is the thing both can point at instead of misremembering.)
+
+If it's a reversible two-way door, don't ceremonialize it — a `/log` line is enough.
+
+## How to run it
+
+1. **Resolve the decider** (the one named accountable person — the "DRI"). Get their GitHub handle:
+
+   ```bash
+   gh api user --jq '.login' 2>/dev/null || git config user.name
+   ```
+
+   Use it as `@<login>`. If neither resolves, leave `@you` — never fabricate a name. Also set **how the
+   call was made** in `decided_by`: `founder` (a human chose it), `ai-suggested-ratified` (the model
+   proposed it, a human signed off), or `ai-autonomous` (the model decided and acted). This makes
+   over-delegation of load-bearing calls *visible* — it's where automation bias quietly enters.
+
+2. **Pick the next number.** Look in `docs/decisions/` for the highest `DEC-NNN`; add one. First one is
+   `DEC-001`. Create the directory if it doesn't exist.
+
+3. **Write `docs/decisions/DEC-NNN-<short-slug>.md`:**
+
+   ```markdown
+   ---
+   id: DEC-NNN
+   type: decision
+   owner: "@<github-login of the decider>"
+   decided_by: founder        # founder | ai-suggested-ratified | ai-autonomous
+   status: decided
+   created: {{today}}
+   reversibility: reversible | costly | one-way
+   revisit_by: <YYYY-MM-DD>   # optional — the "by when" of the Falsifier below
+   # supersedes: DEC-MMM      # only if this replaces an earlier decision
+   ---
+
+   # DEC-NNN — <the decision, in one line>
+
+   ## Context
+   What's true that forced a choice? The constraints, the options on the table, what's at stake.
+
+   ## Decision
+   What we're doing. One or two plain sentences. If there were named contributors to the call beyond the
+   decider (pairing, a cofounder who weighed in), name them here — credit the thinking.
+
+   ## Why
+   The reasoning. Why this over the alternatives. Name the alternative you rejected and what would change
+   your mind. (For `costly`/`one-way` calls, weigh the real options: considered · chosen · why-not.)
+
+   ## Falsifier — what would prove this wrong, and by when?
+   The cheapest signal you were wrong, with a date. *"If signups don't move by July, X was wrong."*
+   This is the load-bearing field: naming who decided and who's accountable **is not enough** — the real
+   bottleneck is the *cost of finding out later* that the call was wrong. A falsifier makes the check cheap
+   and scheduled (mirror the date into `revisit_by:`). **Required for `costly`/`one-way`; encouraged for
+   `reversible`.**
+
+   ## Consequences
+   What this commits you to, what it rules out, what to watch. If `reversibility` is `costly`/`one-way`,
+   say what the exit would cost.
+   ```
+
+4. **Fill from what the founder gave you.** If they only have the one-liner, write Context + Decision and
+   leave **Why** as a single honest question prompt rather than inventing rationale. Blanks are honest;
+   fabricated reasoning is worse than a gap.
+
+5. **Scale the ceremony to `reversibility` — never block, just match the rigor:**
+   - **`reversible`** (undo in minutes) — keep it to a line or two. The bar isn't "is this provably right?"
+     but **"is it safe enough to try?"** (the consent question — it gives a non-technical cofounder honest
+     language to agree to a reversible call without fully evaluating the technical detail). A falsifier is
+     encouraged, not required. Don't ceremonialize a two-way door.
+   - **`costly` / `one-way`** (real switching cost / effectively permanent) — **require the Falsifier**
+     (what would prove this wrong, by when) and **weigh the alternatives** in `## Why` (considered · chosen
+     · why-not). These are the calls worth the extra minutes.
+
+6. **If `decided_by` is `ai-suggested-ratified` or `ai-autonomous` AND it's `costly`/`one-way`, ask one
+   skeptical question — then stop.** *"This came from the model — what's the one thing you'd check before
+   you can't undo it?"* Disposition (a moment of skepticism) catches more than any process; install it at
+   the single moment it matters. **It's a prompt, never a gate** — forcing verification backfires (it raises
+   the odds people rubber-stamp). Record their answer in the Falsifier; if they wave it off, that's their
+   call — note it and move on.
+
+## Superseding, not editing
+
+A decision record is a **historical fact** — it was true when made. Don't rewrite it when you change your
+mind. Instead: write a **new** `DEC` with `supersedes: DEC-MMM`, and flip the old one's `status:` to
+`superseded`. The chain *is* the story of how your thinking evolved — keep it readable, don't erase it.
+
+## What this is not
+
+- Not an approval gate. `/decide` records a decision; it never blocks one. (BOSS's conscience may *surface*
+  a tension; it never picks the decision for you — and with cofounders, it never takes a side.)
+- Not a cap table or a legal instrument. A `DEC` can record *that* you agreed equity splits 60/40 with a
+  4-year vest — it does not compute the split, and it is not legal advice. For ownership/equity/vesting,
+  the record is the conversation you had; **a real attorney is the authority.**
+- Not for every choice. Over-record and the log rots. Reserve it for the load-bearing and the one-way.
+
+## Why it's worth the two minutes
+
+The decisions you don't write down are the ones that cause the worst fights and the slowest re-litigation
+— solo (with your future self) and especially with a cofounder. A short, dated, attributed record is the
+cheapest insurance there is against "wait, why did we do it this way?"

package/stages/L0-quickstart/template/.claude/skills/feedback/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: feedback
+description: Send feedback about BOSS itself back to the people who build it — a bug, a confusion, a wish, a "this got in my way." User-initiated and transparent: it shows you exactly what it will send (and the small bit of context attached) before anything leaves your machine, then files it as a GitHub issue upstream (or gives you a prefilled link to paste). Never background telemetry. Usage - /feedback [what's on your mind]
+---
+
+# /feedback — tell BOSS's makers what's working and what isn't
+
+BOSS is an alpha built in the open. The fastest way it gets better is you saying *"this confused me"*
+or *"I wish it could…"* — in the moment, without leaving your work to go find a form.
+
+**This skill is the one and only feedback path, and it is always your move.** BOSS does not watch you,
+does not phone home, does not collect usage in the background. Nothing leaves this machine unless you
+read it and say yes. (That's not a nicety — it's the principle: a tool that helps founders build well
+must itself behave well. See `PRINCIPLES.md`.)
+
+## 0. Orient (silent)
+
+Read `.boss/manifest.json` for the BOSS version + current mode — that's the only context worth
+attaching, and you'll show it to the founder before sending. Don't read anything else; this isn't a
+diagnostics dump.
+
+## 1. Get the feedback
+
+- If the founder typed something after `/feedback`, that's it.
+- If not, ask **one** open question: *"What's on your mind — a bug, something confusing, a wish, or
+  something that got in your way? A sentence is plenty."*
+- Don't interrogate. One round. Take what they give you.
+
+## 2. Draft it — and show it before sending
+
+Compose a short issue. Title = a tight one-liner. Body =
+- **What they said** (their words, lightly cleaned up — don't editorialize).
+- **Context** (the *only* thing attached, and you state it plainly): `BOSS <version> · <mode> mode ·
+  <OS>`. Nothing else — no file contents, no paths, no transcript.
+
+Then **show the founder the full title + body** and ask: *"Send this to BOSS's repo as a public GitHub
+issue? It'll be visible at github.com/ajeshh/BlueprintOS. Yes / edit / keep it local."*
+
+- **Yes** → step 3.
+- **Edit** → take their changes, re-show, re-ask.
+- **Keep it local** → write it to `.boss/feedback.log` in this project (append, dated) and stop. Tell
+  them where it went. Their call is final.
+
+## 3. Send it (only on an explicit yes)
+
+Try the direct path first:
+
+```bash
+gh issue create --repo ajeshh/BlueprintOS --title "<title>" --body "<body>"
+```
+
+- **Success** → give them the issue URL. Done. Thank them in one line, no fawning.
+- **`gh` missing or unauthed** → don't block. **Fall back:** print a ready-to-paste link —
+  `https://github.com/ajeshh/BlueprintOS/issues/new?title=<urlencoded>&body=<urlencoded>` — and the
+  plain body, so they can open it in a browser and submit with one click. Also append to
+  `.boss/feedback.log` so they keep a copy either way.
+
+## Rules
+
+- **User-initiated only. Never automatic.** There is no hook, no loop, no background send. If you ever
+  feel tempted to "just collect a bit of telemetry," that's the line BOSS exists not to cross
+  (`docs/ideas/IDEA-021`). Don't.
+- **Show before send. Consent is the gate.** The founder sees the exact title + body + the one line of
+  context before anything is filed. No silent attachment of paths, code, or transcript.
+- **Public issue = say so.** Filing on a public repo means the text is public. State that plainly so
+  the founder doesn't paste anything private by surprise.
+- **Never block on tooling.** No `gh`, no auth, offline — the prefilled-link fallback always works.
+- **Thank, don't grovel.** One sincere line. Then back to their work.

package/stages/L0-quickstart/template/.claude/skills/import/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: import
+description: Bring existing material into this project — point at a file, a folder, or a URL (Word doc, Google Doc, Obsidian note, PDF, slide deck, online reference) and BOSS pulls a durable copy into docs/source/ and folds it into your idea. Use it during spin-up or anytime later to add to a captured idea. The on-ramp for "I already jotted this somewhere." Usage - /import <path-or-url> [more paths/urls] [IDEA-NNN]
+---
+
+# /import — bring your own material in
+
+The idea you're building usually exists *before* the project folder does — in a Word doc, a Google
+Doc, an Obsidian vault, a PDF, a deck, a link. This skill is the on-ramp: **point at it, BOSS pulls it
+in.** No retyping, no "where do I even put this."
+
+This is the deliberate, add-material counterpart to `/boss` (which ingests during first spin-up).
+Run `/import` anytime — including well after the idea is captured — to add more sources to it.
+
+## 0. Orient (silent)
+
+Read, in order:
+- `.boss/manifest.json` — current stage.
+- `docs/ideas/INDEX.md` and `docs/IDS.md` — existing ideas + the next free `IDEA-NNN`.
+- If the founder named an `IDEA-NNN`, read that idea doc — you're adding to it, not starting over.
+
+Don't announce these reads.
+
+## 1. Collect the sources
+
+Take everything the founder pointed at — files, folders, URLs, in any mix:
+- **Local files** — `.md`, `.txt`, `.pdf` (read it), `.docx` (extract the text), Obsidian notes, slide
+  decks. Read each.
+- **A folder** — read the text-bearing files in it; don't recurse into binaries you can't parse.
+- **URLs** — a Google Doc share link, a published page, a reference. Fetch each.
+- **Nothing given** — ask once: *"Point me at what you've got — a file path, a folder, or a URL (or a
+  few). I'll pull them in."*
+
+If a source can't be read (image-only PDF, an auth-walled link, an unsupported binary), **say so plainly
+and skip it** — don't guess at its contents. Name what you skipped and why.
+
+## 2. Snapshot — the project owns a copy
+
+For each source you successfully read, write a durable copy into `docs/source/` (create the folder if
+absent):
+- **A file** → `docs/source/<original-filename>` (copy it in).
+- **A URL** → `docs/source/<slug>.md` with the source URL on the first line, then the fetched text.
+
+This is the "create a dupe" the founder asked for: the idea survives if the original moves, changes, or
+goes offline. **Snapshot first, interpret second** — don't paraphrase away the source.
+
+## 3. Fold into the idea
+
+- **Adding to an existing idea** (`IDEA-NNN` named, or only one idea exists): append a dated entry to
+  that idea's capture log noting what you pulled in and the 1-2 lines it changes about the idea's shape.
+  Update the "current shape" at the top if the new material genuinely sharpens or shifts it. Reference
+  the snapshot paths under `docs/source/`.
+- **No idea yet** (a fresh project, founder ran `/import` instead of `/boss`): this is really spin-up —
+  hand off to `/boss`'s shaping. Read all sources, then create `docs/ideas/IDEA-001-<slug>.md` (frontmatter
+  `id`, `type: idea`, `owner: pm`, `status: ready`) seeded from the material, and update
+  `docs/ideas/INDEX.md`. Don't make the founder run a second command to see their idea captured.
+
+## 4. Wrap up — and point at the next step
+
+Tight summary: what you pulled in (and into which `IDEA-NNN`), where the copies live (`docs/source/`),
+anything you skipped and why. **End with the single next step** — usually `/canvas <IDEA-NNN>` if the
+idea now has legs, or "keep adding with `/triage` or `/import`" if it's still forming. Close on the
+action, not the recap.
+
+## Rules
+
+- **Snapshot before interpret.** The project owns a copy of every source you read. Never summarize a
+  source away without first saving it.
+- **Skip honestly.** If you can't read something, say so and skip it — no hallucinated contents.
+- **Don't over-capture.** A pasted one-liner doesn't need a `docs/source/` file; a real document does.
+- **One idea, many facets.** Multiple sources for one idea fold into one `IDEA-NNN` — don't spawn an
+  idea per file.
+- **Capture, don't build.** Like `/boss`, this is intake — don't start implementing the product here.

package/stages/L0-quickstart/template/.claude/skills/persona/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: persona
+description: Build your app's target-user persona from your idea, grow it from what you know + online research + any real user research you drop in, and consult it as an agent voice — both to guide product decisions ("would my user want this?") and to QA your builds ("how would she react to this screen?"). A pre-filter that sharpens the questions you take to real users; never a replacement for talking to them. Usage - /persona [derive | enrich <slug> | consult <slug> "question"]
+---
+
+# /persona — your user's voice, as a thinking tool
+
+The first thing every app has is a *user*. If you're building a chore tracker for moms, the first
+persona is **a mom managing a household** — and most product decisions get easier when you can ask her.
+`/persona` builds that voice from your idea, grows it as you learn more, and lets you consult it: to
+**guide** what you build, and to **QA** what you built.
+
+> **What it is:** a sharpening tool — a fast, honest *pre-filter* that helps you write better questions
+> and catch obvious misses. **What it isn't:** a real user. A synthetic persona will tend to like your
+> idea more than a real person would, and it can't know what it wasn't told. Use it to get *ready* for
+> real conversations (Rob Fitzpatrick's *Mom Test*), never to skip them. BOSS will say this once, then
+> get out of the way.
+
+## Modes
+
+### `derive` (default when no persona exists yet)
+Read the captured idea (`docs/ideas/*.md`) + its canvas if one exists. Propose the **one primary
+target user** (start with one; secondary users come later). Write `docs/personas/<slug>.md`:
+
+```
+who         — one line ("a working mom, 30s-40s, running a household of 4")
+context     — when/where/why they'd reach for this (the situation, not demographics)
+jobs        — what they're actually trying to get done (jobs-to-be-done, not features)
+pains       — what's hard / annoying / failing about how they do it today
+values      — what they care about, what would make them trust or abandon a tool
+what we DON'T know yet — the open questions a real conversation would answer (be honest + specific)
+---
+Evidence ledger:  synthetic <N%> · real <N%>   (starts 100% synthetic)
+Notable refactors: (dated bullets when evidence reshapes the persona)
+```
+
+Name what's a guess. The `what we don't know` block is the most valuable part — it's the interview
+guide for when you talk to a real one.
+
+### `enrich <slug>` — grow it from evidence
+Offer the four sources; fold in what they choose; **shift the ledger** (real grows, synthetic shrinks):
+- **Q&A with you** — ask what *you* already know about this user (you chose this problem for a reason —
+  you often know a lot). Your knowledge is real evidence (n≥1).
+- **Online research** — run `deep-research` to ground the archetype in real-world data about this
+  group. Better than a guess; still averaged, so mark it synthetic-leaning.
+- **Drop in real research** — point at interviews / surveys / notes (a file, folder, or URL); ingest
+  via `/import` and fold the real signal in. **This is the strongest source** — it shrinks the
+  synthetic share fastest. (A UX researcher dropping a study here is the ideal case.)
+- **Passive** — read the idea / canvas / build for who-the-user-is clues already on record (no new
+  tracking; the work already names them).
+
+Each enrich pass: update the persona body, add a dated `Notable refactor` bullet, re-weight the ledger.
+
+### `consult <slug> "question"` — ask the voice (both directions)
+Answer **in the persona's voice**, and run in whichever direction fits:
+- **Guidance** (before/during build): *"would she want X? how would she react to this flow?"*
+- **QA** (after build): react to a screen / feature you built — structured (first feeling · what she'd
+  do · where she'd bounce · what she'd want different), so you can compare versions over time.
+
+Every consult: **balance interest with concerns** (don't just cheerlead), **name what the persona
+can't know** (the blind spots from the ledger), and **close with the caveat** — *"that's a synthetic
+read at <real%> real evidence; go ask <N> real ones before you bet on it."*
+
+## The discipline (why this is honest and not snake oil)
+
+- **Pre-filter, never validation.** A persona consult is a sharpened guess. The conscience uses it to
+  push you *toward* real contact (`/canvas` "who's served", `/pretotype` demand test, the Mom Test),
+  never as a substitute. If you're about to build for real on persona signal alone, that's the moment
+  BOSS asks: *have you talked to one?*
+- **Synthetic shrinks as real grows.** The ledger is visible on purpose — you always see how much of
+  "your user" is real evidence vs. BOSS's average. The persona is the same artifact across its life;
+  today's version is just early in it.
+- **Name the blind spots.** LLMs reflect internet-averages and can't *do* behavior — only describe it.
+  Higher-stakes or niche users (regulated, marginalized, very specific) are exactly where the synthetic
+  read misses most; say so loudly for those.
+
+## Cohort-aware
+- `first-product` / `non-tech-founder` — plain language; the deliverable is "a clear picture of who
+  you're building for + the questions to go ask them," not a research artifact.
+- `eng-builder` / `returning-founder` — terse; lead with the `what we don't know` gaps and the
+  cheerleading caveat; they know personas can lie.
+- `domain-expert` — flag hard that domain stakes (clinical/legal/financial) aren't in training data
+  with enough specificity; their own expertise outranks the synthetic read.
+
+## Rules
+- **One persona first.** Start with the primary user; add segments only when the idea clearly serves
+  distinct users.
+- **Real beats synthetic, always.** Dropped-in research and your own knowledge outweigh online
+  averages, which outweigh pure derivation. Weight the ledger accordingly.
+- **Caveat every consult.** The go-talk-to-a-real-one line is non-negotiable — a persona that forgets
+  it's synthetic is the pseudo-app trap with a friendly face.
+- **It's both.** The same persona guides decisions *and* QAs builds — point it forward or back.