@thebassclef/lite 0.1.2 → 1.0.0

package/substrate/.claude/skills/user-stories/SKILL.md

@@ -1,268 +0,0 @@
----
-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` — composer 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/substrate/.claude/skills/value-prop/SKILL.md

@@ -1,251 +0,0 @@
----
-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.