@thebassclef/lite 1.0.4 → 1.1.0

package/dist/lite/.claude/skills/user-stories/SKILL.md

@@ -0,0 +1,268 @@
+---
+tier: lite
+name: user-stories
+description: "Produce INVEST-shaped user stories that trace back to personas, JTBDs, and value-prop-canvas entries. Backlog-intake artifact for incremental delivery. Distinct from /task-scenarios (UX narrative) and /use-case (system behavior)."
+problem: "Stories get written from developer intent not persona need. INVEST shape drifts."
+value: "INVEST-shaped stories that trace back to personas and JTBDs and value prop."
+inputs: [A feature scope plus personas ref]
+outputs: [INVEST user stories per persona, Acceptance criteria per story]
+user_invocable: true
+disable_model_invocation: false
+---
+
+# /user-stories — INVEST Backlog Intake
+
+Produce backlog-ready user stories shaped per INVEST (Independent,
+Negotiable, Valuable, Estimable, Small, Testable). Each story traces
+to a persona, a JTBD, and (when present) a value-prop-canvas entry +
+a use-case line. Backlog-intake artifact, not UX research, not
+system spec.
+
+## When to invoke
+
+- After `/personas` (and ideally `/jtbd-tasks` + `/value-prop-canvas`) have produced upstream artifacts
+- When converting an iteration scope into a tracked backlog
+- Before `/spec` and `/interaction-design` — stories scope what they cover
+
+## Distinction from adjacent artifacts
+
+Per @luminary alistair-cockburn (2024) and NN/G: **user stories ≠ task scenarios ≠ use cases**. Each is a distinct artifact with a distinct purpose.
+
+| Artifact | Purpose | Format | Primary consumer |
+|----------|---------|--------|------------------|
+| **JTBDs** | WHY (job the user is hiring the product for) | Outcome statement | PM, strategist (problem framing) |
+| **Task scenarios** (NN/G) | CONTEXT (narrative day-in-the-life with mental state, obstacles, environment) | Story prose ("Sam is stuck in traffic…") | UX researcher, `/synthetic-user` tester, designer |
+| **User stories** (this skill) | WHAT (feature/requirement for incremental delivery) | Formulaic As-a-I-want-So-that + INVEST + acceptance criteria | Developer, sprint planner |
+| **Use cases** (Cockburn) | SPEC (system behavior for a complete user goal) | Structured (begin/middle/end + extensions + pre/post) | Architect, `/decompose`, `/verify` |
+
+All four coexist. `/user-stories` does not replace any of them. It produces backlog tokens for incremental work — it intentionally splits a use-case (when one exists) into smaller, independently shippable units.
+
+## Sources read
+
+- @luminary alistair-cockburn — *Unifying user stories, use cases, and story maps* (2024). Establishes the user-story↔use-case distinction this skill is built on: stories slice use-case lines into INVEST-shaped delivery tokens. The four-artifact non-overlap (JTBD / task scenario / user story / use case) comes directly from this work.
+- Mike Cohn — *User Stories Applied* (2004). Origin of the bassclef As-a-I-want-So-that template + INVEST principles
+- Jeff Patton — *User Story Mapping* (2014). Story-as-conversation-token framing; backlog ordering via story map
+- Bill Wake — INVEST acronym (2003). Independent, Negotiable, Valuable, Estimable, Small, Testable
+- Nielsen Norman Group — *Task Scenarios in Usability Testing* (cited for the user-stories vs task-scenarios distinction)
+- Quorum #52 — original `/promote` ticket; bassclef #208 — companion
+- `.claude/skills/personas/SKILL.md`, `.claude/skills/jtbd-tasks/SKILL.md`, `.claude/skills/value-prop-canvas/SKILL.md` — upstream artifacts this skill reads
+- `standards/user-story-invest.md` — companion standard (this skill's standard; codifies INVEST validation)
+- `templates/user-story-template.md` — bassclef template
+
+## What I'm NOT reading (with reason)
+
+- `.claude/skills/task-scenarios/SKILL.md` — sibling skill in the chain. /task-scenarios is currently muddled (conflates NN/G scenarios + Agile stories + BDD). Cleanup is tracked as a separate bassclef-evolution ticket; this skill explicitly stays in its lane (backlog intake) so the boundary is clean even before /task-scenarios is refocused
+- `/use-case` skill — not yet built (filed as separate bassclef-evolution ticket). When it lands, /user-stories will read use-case lines as input; until then, it reads /jtbd-tasks output directly + falls back to scope statement
+
+## Usage
+
+```
+/user-stories                              → produce stories from current iteration goal scope
+/user-stories [ticket-ref]                 → produce from a specific ticket / spec / canvas
+/user-stories from-jtbd [JTBD slug]        → derive stories for one JTBD
+/user-stories from-use-case [UC slug]      → split a use-case into stories (when /use-case exists)
+/user-stories validate                     → audit existing stories at docs/user-stories/ against INVEST
+```
+
+## Procedure
+
+### Step 1: Resolve inputs
+
+Read upstream artifacts in this order. Halt with a useful warning if a required input is missing:
+
+1. **Personas** — `docs/personas/*.md` (preferred) or `docs/design/personas/*.md` (legacy). If none exist, run `/personas default` and proceed with operator-default (warn that stories will have weak persona grounding).
+2. **JTBDs** — `docs/design/personas/[persona]/jtbds.md` or whatever path `/jtbd-tasks` writes to. If none exist, ask the operator which jobs are in scope OR fall back to inferring from the iteration goal scope statement (warn).
+3. **Value Prop Canvas** (optional but high-value) — `docs/value-prop-canvas/*.md`. When present, the canvas's Pain-Relievers + Gain-Creators ground the `<benefit>` clause of stories.
+4. **Use case** (when /use-case exists) — `docs/use-cases/*.md`. Each story slices a use-case line; carry the line reference in the traceability block.
+
+### Step 2: Map jobs/use-case-lines to candidate stories
+
+For each JTBD (or use-case main-success line), draft candidate stories. Each story:
+
+- Has ONE persona (no "as a user" — be specific)
+- Has ONE outcome (not a list of features — split into multiple stories)
+- Has a `<benefit>` clause that traces to a VPC Gain-Creator or Pain-Reliever (when VPC exists)
+
+Format per the template (`templates/user-story-template.md`):
+
+```markdown
+### US-NNN — [imperative title]
+
+**As a** [persona slug — couple-founders, not "user"]
+**I want to** [observable, testable outcome — not internal mechanism]
+**So that** [benefit grounded in VPC entry or JTBD]
+
+**Traceability**:
+- Persona: [slug] (docs/personas/[slug].md)
+- JTBD: [job statement] (docs/design/personas/[persona]/jtbds.md#J-N)
+- VPC: [PR-N or GC-N from value-prop canvas] (docs/value-prop-canvas/[persona].md)
+- Use-case (when present): [UC-N step Xa] (docs/use-cases/[uc-slug].md)
+
+**Acceptance criteria**:
+- [ ] [observable behavior — written as a test assertion]
+- [ ] [edge case from CTA decision points or use-case extension]
+- [ ] [non-functional concern if applicable: performance threshold, accessibility, etc.]
+
+**INVEST self-check**:
+- I (Independent): [why this story can ship without others]
+- N (Negotiable): [what's flexible vs. fixed]
+- V (Valuable): [observable value to the persona]
+- E (Estimable): [Small enough to estimate confidently]
+- S (Small): [≤ N days of work]
+- T (Testable): [acceptance criteria are concrete and observable]
+```
+
+### Step 3: INVEST validation
+
+Walk every drafted story through INVEST per `standards/user-story-invest.md`:
+
+| Letter | Test | Fail signal |
+|--------|------|-------------|
+| **I**ndependent | Can ship without other stories shipping first? | If "needs X first," either resequence or merge |
+| **N**egotiable | Is this a conversation, not a contract? | If exact wording is mandatory, you wrote a use case |
+| **V**aluable | Does the persona get observable value when this ships? | If only internal/refactor value, it's a tech-debt task — not a story |
+| **E**stimable | Can the team estimate it within ~30 min? | If no, it's too vague — split or research |
+| **S**mall | Fits in one iteration / sprint? | If multi-sprint, it's an epic — split |
+| **T**estable | Acceptance criteria are concrete + observable? | If not, criteria need rewrite |
+
+Stories that fail any INVEST letter get marked WARN; stories that fail multiple get FAIL and require rewrite before they're backlog-ready.
+
+### Step 4: Anti-pattern check
+
+Reject (or rewrite) stories that exhibit any of:
+
+- **Solution-as-story** — "Add a sidebar" is a solution; the story should be the user outcome that motivates the sidebar
+- **Implementation leak** — "Use Redis to cache X" is implementation detail; story is about user-facing behavior, not how
+- **Persona inflation** — "As a user" is too broad; reference a persona slug from `/personas`
+- **Benefit absent** — "So that" clause empty or generic ("so that I can use the app"); ground in VPC entry or JTBD outcome
+- **Acceptance criteria as pseudocode** — criteria should be observable behaviors, not function signatures
+
+### Step 5: Emit + traceability matrix
+
+Write each story to `docs/user-stories/US-NNN-[slug].md` (one file per story for granular Git history) OR append to `docs/user-stories/[iteration-slug].md` for batch (operator preference).
+
+Emit a traceability matrix at `docs/user-stories/_matrix.md`:
+
+```markdown
+| Story | Persona | JTBD | VPC | Use-case | INVEST | Status |
+|-------|---------|------|-----|----------|--------|--------|
+| US-001 | couple-founders | J1 | GC2 | UC-3:4a | PASS | new |
+| US-002 | cofounder-pair | J2 | PR1 | UC-3:4b | WARN-S | new |
+| ... | ... | ... | ... | ... | ... | ... |
+```
+
+The matrix surfaces:
+- **Coverage gaps**: a JTBD with no stories = unserved user need
+- **Orphan stories**: a story with no JTBD trace = solution looking for a problem (red flag)
+- **INVEST health**: aggregate PASS/WARN/FAIL ratio for the iteration
+
+### Step 6: Output summary
+
+Print a compact summary:
+
+```markdown
+## User stories produced
+
+**Iteration**: [iteration goal slug]
+**Personas covered**: N
+**JTBDs covered**: N
+**Use-cases sliced**: N (if applicable)
+**Stories produced**: N
+**INVEST**: N PASS / M WARN / K FAIL
+
+**Coverage gaps**: [JTBDs with zero stories]
+**Orphans**: [stories with no JTBD trace — should be 0]
+```
+
+## Worked example — INVEST validation in action
+
+To make the INVEST rule concrete, here's a deliberate WARN catch:
+
+**Persona**: cofounder-pair (two technical co-founders, ChatGPT Business friction)
+**JTBD**: J1 — share AI-discovered context across the cofounder pair without re-explaining
+
+**Story drafted** (US-001):
+
+> **As a** cofounder-pair member
+> **I want to** see what my partner asked the AI yesterday
+> **So that** I can pick up the thread without making them re-explain
+>
+> **Acceptance**:
+> - [ ] Yesterday's AI conversations from the partner appear in a "shared digest" pane
+> - [ ] Each entry shows: timestamp, partner-name, conversation summary, link to full thread
+
+**INVEST check**:
+- I: ✅ Ships independently of any other story
+- N: ✅ Wording is suggested, not mandatory
+- V: ✅ Observable value — operator stops re-explaining
+- E: ✅ Estimable (~2-3 days)
+- **S**: ⚠️ WARN — "shared digest pane" implies UI surface + backend digest job + partner-account linkage. Three concerns; might be too big.
+- T: ✅ Testable
+
+**Resolution**: split into US-001a (backend digest job) + US-001b (UI pane) + US-001c (partner-account linkage). Each ships independently, each is small, each is testable.
+
+Without the **S** check, US-001 ships as a 3-week mega-story and we lose all the INVEST benefits. The check forces the split before sprint planning, not after.
+
+## Common pitfalls
+
+- **Treating /user-stories as a replacement for /task-scenarios** — they're different artifacts. Task scenarios provide narrative context for UX research + synthetic-user testing; user stories are backlog tokens. Keep both.
+- **Skipping persona grounding** — "As a user" is a code smell. Always reference a persona slug.
+- **Writing stories without a use-case when one would help** — for goal-level features (multi-step flows, complex behaviors), write the use-case first, then split into stories. The use-case gives you the spec; the stories slice it.
+- **Padding INVEST** — every letter should be a real check, not a checkbox. If you can't articulate WHY a story is Independent, it probably isn't.
+- **Acceptance criteria as wishes** — "Works well" is not a criterion. "Loads in <2s on 4G" is.
+
+## Relationship to other skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `/personas` | Upstream — provides the persona slug for the `<As a>` clause |
+| `/jtbd-tasks` | Upstream — provides JTBD outcome statements that ground the `<so that>` clause |
+| `/value-prop-canvas` | Upstream — Pain-Relievers + Gain-Creators inform the benefit phrasing |
+| `/value-prop` | Sibling — value-prop is for positioning; user-stories are for backlog. Both consume personas + VPC. |
+| `/use-case` (future) | Direct upstream when present — user-stories slice use-case lines with traceability back |
+| `/interaction-design` | Downstream — diagrams render the story flows |
+| `/decompose` | Downstream — responsibilities assigned per story (or per use-case if one exists) |
+| `/spec` | Downstream — spec consumes stories + use-cases as input |
+| `/task-scenarios` | Sibling, NOT replacement — task-scenarios are narrative day-in-the-life for UX research; user-stories are backlog tokens. Both coexist. |
+| `/synthetic-user` | Indirect — synthetic-user reads /task-scenarios for journey context, NOT stories. Stories are not the right shape for testing journeys (too granular). |
+| `/sprint` | Downstream — sprint reads the user-story matrix to surface candidate work |
+
+## Chain position
+
+```
+/personas (WHO)
+    ↓
+/jtbd-tasks (WHY) ─────────────┐
+    ↓                           ├─→ /task-scenarios (CONTEXT for /synthetic-user)
+/value-prop-canvas (FIT)       │
+    ↓                           │
+/use-case (SPEC, future)        │
+    ↓                           │
+/user-stories (BACKLOG)  ←──────┘  ← THIS SKILL
+    ↓
+/interaction-design (RENDERS) + /decompose (RESPONSIBILITIES)
+    ↓
+/spec (BUILD)
+```
+
+## Provenance & evolution
+
+- Drafted in an operator project during user-centric chain shaping
+- Promoted to bassclef via issue #208
+- Cockburn-aligned (user-stories ≠ use-cases) and NN/G-aligned (user-stories ≠ task-scenarios)
+
+Future related promotions (separate bassclef-evolution tickets):
+- `/use-case` — Cockburn-style behavior spec
+- `/story-map` — Patton 2D backlog grid
+- `/shape` — workflow for tiered shaping (quick-spike / light / medium / full-blown)
+- Refocus `/task-scenarios` on NN/G narrative scenarios (strip stories + BDD overlap)
+- Wire `/synthetic-user` to read `/task-scenarios` for journey context
+
+## Closes
+
+- bassclef #208
+- Part of follow-up to iteration `2026-04-19e-persona-vpc-promotions`
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.

package/dist/lite/.claude/skills/value-prop/SKILL.md

@@ -0,0 +1,251 @@
+---
+tier: lite
+name: value-prop
+description: "Draft a value prop for a ticket, goal, or feature. Three sizes: tweet (\u2264280 chars claim + sharpener), brief (claim + 3 reasons), verbose (full Dunford / Moore positioning). Pick the size that matches your audience attention."
+problem: "PR bodies and ticket bodies open with solution-framing. The reader has no reason to care."
+value: "One line that names claim plus sharpener. Three sizes \u2014 tweet and brief and verbose."
+inputs: [A ticket ref or doc path or scope description, Optional size — tweet or brief or verbose]
+outputs: [Claim plus sharpener at chosen size, Ready to paste as opener]
+user_invocable: true
+disable_model_invocation: false
+sizes: [tweet, brief, verbose]
+---
+
+# /value-prop
+
+## What you get
+
+A value proposition for a ticket, iteration goal, feature, or product concept. Three sizes along a single axis — how much scaffolding around the claim? `tweet` gives you a claim plus one sharpener in ≤280 chars for status updates and Slack. `brief` (default) gives you a ≤180-char claim plus 3 evidence-backed Reasons to Believe plus sources — deck-ready. `verbose` gives you the full Dunford 5-part sales pitch plus Moore positioning — long-form material for landing pages and pitches.
+
+## When to use it
+
+Any time you need to state the value of a ticket or feature at a specific size. Pick the size by audience attention:
+
+| Context | Mode |
+|---|---|
+| Status update / Slack message / quick social share | `tweet` |
+| Deck, landing page, internal framing doc, pitch prep | `brief` (default) |
+| Technical ticket (internal audience) | `brief` — framed for engineering value (e.g., "reduces deploy time by 40%" is proof) |
+| External launch / long-form pitch / website hero + supporting | `verbose` |
+
+Skip for conversational asides or when the value is self-evident from context.
+
+## Grace window on flash mode
+
+The `flash` mode (≤180 chars claim only) retired 2026-07-17 per ADR-040 Decision 3. Sessions from before the retirement still work — the compat layer through 2026-10-31 accepts `/value-prop flash` and returns a tweet-mode output with a note. New sessions use `tweet` for the compressed claim.
+
+## FAQ
+
+### Why did flash retire?
+
+Per Toulmin, flash carried only the claim and failed the minimum argument shape (claim + evidence + warrant). Per Ousterhout, flash was a shallow interface with no hidden work. Per Beck, the minimum planning artifact is goal + steps + done-markers — not a fragment. The compression discipline (short opening line) folded into the tweet mode's sharpener clause.
+
+ADR-040 Decision 3 pins the retirement. The `/state-a-problem brief` skill covers the Problem-side of what flash used to do at planning surfaces; `tweet` mode covers the Value-side.
+
+### What's the difference between tweet and brief?
+
+`tweet` is one glance — a claim in ≤280 chars, optionally followed by one sharpening clause (who it's for, what it replaces, or one credibility signal). No Reasons to Believe.
+
+`brief` is deck-ready — a ≤180-char claim plus 3 evidence-backed Reasons to Believe plus sources. Use tweet when the operator just needs orientation; use brief when someone will ask "why should I believe this?" and you want the answer on the same page.
+
+### What sources back the templates?
+
+Two industry-standard B2B product marketing sources — Geoffrey Moore (positioning statement template from *Crossing the Chasm* 1991) and April Dunford (5-part sales pitch framework from *Sales Pitch* 2023 and *Obviously Awesome* 2019). All three modes use Moore positioning compressed differently. Brief adds 3 Dunford proofs. Verbose gives you the full 5-part Dunford + Moore positioning as one section.
+
+### What are Reasons to Believe?
+
+Evidence-backed claims — not aspirational. "Faster than X" is assertion; "7x faster in benchmark Y" is proof. Each RTB is independent — you should be able to remove any one and still have a defensible pitch. Aim for exactly 3 (pattern recognition needs three points; deck space is expensive).
+
+### What if the artifact is thin?
+
+Ask for the missing signals rather than inventing them. Fabricated value props fail silently — they look plausible but don't survive customer contact.
+
+## Details below the fold
+
+### Usage
+
+```
+/value-prop                             → brief mode (default), use current iteration goal
+/value-prop [ticket-ref]                → brief, from specific ticket
+/value-prop brief                       → same as default
+/value-prop tweet                       → claim + sharpener, ≤280 chars
+/value-prop tweet [ticket-ref]          → tweet for a specific ticket
+/value-prop verbose                     → verbose mode
+/value-prop verbose [ticket-ref]
+```
+
+Ticket references accepted:
+
+- GitHub issue: `#NNN` or `owner/repo#NNN`
+- File path: `docs/iteration-bets/YYYY-MM-DD-slug.md`
+- Spec path: `docs/specs/NNN-feature.md`
+- Canvas path: `docs/strategy/canvases/YYYY-MM-DD-slug.md`
+- Freeform: `/value-prop for [description]`
+
+### Procedure
+
+**Step 1 — Extract signals from the ticket.**
+
+| Signal | Where to find |
+|---|---|
+| **Target user** | Canvas personas, spec actors, iteration goal user field |
+| **Problem** | Ticket "What" section, canvas Thesis, iteration goal "risk being retired" |
+| **Current alternatives** | Canvas "alternatives considered," spec "out of scope," or inferred |
+| **Key benefit** | Iteration goal "business value being proven," spec "success criteria" |
+| **Differentiator** | What makes THIS approach different (technical, UX, timing, cost) |
+| **Evidence available** | Quantified outcomes, prior proof points, pilot results |
+
+**Step 2 — Draft tweet mode.**
+
+Structure — 1-2 sentences, ≤280 chars total. Claim plus optional sharpening clause (who it's for, what it replaces, or one credibility signal).
+
+Rules:
+
+- ≤280 chars total, no exceptions
+- Sharpening clause is optional. If the claim already lands short, don't pad
+- If you add a clause, pick exactly one — not a list
+- No Reasons to Believe — this is a handoff, not a pitch
+- Reads as one thought
+
+Purpose — one-glance share-ready (Slack, quick social post, status update).
+
+**Step 3 — Draft brief mode (default).**
+
+Structure:
+
+```markdown
+## Value proposition
+[≤180 characters. Moore-compressed — target + benefit + differentiator in one sentence. Scannable. Deck-ready.]
+
+## Reasons to Believe
+1. **[claim]** — [evidence: quantified outcome, proof point, prior result]
+2. **[claim]** — [evidence]
+3. **[claim]** — [evidence]
+
+## Sources
+- Positioning: Geoffrey Moore, *Crossing the Chasm* (1991)
+- Proof structure: April Dunford, *Sales Pitch* (2023)
+```
+
+Rules:
+
+- Value prop ≤180 chars. If it does not fit, the positioning is not tight enough. Iterate.
+- RTBs are evidence-backed, not aspirational
+- Each RTB is independent
+- 3 RTBs — not 2 (pattern recognition needs three points), not 5 (cut to the three strongest)
+- No jargon in value prop — user vocabulary, not internal domain terms
+
+**Step 4 — Draft verbose mode.**
+
+Structure (Dunford 5-part + Moore positioning):
+
+```markdown
+## Positioning statement (Moore)
+
+For [target customer]
+Who [statement of need or opportunity]
+The [product name] is a [product category]
+That [statement of key benefit].
+Unlike [primary alternative], our product [differentiation].
+
+## Sales pitch (Dunford 5-part)
+
+### 1. Insight
+[The market/customer shift everyone is wrestling with. The thing changing that makes current alternatives inadequate.]
+
+### 2. Alternatives + trade-offs
+[What is on the table today. For each alternative, the inherent trade-off that creates the opening.]
+- Alternative A — trade-off
+- Alternative B — trade-off
+- Status quo / DIY — trade-off
+
+### 3. Perfect world
+[What an ideal solution would do. Do not pitch the product yet — articulate the goal the buyer would endorse.]
+
+### 4. Introduction
+[Our product, cast as the perfect-world solution. Brief.]
+
+### 5. Proof (Reasons to Believe)
+[Each claim evidence-backed. More than 3 acceptable in verbose mode. Target 5-7.]
+1. **[claim]** — [evidence]
+2. **[claim]** — [evidence]
+...
+
+## Sources
+- Moore positioning: *Crossing the Chasm* (1991), *Inside the Tornado*
+- Dunford framework: *Obviously Awesome* (2019), *Sales Pitch* (2023)
+```
+
+**Step 5 — Output.**
+
+If invoked within an iteration goal, consider appending to the goal doc under `## Value proposition` after Scope. If standalone, output to conversation only. Do not overwrite existing sections.
+
+### Common pitfalls
+
+- **Aspirational RTBs** — "We'll be the best at X" is not a reason to believe. Past performance, benchmarks, or testimonial beats promise.
+- **Feature-list masquerading as value** — "Has integration with X, Y, Z" is features, not value. Value is the outcome the integration enables.
+- **Target too broad** — "Every team" is not a target. "PE operators managing 50+ active deals" is a target.
+- **180 becomes 220** — if you are over, cut. Do not let scope creep the character limit.
+- **Proof by asserting proof** — "Proven to work" is not evidence. Evidence names a number, a prior customer, or a controlled study.
+
+### Example — tweet mode
+
+For `/personas` bassclef skill:
+
+```
+One shared format for describing who your users are — so every tool that reasons about them speaks the same language. Replaces the ad-hoc per-project persona shapes most teams reinvent.
+```
+
+(187 characters)
+
+For `/value-prop-canvas` bassclef skill:
+
+```
+A diagnostic for your value prop — checks that every benefit you promise actually addresses a pain your user has named. Catches "features looking for problems" before they hit your roadmap.
+```
+
+(191 characters)
+
+One sharpener added to the claim — for /personas it is what-it-replaces; for /value-prop-canvas it is the credibility signal. Not a list, just one sharpener.
+
+### Example — brief mode
+
+For an iteration goal about `/decompose`:
+
+```markdown
+## Value proposition
+For engineering leaders building with AI agents, /decompose prevents cross-cutting concerns being bolted into implementations instead of resolved as proper abstractions — unlike ad-hoc code review.
+
+## Reasons to Believe
+1. **Catches the class of error that cost 6 CI failures in one POA session** — Langfuse-inside-implementation pattern recurred until /decompose Phase 2 NFR check codified the decorator as the answer.
+2. **Produces concrete interfaces as output, not principle citations** — Responsibility matrix names the interface; Builder gets drop-in schema instead of GRASP theory.
+3. **Works regardless of starting artifact** — canvas, epic, defect, or bug all produce a decomposition (Entry Point states landed 2026-04-12b).
+
+## Sources
+- Positioning: Moore, *Crossing the Chasm*
+- Proof structure: Dunford, *Sales Pitch*
+```
+
+### Composes with
+
+| Skill | Relationship |
+|---|---|
+| `/state-a-problem` | Problem-side pair; sits alongside `/value-prop` in the three-block opener discipline |
+| `/canvas` | Canvas Thesis stage feeds value prop input |
+| `/spec` | Spec success criteria maps to RTB evidence |
+| `/journal` | Journal entries often open with value prop compression |
+| `/feynman` | Value prop is adjacent to plain-English explanation but has specific structure |
+| Amazon PR/FAQ | Long-form cousin; `/value-prop` is the compressed version |
+
+### Refs
+
+- `.claude/rules/assert-only-after-verify.md` — a value prop is a claim that needs data + warrant per Toulmin's argument model. The brief and verbose modes ship Reasons to Believe cells that ARE Toulmin's data + warrant.
+- `.claude/luminaries/stephen-toulmin.md` — anchor luminary for the argument shape
+- `standards/opener-discipline.md` — the three-block opener that pairs `/value-prop tweet` with `/state-a-problem brief`
+- ADR-040 Decision 3 — flash mode retirement rationale
+- Bet 2026-07-18c — this rewrite (Step 5 flash retirement + template application)
+- bassclef#204 — original flash + tweet mode addition (2026-04-19, retired 2026-07-17)
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.