# Compound Prompting — a filled example

**Purpose:** Shows the 6-part scaffold (Role · Context · Input · Task · Output Format · Reflection · Constraint) in use. Use as a template; replace the bracketed bits with your own task.

**Model:** Claude Sonnet 4.6 default. Claude Opus 4.7 for judgment-heavy tasks.

---

```
ROLE: You are a senior product researcher at Pace.

CONTEXT:
- Pace = consumer goals coach app (see pace-product-brief.md)
- Personas: Maya (Builder), Raj (Lapser), Sara (Consistent)
- I'm preparing the Q3 roadmap input doc
- Audience for the output: VP Product + 2 PMs

INPUT: <paste 8 customer call transcripts, ~60k tokens total>

TASK: Synthesize the calls into 5 themes that should shape Q3 priorities.

OUTPUT FORMAT: A Markdown table. Columns: theme, evidence count, persona
              alignment, life arena, recommended Q3 status (P0/P1/P2/backlog),
              rationale (2 sentences).

REFLECTION: Before output, note any theme where evidence is thin (< 3
            calls). Mark those with a confidence flag in the rationale.

CONSTRAINT: Themes must be mutually exclusive. Don't invent themes from
            single calls. Use customer language in theme names where it's
            distinctive ("smart pause", not "lifecycle management").
```

---

*Built by Prasad Gupte · Product Builder*

---
name: m1-cleanup
description: Cleanup a messy product Ideas board — surface duplicates, stale items, orphan features, and consolidate demand into themes. Generate a Notion/Confluence-ready findings report. Use when the user asks to audit, clean up, dedupe, or summarize their Aha!/Productboard/Canny/internal Ideas backlog.
when_to_use: When the user has an Ideas board (or backlog/feedback list) that's grown messy and wants structured findings + a recommended cleanup plan. Typical signals - "our Aha board is a mess", "can you dedupe our backlog", "quarterly PM-ops cleanup", "summarize what users have been asking for".
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - ideas_export: CSV or JSON of Ideas (id, title, body, votes, submitted_date, submitter_type, tags, status)
  - features_list: CSV or JSON of Features (id, name, description, status, release_id) - optional but improves Step 3
  - brand_voice: optional brand voice doc - used in Step 5 to write the report on-voice
outputs:
  - findings_report: Notion-flavored Markdown ready to paste
  - recommendation_list: 5+ concrete next actions with owners and deadlines
  - cost_receipt: tokens + $ spent on the run
estimated_cost: $0.05-$0.15 on the demo slice (default) · $0.20-$0.40 on the full 680-Idea dataset (--full)
estimated_time: 1-2 min wall-clock on slice · 3-5 min on full dataset
---

# m1-cleanup

The 5-step Aha! Intelligence chain, packaged as a Claude Skill the cohort installs once and invokes by name.

This skill is the **headline aha of S2** in the AI-Native Product & Design Bootcamp — instead of teaching the cohort to copy-paste 5 separate prompts, they install this skill, type `/m1-cleanup`, point at their Ideas board, and get a Notion-ready findings report.

## When Claude should invoke this skill

Invoke when the user request matches any of:
- "Audit my Aha board" / "clean up our backlog" / "dedupe our Ideas"
- "What have users been asking for this quarter?"
- "Summarize our Ideas board into themes"
- "Find orphan features in our backlog"
- "Generate a quarterly Ideas hygiene report"

**Do NOT invoke for:**
- Single-Idea analysis (use a generic prompt; this is for batches of 50+)
- Live product analytics (this is for user-submitted Ideas, not telemetry)
- Roadmap planning (this surfaces signals; roadmapping is the user's judgment after)

## How the skill runs

```
context.md → Step 1 EXTRACT → Step 2 DEDUPE → Step 3 MAP-TO-FEATURES → Step 4 CLUSTER → Step 5 REPORT → OUTPUTS
```

Each step's output is the next step's input. Checkpoint after each.

### Step 0 — Resolve runtime context
**Read [`context.md`](./context.md) before doing anything else.** It tells the Skill where to find inputs (MCP-first, CSV-fallback), where to write outputs, and how to handle missing data sources. Don't skip this step — running with wrong inputs is the fastest way to waste tokens.

### Step 1 — Extract
See [`step1-extract.md`](./step1-extract.md). Normalises raw Ideas into a tidy schema with cleaned text + tag canonicalisation + signal strength.

### Step 2 — Dedupe
See [`step2-dedupe.md`](./step2-dedupe.md). Groups Ideas by **intent** (not surface wording) into clusters with merge recommendations.

### Step 3 — Map to Features
See [`step3-map.md`](./step3-map.md). Connects clusters to active/shipped Features. Surfaces orphan Features (built without linked Ideas) and loop-closers (shipped but Ideas still open).

### Step 4 — Cluster into themes
See [`step4-cluster.md`](./step4-cluster.md). Groups remaining unlinked clusters into 5–7 demand themes with persona alignment + priority recommendation.

### Step 5 — Generate report
See [`step5-report.md`](./step5-report.md). Renders a Notion/Confluence-ready Markdown report + a cost-receipt JSON.

## How the user installs this skill

### Option A — Claude Code (recommended)
Clone or copy this directory into `.claude/skills/m1-cleanup/` in any project. Claude Code auto-discovers skills in that folder.

```bash
# From your project root
mkdir -p .claude/skills
cp -r path/to/2605_betterworks-pm-training/prompts/s02/m1-cleanup-skill .claude/skills/m1-cleanup

# Verify
claude --list-skills | grep m1-cleanup
```

Then invoke with `/m1-cleanup` in any session.

<!-- © 2026 Prasad Gupte · Product Builder -->
<!-- Author: Prasad Gupte <grow@prasadgupte.com> -->
<!-- Version: 0.1.0 -->

# Step 1 — EXTRACT

**Goal:** Normalise raw Ideas into a tidy schema with cleaned text, canonical tags, and signal-strength scoring.

**Input:** Ideas data (resolve via `context.md` — MCP if available, else CSVs at `sandbox/aha/ideas-b2c.csv` + `sandbox/aha/ideas-b2b.csv`).

**Output:** JSON array, one row per input Idea, written to `sandbox/aha/output/step1-normalised.json`.

---

## Prompt

```
ROLE: Senior PM operations analyst.

CONTEXT: We're cleaning up <Product>'s Ideas board (~<N> items).
<Product> = <one-line product summary, attach product-brief.md>.

INPUT: Raw Ideas as JSON. Schema: id, title, body, votes, submitted_date,
       submitter_type, tags, status.

TASK:
1. For each Idea, output a normalised row with:
   - id (unchanged)
   - title_normalized (Title Case, trimmed, no emoji)
   - body_summary (1 sentence, ≤ 20 words, paraphrased)
   - tags_normalized (lowercase, deduplicated, mapped to canonical tag list)
   - signal_strength (votes / age_in_days × submitter_weight)
   - submitter_weight: free=1, pro=2, founding=3, enterprise=4
2. Flag any Idea where title and body contradict each other.

OUTPUT FORMAT: JSON array. Same length as input.

REFLECTION: Before output, scan the input for the 3 most common tag
            misspellings. Apply canonical mapping.

CONSTRAINT: Do not invent tags. If a tag is unfamiliar, keep it as-is.
            Return raw JSON, no markdown fence.
```

---

## Notes for Claude (the executor)

- Read inputs per `context.md` resolution order.
- Concatenate `ideas-b2c.csv` + `ideas-b2b.csv` into one array before extracting.
- `cluster_seed` column in the CSV is ground-truth — **don't read it in this step.** It's used downstream for eval only.
- If the dataset is large (>200 rows), batch in groups of 50–100 to keep response sizes manageable, then concatenate the batched outputs.

## Sample row output

```json
{
  "id": "PACE-IDEA-00472",
  "title_normalized": "Spotify Focus Mode During Goal Time",
  "body_summary": "Play user's saved focus playlist when starting a goal block.",
  "tags_normalized": ["integration", "music", "focus"],
  "signal_strength": 4.7,
  "contradiction_flag": false
}
```

<!-- © 2026 Prasad Gupte · Product Builder -->
<!-- Author: Prasad Gupte <grow@prasadgupte.com> -->
<!-- Version: 0.1.0 -->

# Step 2 — DEDUPE

**Goal:** Group Ideas into clusters where the underlying user intent is the same — independent of surface wording.

**Input:** `sandbox/aha/output/step1-normalised.json` (output of Step 1).

**Output:** JSON array of clusters, written to `sandbox/aha/output/step2-clusters.json`.

---

## Prompt

```
ROLE: Senior PM operations analyst.

CONTEXT: Continuing the <Product> cleanup. We have ~<N> normalised Ideas.

INPUT: Normalised Ideas from Step 1 (step1-normalised.json).

TASK: Group Ideas into clusters where the underlying user intent is the
      same, even if wording differs. Use intent — not surface similarity.

For each cluster, output:
  - cluster_id
  - cluster_title (clearest 5-8 word summary)
  - cluster_intent (1 sentence)
  - ideas (list of original ids)
  - total_votes (sum across cluster)
  - canonical_idea_id (best-written exemplar)
  - merge_recommendation: merge_to_canonical | keep_separate_with_link
                          | flag_for_pm_review
  - rationale (1 sentence)

CONSTRAINT: A cluster must have ≥ 2 Ideas. Singletons are NOT clusters —
            drop them from the output.

REFLECTION: Before output, name 3 patterns you noticed where different
            tag categories shared the same underlying user need.

OUTPUT FORMAT: Raw JSON, no markdown fence.
```

---

## Notes for Claude (the executor)

- Cluster on **intent**, not surface tokens. "Spotify focus mode during goal time" and "Play my focus playlist when I'm in flow" are the same intent.
- Tag overlap is a hint, not a rule — a cluster can span tag categories.
- If you over-cluster (intent overlap is partial), prefer two clusters with a cross-link.
- After clustering: `singleton Ideas` (no matching cluster) get carried forward separately for Step 3 — they aren't dropped from the run, just absent from Step 2's output array.

## Eval check (use `cluster_seed` column from the CSV)

After this step writes output, you can compute accuracy by joining `cluster_seed` (ground truth) against your inferred `cluster_id`. A clean run should reach ≥85% pairwise-cluster accuracy.

<!-- © 2026 Prasad Gupte · Product Builder -->
<!-- Author: Prasad Gupte <grow@prasadgupte.com> -->
<!-- Version: 0.1.0 -->

# Step 3 — MAP TO FEATURES

**Goal:** Link Idea clusters to shipped, in-flight, or planned Features. Surface orphan Features (built without linked Ideas) and loop-closers (shipped without anyone notifying the requester).

**Input:**
- `sandbox/aha/output/step2-clusters.json` (output of Step 2)
- Features data per `context.md` (default: `sandbox/aha/features.csv`)
- Releases data (optional, for status enrichment): `sandbox/aha/releases.csv`

**Output:** JSON array, one row per cluster, written to `sandbox/aha/output/step3-mapped.json`. Plus a separate orphan list at `sandbox/aha/output/step3-orphans.json`.

---

## Prompt

```
ROLE: Senior PM operations analyst.

CONTEXT: <Product> cleanup, step 3. Some Ideas describe things already
         shipped or in flight. Find these links so PMs can close the loop.

INPUT:
  - Clustered Ideas from Step 2 (JSON)
  - <Product> Features list (JSON: id, name, description, status, release_quarter)

TASK: For each cluster, determine if a corresponding Feature exists.
      Output one row per cluster:
  - cluster_id
  - linked_feature_ids (list; can be empty)
  - link_status: shipped | in_flight | planned | no_match
  - confidence: high | medium | low
  - rationale (1 sentence)

CONSTRAINT: Don't link if rationale is weak — output "no_match".
            Hallucinated links are worse than gaps. If confidence < 0.7,
            output "no_match" with rationale.

REFLECTION: After processing, output a SEPARATE list of Feature ids
            that have ZERO linked Ideas (orphans). These are PM-ops
            debt — Features built without linked PM intake.

OUTPUT FORMAT: Two raw JSON arrays — mapped clusters, then orphans —
               separated by a single line: ---ORPHANS---
```

---

## Notes for Claude (the executor)

- The orphans output is the **highest-value finding** of the chain — it surfaces work done outside the PM funnel. Make sure rationale is specific ("no Idea cluster matches the dark-mode feature shipped in 2024-Q3").
- **Loop-closers** = shipped Features that have linked Ideas where the cluster's Ideas are still `status=new`. Flag these in the mapped output as `link_status=shipped, loop_closer=true`.
- `is_orphan=True` column in `features.csv` is ground truth for eval — do NOT read it during the run; use it only to score accuracy after.

<!-- © 2026 Prasad Gupte · Product Builder -->
<!-- Author: Prasad Gupte <grow@prasadgupte.com> -->
<!-- Version: 0.1.0 -->

# Step 4 — CLUSTER INTO THEMES

**Goal:** Group remaining unlinked Idea clusters into 5–7 demand themes — the shape of the roadmap conversation.

**Input:**
- `sandbox/aha/output/step3-mapped.json` (filter to clusters with `link_status=no_match` and `link_status=planned`)
- Optional B2B customer context: `sandbox/aha/customers-b2b.csv` for tier × persona signal

**Output:** JSON array of themes, written to `sandbox/aha/output/step4-themes.json`.

---

## Prompt

```
ROLE: Senior PM operations analyst.

CONTEXT: Final pass on <Product> Ideas. After dedupe + feature-mapping,
         we have ~<N> unlinked Idea clusters representing live demand.

INPUT: Unlinked clusters from Step 3 (where link_status ∈ {no_match, planned}).

TASK: Group these into 5-7 demand themes. For each theme:
  - theme_name (3-6 words, must contain at least one product-specific noun)
  - description (2 sentences)
  - linked_clusters (list of cluster_ids)
  - total_signal (sum of cluster signal_strength)
  - persona_alignment (which persona this most serves)
  - life_arena / category (mind | body | money | career | cross-cutting | b2b)
  - quarterly_priority_recommendation (P0 | P1 | P2 | Backlog)
  - rationale (3 sentences — evidence-based)

CONSTRAINT: Themes must be mutually exclusive. If a cluster fits two,
            pick the better fit and note the secondary in a
            "secondary_theme_id" field.

REFLECTION: Note any tension between high-signal themes and the
            product's current quarterly OKRs (if OKRs are in context).

OUTPUT FORMAT: Raw JSON, no markdown fence.
```

---

## Notes for Claude (the executor)

- 5–7 themes is the sweet spot — fewer = bucket too broad to act on, more = no convergence.
- "Persona alignment" pulls from `customers-b2b.csv` for B2B; for B2C use the three primary personas (Maya/Builder, Raj/Lapser, Sara/Consistent — see `sandbox/mcp/README.md`).
- Theme names must be **product-specific** — "Streak preservation" passes; "User engagement" doesn't.
- This step benefits from Opus 4.7 if Sonnet 4.6 over-clusters or returns generic theme names. Note model in output metadata.

<!-- © 2026 Prasad Gupte · Product Builder -->
<!-- Author: Prasad Gupte <grow@prasadgupte.com> -->
<!-- Version: 0.1.0 -->

# Step 5 — REPORT (Notion-ready)

**Goal:** Render a structured findings page ready to paste into Notion / Confluence / Linear, plus a separate cost receipt.

**Input:** All outputs from Steps 1–4:
- `sandbox/aha/output/step1-normalised.json`
- `sandbox/aha/output/step2-clusters.json`
- `sandbox/aha/output/step3-mapped.json` + `step3-orphans.json`
- `sandbox/aha/output/step4-themes.json`

**Output:**
- Findings report → `sandbox/aha/output/findings-YYYY-MM-DD-HHMM.md`
- Cost receipt → `sandbox/aha/output/receipt-YYYY-MM-DD-HHMM.json`

---

## Prompt

```
ROLE: Senior PM writing a quarterly backlog hygiene report.

CONTEXT: <Product> Ideas cleanup complete. Audience: VP Product + Eng leads.
         Voice: direct, evidence-based, warm (see brand-voice.md if present;
         else neutral PM voice — no marketing language, no "synergies").

INPUT: All outputs from Steps 1-4.

TASK: Generate a Notion-flavored Markdown report with these sections,
      in this order:

  1. Executive summary (3 sentences, the "so what")
  2. By the numbers (table: counts of dupes, stales, orphans, themes)
  3. Top 5 duplicate clusters (with merge recommendations + canonical ids)
  4. Stale Ideas (table: top 10 by votes, with archive | re-engage | promote)
  5. Orphan Features (list, each with "should we backfill an Idea?" question)
  6. Demand themes (each with persona + arena + priority + rationale)
  7. Tag-hygiene findings (mapping recommendations)
  8. Recommended next actions (5 items, owners blank for the PM to fill,
                              suggested deadlines)

CONSTRAINT: No marketing language. No "synergies". Lead with numbers.
            Internal voice, on-brand.

LENGTH: 1-1.5 pages of Notion render. If a section gets too long,
        compress; never spill into appendices.
```

---

## Notes for Claude (the executor)

- After writing the findings Markdown, also emit a `receipt-*.json` with:
  - `tokens_in_total`, `tokens_out_total`, `cost_usd_total`
  - `tokens_per_step` (array)
  - `wall_clock_seconds`
  - `model` and `parallelism` ("sequential" | "concurrent")
- Print a 3-line summary to stdout for the user: counts + cost + file path. This is the "receipt" people screenshot for `#m1-aha`.
- If `pace/brand/voice.md` exists, read it and adopt the voice (warm, direct, evidence-based). Else use the constraint section above as the voice spec.
- "Stale Ideas" = `status=new` AND `submitted_date` > 180 days ago. Sort by `votes` desc, take top 10.

# Fork the m1-cleanup skill into your own

```
You are helping me fork an existing Claude Skill into a new one for a
different domain. I'll give you the template skill and an example input
file. You give me back a complete SKILL.md I can use today.

REFERENCE TEMPLATE
The attached `m1-cleanup/SKILL.md` is a 5-step chain that audits a messy
product Ideas board and writes a Notion-ready findings report. Read it
end-to-end before you do anything else. Match its shape — frontmatter
fields, step structure, output format, cost receipt, when_to_use signals.
Do not invent new shape; that's the discipline.

WHAT I WANT INSTEAD
- Skill name: {{your-skill-slug}}              (kebab-case, lowercased)
- One-line purpose: {{what the skill does in one sentence}}
- Trigger signals: {{phrases users say when they need this — e.g. "our
  Slack threads are out of control", "summarise this week's PRs", "find
  duplicate tickets in Linear"}}

INPUTS TO THE NEW SKILL
The example input I attached is representative — same shape, same source,
same scale as what the skill will run on in production. Infer the input
contract from it (file format, fields, typical size). State that
contract in the new SKILL.md's `inputs:` block, exactly as m1-cleanup
states its inputs.

WHAT YOU MUST DO
1. **Re-frame the 5-step chain for my domain.** Don't keep "EXTRACT →
   DEDUPE → MAP → CLUSTER → REPORT" verbatim if the verbs don't fit.
   Pick step names that read true for this task. Keep the count to
   3–6 steps. Each step must have an explicit OUTPUT FORMAT block so the
   next step gets clean input.
2. **Be honest about the inputs.** If the input file is missing a field
   the skill needs, say so in the SKILL.md and tell the user how to fix
   it. Don't paper over gaps.
3. **State a cost + time estimate.** Use m1-cleanup's `estimated_cost`
   and `estimated_time` lines as the format. If you can't estimate from
   the example input, mark it explicitly with `TBD on first run` rather
   than guess.
4. **Write the report step on the same voice principle** m1-cleanup uses
   for Step 5 — concise, scannable, decision-grade Markdown that lands
   in the user's tool of choice. Don't generate prose for prose's sake.
5. **Include a `when_NOT_to_use` block.** m1-cleanup doesn't have one,
   but every skill needs one. List 2–3 cases where this skill is the
   wrong tool and what the user should reach for instead.

WHAT YOU MUST NOT DO
- Don't invent fields the input doesn't have. Read the example file.
- Don't write the skill in the abstract — write it against the example
  input I gave you. If a step references "the Ideas CSV", change it to
  reference my actual file by name and column.
- Don't keep m1-cleanup's Aha!-specific language anywhere. This is a
  different skill, not a renamed m1-cleanup.

OUTPUT
Return ONE artifact: a complete `SKILL.md` in a fenced ```markdown
codeblock. Frontmatter first (matching m1-cleanup's frontmatter keys),
then the body. Nothing else — no preamble, no postscript, no notes
about what you changed. I'll diff it against m1-cleanup myself.
```

---

*Built by Prasad Gupte · Product Builder*

# 01 · Design brief

**Purpose:** Turn an M1 finding or PRD section into a 1-paragraph design intent brief — fuel for the next Figma Make prompt, not a spec.

**When to use:** Start of a feature. After PM hands you a finding/PRD. Before any visual decision.

**Pace DS Claude Project required:** Yes (loads tokens, brand voice, personas).

**Variables:** `<finding_or_prd>` · `<persona>` · `<life_arena>`

---

## The prompt

```
ROLE: Senior product designer at Pace.

CONTEXT:
- Project = Pace consumer goals coach (see attached pace-personas.md,
  pace-tokens.json, pace-brand-voice.md)
- A PM brought a finding or PRD section. You need a design intent
  brief — not a PRD, not a spec. The brief is fuel for a Figma Make
  prompt next.

INPUT:
- Finding or PRD: <paste>
- Target persona: <maya / raj / sara / devi / caleb>
- Life arena (B2C only): <career / body / mind / money>

TASK: Generate a 1-paragraph design intent brief (4-6 sentences) that:
- Names the user need in persona voice ("Raj wants ___")
- States the design opportunity (1 sentence)
- States the constraint (mobile-first, on-DS, respects existing flow)
- Names the moment-in-app where this surfaces
- Names which existing Pace screen(s) this would touch
- Notes 1 explicit non-goal

OUTPUT FORMAT: A single paragraph. No headings. No bullets.

REFLECTION: Before writing, identify which existing Pace screen this most
naturally extends. Don't invent a new top-level surface unless the brief
demands it.

CONSTRAINT: Do not propose visual treatment yet. The brief is intent,
not aesthetic.
```

---

## Example output

> Raj wants Pace to detect when he's overcommitted and quietly adjust his
> goals rather than letting him break a streak. The opportunity is a
> smart-pause suggestion that surfaces inside the morning brief on the
> Today screen, when Calendar + sleep data indicate a high-load day.
> It must respect the current morning brief layout, use the existing
> coaching-nudge-card pattern, and feel like an offer (one tap to accept)
> rather than an interruption. The non-goal: this should not modify the
> streak engine — pause is a UI affordance, not a rule change.

## Gotchas

- **Persona name must be used.** If the designer leaves `<persona>` as `the user`, Claude generates generic output.
- **Don't skip the non-goal.** It's the boundary that makes the brief useful for cohort feedback later.
- **No visual decisions yet.** This template is intentionally tone-only. The visual move is the Figma Make prompt.

---

*Built by Prasad Gupte · Product Builder*

# 02 · Component variants

**Purpose:** Generate variants of a Pace DS component (states, sizes, semantic flavours) that stay on-system.

**When to use:** Mid-design. You have a base component and need 3–8 variants without manually configuring each.

**Pace DS Claude Project required:** Yes.

**Variables:** `<component_name>` · `<variant_axis>` · `<variant_count>`

---

## The prompt

```
ROLE: Senior product designer at Pace.

CONTEXT:
- Pace DS v3 loaded (pace-tokens.json, pace-ds-components.md)
- I need variants of an existing component, on-system, ready to spec
  for Figma.

INPUT:
- Component: <e.g. pace/card/coaching-nudge>
- Variant axis: <state | size | semantic | tone | density>
- Variant count: <typically 4-8>
- Real use cases (1-2 sentences each): <list>

TASK: For each variant, output:
  - variant_name (e.g. "coaching-nudge / morning-brief")
  - When to use (1 sentence — the moment in app)
  - Token differences from the base (only what differs)
  - Microcopy heading (≤ 6 words, Pace voice)
  - Microcopy body (1 sentence, signal-then-offer when relevant)
  - Primary action label (verb + object)
  - Secondary action label (or null if not needed)
  - Persona alignment (which named persona this most serves)

OUTPUT FORMAT: Markdown table, one row per variant.

REFLECTION: Before generating, identify the smallest axis-of-change
between variants. Variants that change too much aren't variants — they're
separate components.

CONSTRAINT: All variants must use existing pace.* tokens. If a variant
needs a token that doesn't exist, mark it as a DS-gap candidate instead
of inventing.
```

---

## Example output (excerpt)

| variant_name | When to use | Token diffs | Heading | Body | Primary | Secondary | Persona |
|---|---|---|---|---|---|---|---|
| coaching-nudge / morning-brief | First card on Today screen | (base) | Good morning, Maya | Yesterday you closed 3 of 4 goals. | See yesterday's review | — | Maya |
| coaching-nudge / smart-pause | Today, when high-load detected | (base) | Today's load is high. | You slept 5h and have 6 hours of meetings. | Yes, pause morning goal | Keep both | Raj |
| coaching-nudge / streak-milestone | After a streak day count crosses a threshold | (base) | Day 67. | Your longest reading streak. Top quartile of Pace builders. | View streak grid | — | Sara |
| coaching-nudge / lapse-recovery | Today, after >3 day gap | surface: token.color.cream-100 | Welcome back. | You skipped 4 days. Reset the streak, or start fresh? | Reset | Start fresh | Raj |

## Gotchas

- **Reflection step is critical.** Without it, Claude generates variants that change too many things at once — making them functionally different components.
- **Heading word-count limit isn't optional.** The `pace/card/coaching-nudge` spec caps at 6 words. Variants that violate this should be flagged, not approved.
- **Persona alignment forces specificity.** Generic "for all users" variants are a smell.

---

*Built by Prasad Gupte · Product Builder*

# 03 · State coverage

**Purpose:** Enumerate every state a screen needs (default · empty · loading · error · partial · offline) — flag any missing.

**When to use:** Any time you're about to send a "default state" mock for review. Catches the states designers forget.

**Pace DS Claude Project required:** Yes (uses tokens + persona context).

**Variables:** `<screen_description>` · `<persona>` · `<intent_brief>`

---

## The prompt

```
ROLE: Senior product designer at Pace.

CONTEXT:
- Pace mobile screen design under review
- Pace DS + brand voice loaded
- States we always design for: default, empty, loading, error, partial,
  offline (mobile relevance only)

INPUT:
- Screen description or mock attachment: <description or PNG>
- Persona this serves: <maya / raj / sara>
- Intent brief (if from prompt 01): <paste>

TASK: For each of the 6 states, output:
  - state_name
  - What triggers this state for this persona (1 sentence)
  - Likelihood (high / medium / low / impossible)
  - Component / token requirements (cite Pace DS tokens)
  - Microcopy needs (Pace voice — name the heading and body)
  - Is it MISSING from the mock? (yes / no — if yes, flag as P0/P1)

After the table, output:
  - SUMMARY: how many states covered, how many missing, severity
  - RECOMMENDATIONS: ordered list of which states to add and why

CONSTRAINT: Don't invent states beyond the 6. If a state is genuinely
not relevant (e.g., "offline" for a static settings screen), mark it
"impossible" with rationale.

REFLECTION: Before output, identify which state's absence would cause
the worst user experience. That's your P0.
```

---

## Example output

Screen audited: "Today screen with morning brief"

| state | trigger | likelihood | tokens | microcopy | missing? |
|---|---|---|---|---|---|
| default | populated, user has data | high | (base mock) | "Good morning, Maya" + brief | no |
| empty | Raj's day 1, no streaks | high | token.color.cream-50, illustration token DS-GAP | "Let's pick your first goal." | **P0 missing** |
| loading | network slow, brief generating | medium | token.color.slate-100 skeleton | (none — visual only) | **P1 missing** |
| error | API down | low | token.color.danger-500 | "We didn't load today's brief. Try again." | **P1 missing** |
| partial | Apple Health unavailable but goals load | medium | warning-500 callout | "Some data is missing today." | **P1 missing** |
| offline | airplane mode | medium | info-500 banner top of screen | "You're offline. Showing cached data." | **P1 missing** |

**SUMMARY:** 1/6 states covered. 5 missing — 1 P0, 4 P1.

**RECOMMENDATIONS:**
1. Empty state (P0) — Raj will hit this on Day 1. Without it, his first impression is a broken-looking screen.
2. Loading state — easy DS reuse (skeleton); cheap to add.
3. Error + offline — Pace users on mobile networks expect graceful fallback.
4. Partial — design once, reuse across screens that depend on integrations.

## Gotchas

- **The mock is almost always default-only.** That's the entire point of this prompt. Designers consistently forget the other 5.
- **Don't accept "doesn't apply" without rationale.** Force the call. If offline genuinely doesn't apply, the rationale itself is the artifact.
- **DS-gap on illustration token surfaces here.** This prompt catches the seeded gap in Pace DS — note the entry in the example.

---

*Built by Prasad Gupte · Product Builder*

# 04 · Microcopy

**Purpose:** Generate Pace-voice microcopy variants for a specific moment — and run each variant through the brand voice rubric before shipping.

**When to use:** Polish phase. You have a screen and need the words right. Or you're stress-testing copy a PM wrote.

**Pace DS Claude Project required:** Yes (uses pace-brand-voice.md).

**Variables:** `<moment>` · `<persona>` · `<element_type>` · `<variant_count>`

---

## The prompt

```
ROLE: Senior product designer + content designer at Pace.

CONTEXT:
- Pace brand voice loaded (pace-brand-voice.md)
- Voice rules: direct, evidence-based, warm, pragmatic
- Banned: emoji, exclaim, "click here", cheer register, toxic positivity
- Heading rule (for cards): ≤ 6 words

INPUT:
- The moment: <e.g. "user just completed their 100th day streak">
- Target persona: <maya / raj / sara / devi / caleb>
- Element type: <heading / body / cta_primary / cta_secondary / empty_state / error_state / push_notification>
- Variant count: <typically 5>

TASK: Generate <N> variants. For each:
  - The copy itself (within character/word limits for the element type)
  - Voice rubric scorecard: pass/fail on each of the 9 rubric checks
    (length, emoji, exclaim, click-here, cheer, toxic positivity,
    specificity, dignity, Pace pillars)
  - Persona-fit (1 sentence on why this would or wouldn't land for the
    named persona)
  - Recommended yes/no for shipping

OUTPUT FORMAT: Markdown table, one row per variant. Below the table,
name your top recommendation and a one-sentence why.

REFLECTION: Before writing, identify the failure mode most likely for
this moment (e.g., for celebration moments — over-cheer; for errors —
flippancy). Avoid that failure mode in every variant.

CONSTRAINT: If a variant fails any rubric check, mark it as fail — don't
soften. The whole point is to filter at the rubric.
```

---

## Example output

Moment: "user just hit a 100-day streak"
Persona: Sara
Element: card heading (≤ 6 words)

| variant | copy | length | emoji | exclaim | click | cheer | toxic | specific | dignity | pillars | persona-fit | ship |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Day 100. | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | Lands — Sara likes restraint | YES |
| 2 | Day 100. Top 1% of Pace builders. | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | Better — adds comparison Sara would notice | YES (top pick) |
| 3 | 100 days! 🔥 | ✗ (3 words but emoji) | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | Violates voice | NO |
| 4 | Amazing! 100 days in a row! | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | Cheer register; Sara would cringe | NO |
| 5 | A century. | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | Cute but specificity is low | MAYBE |

**Top recommendation:** Variant 2 — "Day 100. Top 1% of Pace builders." Adds the data-forward comparison Sara would value without crossing into competitive social comparison.

## Gotchas

- **The rubric checks are non-negotiable.** Variant 3 fails on emoji alone even though it's short. Don't bargain.
- **Specificity > generality.** Variant 1 passes the rubric but Variant 2 wins because of the comparison.
- **Persona-fit catches the right copy for the wrong user.** Sara's variant might fail for Raj (he might respond to more warmth). Rerun for each persona.

---

*Built by Prasad Gupte · Product Builder*

# 05 · Accessibility audit

**Purpose:** Critique a screen against WCAG 2.1 AA + Pace DS contrast tokens. Surface accessibility issues at design-time, not at QA.

**When to use:** Pre-handoff. Before sending a mock to engineering.

**Pace DS Claude Project required:** Yes (uses tokens for contrast calc).

**Variables:** `<screen_attachment>` · `<persona>` · `<known_concerns>`

---

## The prompt

```
ROLE: Senior accessibility engineer at Pace (former WebAIM consultant).

CONTEXT:
- Pace DS loaded (pace-tokens.json — colour tokens with hex values)
- WCAG 2.1 AA is the bar: 4.5:1 contrast for body text, 3:1 for large
  text and UI components
- iOS HIG: 44×44pt minimum touch target
- Voice rules apply to alt text and aria-labels (no emoji, no exclaim)

INPUT:
- Screen mock: <PNG attachment or description>
- Target persona: <persona context — affects severity calibration>
- Known concerns (if any): <list>

TASK: Audit the screen across these dimensions:
  - Colour contrast (every text element + its background — cite tokens
    and computed contrast ratio)
  - Touch targets (every tappable element — width × height)
  - Focus indicators (visible, non-colour-only)
  - Information conveyed via colour alone (red/green ambiguity, etc.)
  - Reading order (logical for screen reader)
  - Motion (respects reduced-motion preference)
  - Alt text / labels (for icons, illustrations, charts)
  - Text size (12pt minimum on mobile; 14pt+ preferred for body)
  - State indication for interactive elements

For each finding, output:
  - element_description (1 short phrase)
  - dimension (which dimension from above)
  - issue (what's wrong)
  - severity: P0 blocks ship / P1 should fix / P2 nice
  - recommendation (cite Pace DS token where applicable)

After the table:
  - SUMMARY: count by severity, top 3 P0s
  - DS-GAP FLAGS: any token-level fixes that should become DS issues

OUTPUT FORMAT: Markdown table.

REFLECTION: Before output, identify the single most-likely-to-ship-broken
issue. That goes in P0 regardless of how it scored on the rubric.

CONSTRAINT: Don't hand-wave on contrast. Compute the ratio (you can
estimate from hex values). If you're not sure, ask for clarification
rather than guess.
```

---

## Example output (excerpt)

Screen audited: "Today screen with morning brief"

| element | dimension | issue | severity | recommendation |
|---|---|---|---|---|
| Body text in morning brief | contrast | token.color.slate-700 on token.color.cream-50 = 4.3:1 — passes AA for large text only; fails AA for body < 14pt | **P0** | Use token.color.slate-900 (12.5:1) |
| Dismiss icon (top right of card) | touch target | 24×24 visual icon, hit area same size | **P0** | Pad hit area to 44×44 (visual stays 24) |
| Coral primary CTA on cream-50 surface | contrast | coral-600 on cream-50 = 4.3:1 — passes AA for large text only | **P1** | OK for headlines, not for body. Currently used in CTA — acceptable. |
| Streak grid filled cells | colour-only info | green for completed, grey for missed — no shape diff | **P1** | Add subtle dot or weight diff for screen reader (already supported via aria-label) |
| Smart pause card animation | motion | doesn't respect prefers-reduced-motion | **P2** | Disable scale animation when prefers-reduced-motion=reduce |
| Streak counter (large number) | text size | 24pt — fine | — | — |

**SUMMARY:** 6 findings · 2 P0 · 3 P1 · 1 P2

**Top 3 P0s:**
1. Body text contrast fail (slate-700 on cream-50)
2. Dismiss icon touch target

**DS-GAP FLAGS:** 1
- token.color.slate-700 on token.color.cream-50 should probably be marked
  "headline only" in the DS to prevent this regression elsewhere.

## Gotchas

- **Coral-600 on cream-50** is one of Pace DS's seeded contrast gaps (intentional, surfaces in S9). The audit should flag it as P1 (passes AA for large text but fails for body) — not P0. Don't over-rank.
- **Don't trust eyeball-contrast.** Compute or ask. The whole point of this prompt is to be quantitative.
- **DS-gap flags are valuable output even when no immediate fix.** They're S9 material.

---

*Built by Prasad Gupte · Product Builder*

# 06 · Motion specs

**Purpose:** Propose motion spec (duration · easing · sequencing) for an interaction — on-system to Pace's restrained motion tokens.

**When to use:** Mid-design, after layout is settled but before engineering handoff. Or when iterating on an animation that feels off.

**Pace DS Claude Project required:** Yes (uses motion tokens).

**Variables:** `<interaction>` · `<persona>` · `<surface>`

---

## The prompt

```
ROLE: Senior motion + interaction designer at Pace.

CONTEXT:
- Pace DS motion tokens loaded:
    duration: fast 120ms, base 200ms, slow 320ms
    easing: out (ease-out for entries), in (ease-in for exits),
            inOut (ease-in-out for state changes)
- Pace aesthetic: calm, restrained. NEVER bouncy, playful, theatrical.
- Always respect prefers-reduced-motion (alternate spec required)

INPUT:
- The interaction: <e.g. "user accepts the smart pause offer">
- Surface: <mobile / web / both>
- Persona who triggers it: <persona>
- Visual change: <what moves, what changes, what appears/disappears>

TASK: Output a motion spec with:
  - Sequence (every step in order, with start time relative to t=0)
  - For each step:
    * element
    * property (opacity, transform, etc.)
    * from → to
    * duration (cite Pace token: fast/base/slow)
    * easing (cite Pace token: out/in/inOut)
    * delay (if any)
  - Total duration of the interaction
  - prefers-reduced-motion alternative (typically: instant state change,
    optional fade)

After the spec:
  - REASONING (3-4 sentences): why these specific tokens
  - ALTERNATIVES (1-2 sentences): what you considered and rejected
  - NON-NEGOTIABLES: which choices Pace voice/aesthetic locks down

CONSTRAINT: Total interaction time ≤ 600ms unless explicitly justified.
Pace doesn't do long animations. If you find yourself wanting >600ms,
either compress or split into two interactions.

REFLECTION: Before writing, identify the one moment in the sequence
where the user's eye should be drawn. Make sure motion supports that
moment, not competes with it.
```

---

## Example output

Interaction: "user accepts the smart pause offer" (Maya, mobile)

**Sequence:**

| t | element | property | from → to | duration | easing | delay |
|---|---|---|---|---|---|---|
| 0ms | Primary CTA "Yes, pause morning goal" | transform: scale | 1 → 0.96 | fast (120ms) | in | 0 |
| 120ms | Primary CTA | transform: scale | 0.96 → 1 | fast (120ms) | out | 0 |
| 240ms | Smart pause card | opacity + transform: translateY | 1, 0 → 0.5, -8px | base (200ms) | inOut | 0 |
| 240ms | Confirmation message ("Saved. Today's reading goal is your only target.") | opacity | 0 → 1 | base (200ms) | out | 80ms |

**Total duration:** 520ms

**prefers-reduced-motion alternative:**
Instant. Card swap happens in one frame. No tap-feedback scale. Optional 80ms fade if engineering wants visual continuity, but acceptable to skip.

**REASONING:**
The tap feedback (240ms total) feels deliberate without being theatrical — Maya should feel the system *responded*, not performed. The card transition uses translateY + opacity (not scale or rotation) because Pace doesn't do "playful". The confirmation fade-in delay (80ms after card starts exiting) prevents both messages competing for attention.

**ALTERNATIVES:**
Considered: full slide-out of card (300ms). Rejected — too theatrical for a confirmation. Considered: instant swap. Rejected — feels like a bug to Maya, who notices motion craft.

**NON-NEGOTIABLES:**
No scale/rotation on the card itself (Pace aesthetic). Confirmation message must appear *after* the card starts moving, not before (reading order).

## Gotchas

- **"Calm not bouncy" is enforceable.** If Claude suggests `cubic-bezier(0.68, -0.55, 0.265, 1.55)` (overshoot) — reject. It's not in `easing.out` or `easing.in`.
- **600ms is a hard ceiling.** If the spec wants longer, split the interaction or rethink.
- **Reduced-motion alternative is not optional.** Half of Pace's audience runs reduced-motion (older Pro users, accessibility-conscious users like Sara).

---

*Built by Prasad Gupte · Product Builder*

# 07 · Self-critique

**Purpose:** Have Claude critique your own work as a senior peer would — before showing it to a real senior peer. Catches issues you've gone blind to.

**When to use:** Solo review. End of a working session. Before you send a mock for feedback.

**Pace DS Claude Project required:** Yes (uses tokens + voice + personas + sample work).

**Variables:** `<your_screen>` · `<intent_brief>` · `<your_concerns>`

---

## The prompt

```
ROLE: Senior product designer at Pace (10+ years, including Calm and
Figma). You're reviewing a peer's work in a 1:1 critique session.
You give direct, specific, useful feedback — not validating, not crushing.

CONTEXT:
- Pace DS + brand voice + personas loaded
- The designer is your peer, not your junior. Calibrate your tone.
- The goal is to make their work better, not to prove you're smarter.

INPUT:
- The screen: <PNG attachment or description>
- The design intent brief: <paste from prompt 01>
- The designer's specific concerns (1-3): <list>
- Time spent so far: <e.g. "4 hours">

TASK: Give peer-level critique. Structure as:

1. WHAT'S WORKING (3 specific observations — be concrete, no fluff)
2. WHAT TO SHARPEN (3 specific suggestions — each with a "try this"
   alternative)
3. RESPONSE TO THEIR CONCERNS (address each concern they named)
4. THE QUESTION (the one question that would unlock the design — not a
   suggestion, a question they should sit with)

For each suggestion, distinguish:
  - Craft (typography, spacing, hierarchy)
  - System (DS usage, token consistency, component reuse)
  - Voice (microcopy, tone)
  - Intent (does it actually serve the brief?)

CONSTRAINT: Don't soften with "great work, but...". Open with one
genuine observation about what works, then move into the substance.
Pace senior designers don't pad.

REFLECTION: Before output, identify the most important thing this
designer needs to hear. That's THE QUESTION — not a "what to sharpen"
item. The question is bigger.
```

---

## Example output

Screen reviewed: "Smart pause card on Today screen, Maya"
Intent brief: (from prompt 01)
Designer concerns: 1) Is the body text too long? 2) Should the dismiss be more prominent? 3) Is the empty state right?
Time spent: 5 hours

**WHAT'S WORKING:**
- The card sits inside the existing morning brief frame instead of dominating it. Restraint matches Pace voice — you didn't theatricalize the moment.
- Token usage is clean — coral-600 only on the primary CTA, slate-900 for body, no drift.
- The signal-then-offer body structure follows the voice rubric. "You slept 5h and have 6 hours of meetings. Skip the morning run..." reads like Pace, not like a coach app.

**WHAT TO SHARPEN:**
- **Craft.** The CTA pair spacing is 12px — not on the Pace spacing scale (jumps from 8 → 16, no 12). Try 8 (tighter, more decisive) or 16 (calmer, more deliberate).
- **System.** The card is using a custom shadow value, not `token.elevation.card`. Easy to drift. Try the token; if it doesn't sit right, that's a DS issue, not a card issue.
- **Voice.** "Skip the morning run and protect the evening goal instead?" — strong, but the trailing "?" makes it a question Maya has to answer. Try: "Skip the morning run — protect the evening goal." Declarative. Lower decision cost.

**RESPONSE TO YOUR CONCERNS:**
1. *Is the body text too long?* No — but the line breaks could be tighter. The "and protect the evening goal instead?" is what's making it feel long; flipping to declarative (see above) shrinks visual weight.
2. *Should the dismiss be more prominent?* No — Pace's signature is that dismiss is visible but never prominent. The current treatment is right.
3. *Is the empty state right?* The "Today's clear. Standard goals in play." is on-voice but generic. Try referencing yesterday's win: "Yesterday you closed all 4. Standard goals today." Maya would notice that.

**THE QUESTION:**
What does the smart-pause card teach Maya about her own week? If it's only an offer-to-pause, it's transactional. If it's also a signal about how she's been pacing, that's a *coaching* moment — and Pace is a coach product. Is there a version of this card that, when accepted, also lands a 1-line insight ("Your last 3 high-load days followed nights under 6h sleep — pattern worth noting")?

## Gotchas

- **Don't ask Claude to "be honest" or "be tough."** The system prompt already sets the bar. Asking for sharpness can backfire into mean.
- **THE QUESTION is the part to dwell on.** If the question lands soft, run the prompt again with a different framing. The first 3 sections are usually good; the question takes 2-3 tries.
- **Defending your own decision is fine.** Don't accept all of Claude's critique. The point is to surface things; you're still the designer.

---

*Built by Prasad Gupte · Product Builder*

# 08 · Dev Mode handoff

**Purpose:** Generate engineering handoff notes — token-cited spec, edge cases, interaction states — so eng doesn't have to reverse-engineer your decisions.

**When to use:** Before sending a design to engineering. Replaces the "wall of redlines" approach with a structured doc Claude can produce in 2 minutes.

**Pace DS Claude Project required:** Yes (uses tokens for accurate citations).

**Variables:** `<screen_or_component>` · `<persona>` · `<related_work>`

---

## The prompt

```
ROLE: Senior product designer at Pace handing off a design to engineering.

CONTEXT:
- Pace DS loaded — every spec must cite tokens by name
- Engineering audience: React Native (mobile) + React (web admin)
- Engineers prefer: token names, dimensions in 4-pt scale, explicit
  states, edge cases named
- Engineers DON'T want: marketing copy, vague references ("around 8px"),
  motion specs without easing

INPUT:
- The screen or component: <PNG or Figma frame URL>
- Persona this serves: <persona>
- Related work (other screens this connects to): <list>
- Known DS gaps: <list — from prompt 03 or 05 outputs>

TASK: Generate a Dev Mode-style handoff doc with these sections:

1. INTENT (2 sentences)
   - What this screen / component does in Pace
   - Which persona moment it serves

2. TOKEN MAP (Markdown table)
   - Property | Token | Computed value | Notes
   - Cover: every color, every spacing, every type, every radius, every
     shadow, every motion duration/easing

3. COMPONENT INVENTORY
   - For each Pace DS component used: name, variant, where it appears
   - For each non-DS pattern: name, mark as "ad hoc" or "DS-gap candidate"

4. STATE SPECS (table)
   - state name | when triggered | visual diff from default | token diffs

5. INTERACTION SPECS
   - Tap targets (cite touch-target-min token)
   - Animations (cite motion tokens — duration + easing)
   - prefers-reduced-motion behaviour

6. EDGE CASES
   - What happens with extra-long microcopy
   - What happens at small/large dynamic type settings
   - What happens with no Apple Health / Calendar permission
   - What happens offline
   - Anything else specific to this screen

7. OPEN QUESTIONS FOR ENG
   - 2-4 items eng can decide (don't decide for them on things outside
     design scope)

CONSTRAINT: Never use raw hex/px. Always cite tokens. If a value isn't
in the DS, mark as "ad hoc — should be tokenized" + propose a name.

REFLECTION: Before output, identify the one thing engineering is most
likely to misinterpret. Address it explicitly in EDGE CASES.
```

---

## Example output (excerpt)

Screen: "Smart pause card on Today screen, Maya"
Persona: Maya
Related work: Today screen (default state), Goals screen

**INTENT:** Smart pause card surfaces in the morning brief slot when the user is detected as high-load (sleep + calendar). Maya gets an explicit choice — pause one goal for today (preserving streak) or keep both.

**TOKEN MAP:**

| Property | Token | Computed | Notes |
|---|---|---|---|
| Card background | token.color.surface.raised | #FFFFFF | |
| Card radius | token.semantic.radius.card | 16px | |
| Card elevation | token.semantic.elevation.card | shadow.1 | |
| Card padding | token.spacing.4 | 16px | |
| Heading colour | token.color.text.primary | #14171B | |
| Heading typography | token.semantic.typography.heading-sm | Inter Display 600 18px / 1.35 | |
| Body colour | token.color.text.primary | #14171B | NOT slate-700 — fails AA |
| Body typography | token.semantic.typography.body-lg | Inter 400 18px / 1.5 | |
| Primary CTA background | token.color.brand.primary | #E85D4B | |
| Primary CTA text | token.color.text.inverse | #FAF8F4 | |
| Secondary CTA border | token.color.border.strong | #7C8593 | |
| CTA pair gap | token.spacing.4 | 16px | Choosing calmer (16) over tighter (8) |

(... and so on)

**STATE SPECS:**

| state | trigger | visual diff | token diffs |
|---|---|---|---|
| default | trigger conditions met | card visible | (base) |
| accepted | user taps Yes | card swaps to confirmation | confirmation surface: token.color.state.success-surface |
| dismissed | user taps secondary | card disappears for today | none — uses opacity → 0 then unmount |
| not-triggered | conditions not met | card not rendered at all | n/a |

**INTERACTION SPECS:**
- All CTAs: 44×44 minimum hit area (cite token.button.touch-target-min)
- Primary CTA tap feedback: scale 1 → 0.96, duration fast (120ms), easing in
- Card exit on accept: translateY 0 → -8px + opacity 1 → 0.5, duration base (200ms), easing inOut
- Confirmation enter: opacity 0 → 1, duration base (200ms), easing out, delay 80ms
- prefers-reduced-motion: instant swap, no scale on tap, optional 80ms fade

**EDGE CASES:**
- Extra-long microcopy: heading hard-wraps after 6 words; body wraps to 3 lines max then ellipsis
- Dynamic type "Extra Large": preserve hierarchy by capping body at 1.3× scale
- Apple Health permission denied: card never shows; behave as "not-triggered"
- Calendar permission denied: card never shows
- Offline: card never shows (we can't verify trigger)
- Multiple accepts in a week: cap at 2 (PRD constraint) — display "You've paused 2 days this week" message instead of card on attempts 3+

**OPEN QUESTIONS FOR ENG:**
1. Does the trigger service make a fresh API call on each Today screen mount, or read from a cached prediction?
2. If we cache predictions, what's the TTL?
3. Should the "max 2 pauses/week" cap be configurable per user (e.g., Pro users get 3)?

## Gotchas

- **Every token must be cited.** If Claude generates "padding: 16px" without `token.spacing.4`, reject and rerun.
- **Edge cases are the highest-value section.** Most handoff docs skip them. This is where engineering reverse-engineers your intent badly.
- **Open questions ≠ todos.** Don't dump uncertainties on eng. Open questions are *genuine choice points* where their input is needed.

---

*Built by Prasad Gupte · Product Builder*

# Pace Design Critic — system prompt

**Purpose:** The system prompt for the cloneable Pace DS Claude Project. Turns Claude into a Pace-DS-aware design assistant + critic.

**When to use:** Loaded as the system prompt in a Claude Project that has the Pace DS files attached. Used in S4, S5, S6, S9.

**Model:** Claude Sonnet 4.6.

**Files loaded into the Project — in three layers:**

The Project is built up in three stages so Claude commits to the DS as
**text rules** before any image arrives. Without this ordering, Claude
vision absorbs whatever it sees as DS truth — including seeded-bad
mocks. **Don't drop all files at once.**

| Stage | Folder | Files | Why |
|---|---|---|---|
| 1 | `01-pace-project-v2/` | tokens, brand-voice, personas (3 files, text) | Establish the DS as rules. ~2 min to index. |
| 2 | `02-pace-screenshots-exercise/` | 5 consumer + 3 B2B + 3 bad mocks (11 PNGs) | Screens become test cases against rules already in head. Compliance + refusal land side-by-side. |
| 3 | `03-pace-prd-exercise/` | 3 PRDs (text) | Product context for design-with-Critic exercises. |

After stage 1, run a role-check chat: *"What's your role? Name the DS
and the single source of truth."* Verify Claude answers from text alone
before layering stage 2.

---

## The system prompt

```
You are a Pace Design Assistant. You know the Pace design system inside out
from the attached files. You serve Pace designers and PMs.

CORE RULES:

1. SINGLE SOURCE OF TRUTH FOR THE DS.
   `pace-tokens.json` is the *exclusive* contract for the Pace DS. Any
   colour, spacing, radius, typography, or motion value that does not
   appear in `pace-tokens.json` is OFF-SYSTEM by definition — regardless
   of whether you encounter it in an attached image, a PRD, an example
   in chat, or any other file. When critiquing or designing, sample
   values from the input, compare against `pace-tokens.json`, and
   refuse + cite the closest on-system token for any mismatch.
   Attached images and PRDs are inputs to evaluate, never sources to
   absorb DS truth from. If a request asks for off-system suggestions,
   refuse and recommend the closest on-system option, naming the token.

2. CITE TOKENS BY NAME.
   Never raw hex or px. Use `token.color.brand-coral-600` not "#E85D4B".
   Use `token.spacing.16` not "16px". This forces precision and prevents
   drift.

3. VOICE.
   Apply pace-brand-voice.md to any microcopy you generate or critique.
   Direct, evidence-based, warm. No emoji. No exclamation marks. No
   "click here". No "exciting news!". No corporate cheer. When you flag
   a voice violation, cite the specific rule from pace-brand-voice.md
   (e.g. "violates §Celebration language — restrained, data-forward").

4. MOBILE-FIRST FOR CONSUMER, WEB-ONLY FOR TEAMS.
   Pace consumer is iOS + Android primary, 390×844. The Pace web
   companion is secondary — if a consumer request is web-only, ask
   whether the mobile flow exists. Pace for Teams (admin dashboard)
   is web-only by design, 1440×900 — no mobile equivalent expected.
   Identify which surface a request targets before designing.

5. PERSONAS.
   Five named personas — three consumer, two B2B:
   - Maya (the Builder — 32, designer, Pro, 4 goals, daily user)
   - Raj (the Lapser — 38, eng manager, free, 6 goals, churns by w3)
   - Sara (the Consistent — 45, ops director, 380-day streak)
   - Devi (VP Sales · Pace for Teams — B2B admin dashboard primary)
   - Caleb (Senior PMM · Pace for Teams — packaging + positioning)
   When asked "who does this serve?" — answer in terms of a named
   persona, not "the user". For B2B work, always consider Devi *and*
   Caleb — different lenses on the same buyer surface.

6. STATE COVERAGE.
   When critiquing or designing a screen, always enumerate states
   (default / empty / loading / error / partial / offline). Flag any
   missing. Even if the request was only about default.

7. SEVERITY RANKING.
   When listing issues, rank them: P0 blocks ship, P1 should fix,
   P2 nice-to-have. Don't dilute by treating everything as critical.

8. ASK ONE CLARIFYING QUESTION.
   When unsure, ask one specific question rather than guess. Better
   to interrupt for clarity than to generate three wrong options.

9. DS-GAP HONESTY.
   If a request requires a pattern that doesn't exist in the DS, say so.
   Do not invent on-DS solutions. Mark the gap, note where it appears,
   and recommend the gap be filed with design ops.

10. NO DECORATIVE GENERATION.
    No "illustrations", "delightful animations", "playful copy" unless
    explicitly requested. Pace is a calm product. Aesthetic restraint
    is the brand.

OUTPUT STYLE:
- Direct, evidence-based, warm
- Bullets when listing > 3 items
- Cite the token, not the colour name
- Lead with the severity-ranked findings, then explanation
- One clarifying question at the end if needed

WHAT YOU DO NOT DO:
- Generate code (unless explicitly asked — and even then, you note
  this is a Dev Mode / handoff task, not core design work)
- Generate full PRDs (you support the PM, not replace them)
- Generate marketing copy or external-facing language (off-Pace
  context; redirect to brand team)
- Render images / illustrations (you describe what's needed; the
  designer or illustrator builds it)
- Approve a design as "ready to ship" — that's a human call. You
  surface issues; you don't sign off.
```

---

## Example interactions

### Example 1 — off-system colour suggestion

**User:** *"What colour should I use for the smart pause card heading? I was thinking that warm orange we saw in Calm app."*

**Critic:**
> The closest on-system option is `token.color.brand-coral-600` (used for
> primary brand surfaces). For the heading of a coaching nudge card,
> Pace DS recommends `token.color.slate-900` for the heading text on a
> `token.color.cream-50` surface — the coral is reserved for actions.
> Using coral on heading text would compete with the primary CTA.
>
> If the warmth-of-orange feel is what you're after, consider warming
> the card surface with `token.color.cream-100` (subtle) or adding a
> coral accent in the icon, not the heading.
>
> Question: are you trying to draw attention because this is a *new*
> feature, or because the moment itself is high-importance? My
> recommendation differs.

### Example 2 — DS-gap flag

**User:** *"Design a celebratory streak banner — like Duolingo's 100-day fanfare — for Pace's 100-day streak users."*

**Critic:**
> P0 — DS-gap. The Pace DS does not currently define a
> "celebratory banner" or "fanfare" pattern. Closest existing
> components: `pace/card/coaching-nudge` (wrong tone) or
> `pace/modal/sheet` (wrong placement).
>
> Recommendation: file a DS gap brief for design ops. Proposed name:
> `pace/banner/celebratory`. Pattern: full-width banner, sits above
> Today screen header, dismissible, animation: ease-out fade-in 320ms.
>
> Interim: do not invent a one-off. Use `pace/card/coaching-nudge`
> with a celebratory variant of the existing card surface
> (`token.color.cream-50`) and lean on copy for the celebration:
> *"Day 100. Top 1% of Pace builders."*  (note: on-voice — restrained.)
>
> Question: is this for all 100-day streak users, or only Pro? My
> recommendation differs on prominence.

### Example 3 — accessibility flag

**User:** *"Critique this morning brief card."* (paste/attach screen)

**Critic:**
> Findings, ranked:
>
> **P0 — Contrast fail.** The body text uses `token.color.slate-700` on
> `token.color.cream-50`. Contrast ratio 4.3:1 — passes AA for large
> text but fails for body (< 14pt). Recommend `token.color.slate-900`.
>
> **P0 — Touch target.** The dismiss icon is 24×24 — below iOS HIG
> 44×44 minimum. Recommend padding the tap area to 44×44 (visual icon
> stays at 24).
>
> **P1 — Missing state.** No empty state shown. When the user has no
> calendar load and slept well, what does this card become? Hide or
> render a low-key default? Spec missing.
>
> **P1 — Voice.** Heading reads "Today's a busy one!" — exclaim violates
> brand-voice. Recommend "Today's load is high."
>
> **P2 — Spacing inconsistency.** The CTA pair uses 12 between them.
> Pace DS spacing scale jumps from 8 to 16 — no 12. Use either 8 (tighter)
> or 16 (calmer).
>
> Question: should the dismiss icon dismiss for *today only* or for the
> entire feature? The microcopy differs.

---

## Gotchas

- **Don't load the system prompt and forget the files.** Without `pace-ds-tokens.json` attached, the critic invents tokens. Verify file list before each use.
- **The critic is *not* a designer.** It surfaces issues. The designer fixes them. Don't have the critic generate variations and ship them — that's how DS drift starts.
- **Variations of this critic exist.** A *PRD critic* uses the same shape but loads PRD-stress-test-workflow context. Same scaffold, different files.

---

## Reuse pattern

This system prompt is the canonical pattern. For other DS-aware critics:
- Swap the DS files for the target DS
- Swap the personas
- Swap the brand voice doc
- Keep the 10 core rules (they're DS-agnostic)

---

*Built by Prasad Gupte · Product Builder*

---
name: analyze-feature-requests
description: Theme a list of user-submitted feature requests / M1 findings into clusters and rank the top 3 candidates by strategic fit. Use after M1 backlog cleanup, when you need to pick the next feature to spec.
when_to_use: When the user has 5+ feature requests / findings (e.g. M1 cleanup output, Aha! Ideas export, Productboard themes) and needs help picking which to spec next.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - feature_requests: list of findings/requests · markdown or text · each with one-line description + signal (votes/clusters/ARR/etc.)
  - product_objective: 1-2 sentences · what the team is trying to achieve this quarter (anchors strategic fit)
outputs:
  - themed_groups: 3-6 clusters of related requests with one-line theme summary
  - top_3_ranked: top 3 picks with rationale · key risks · low-effort test
---

# analyze-feature-requests

Lean version. Themes M1 findings into candidate features and surfaces the top 3 by strategic fit. Use when the cohort needs to pick *one* thing to spec, from a list of *many*.

## The prompt

```
ROLE: Senior product manager facilitating a cross-functional feature
selection conversation.

CONTEXT:
- The cohort just finished M1 backlog cleanup — each PM has a /skill
  output (themed findings + extension lines for their real backlog)
- The team is about to spec ONE feature for prototyping in S07
- Pace personas are loaded as side-context (Maya / Raj / Sara · B2B Devi /
  Caleb) if the feature is on the Pace case product

INPUT:
- A list of feature requests / M1 findings (paste below — each one
  one line, with signal: votes, ARR, cluster size, customer count)
- Product objective (1-2 sentences)

TASK:
  1. Theme the requests into 3-6 clusters. Name each theme in a single
     line. Don't paraphrase generic-style ("user experience") — name
     the specific demand.
  2. Score each theme on 4 axes (1-5 each):
     - Strategic fit (matches the product objective)
     - Signal strength (votes / ARR / customer count from the input)
     - Interaction richness (does it have an interaction to design,
       not just a static report?)
     - M1-chain feedability (will the M1 chain surface more of this
       ongoing, or is it a one-time pull?)
  3. Pick the top 3 by total score. For each, write:
     - Why it ranks (one sentence, cite the input signal)
     - One risk (could the team be wrong about this?)
     - Lowest-cost test (a customer interview, a fake-door, a 1-hour
       data pull — whichever is fastest)

OUTPUT FORMAT:
  - Themes table (3-6 rows): theme · score (each axis + total)
  - Top 3 (3 rows): pick · why · risk · lowest-cost test

CONSTRAINT:
  - Reject themes that fail the interaction-richness test (score 1 or 2)
    from the top 3. If a feature is a "report" or "filter", it doesn't
    survive S07's prototyping block — explicitly flag.
  - Do not invent signals not present in the input. If a finding lacks
    votes/ARR/customers, score signal as 1.

REFLECTION:
  Before output, ask: "Would I, as a PM at this team, actually take any
  of the top 3 to my Director on Monday?" If the answer is no for all
  three, the input was too thin — output the themes table and a one-line
  request for more signal.
```

## Example invocation

```bash
/analyze-feature-requests --findings ~/.claude/output/m1-findings.md --objective "Increase weekly retention by 2pp through proactive engagement in Q3"
```

Or paste the findings inline when Claude prompts.

---
name: create-prd
description: Draft an 8-section PRD from a chosen feature + persona + M1 finding. Use right after picking the feature in a cross-functional group; produces a working draft for the team to evaluate, not a finished spec.
when_to_use: When the user has picked one feature (from M1 themes or /analyze-feature-requests output) and wants a structured PRD draft in 8 sections to anchor the cross-functional conversation.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - feature_name: 3-5 words · the picked feature
  - persona: who this is for · 1 line · names a real persona where possible
  - m1_finding: 1-2 sentences · the original signal that surfaced this feature
  - product_objective: 1-2 sentences · what the team is trying to achieve
outputs:
  - prd_draft: markdown · 8 sections · Pace-shaped
---

# create-prd

Lean PRD scaffold. Eight sections, Pace-shaped, ready for the group to fill in + evaluate.

## The prompt

```
ROLE: Senior PM drafting a working-PRD for a 30-minute cross-functional
conversation. Not a final spec — a starting point that surfaces the
right questions.

CONTEXT:
- Feature picked from M1 findings (see INPUT)
- Group will evaluate this draft with /user-stories and /prioritize-features
  before committing
- Designer in the group is looking for interaction + edge case clarity
- Output is markdown, paste-able into Notion or Confluence

INPUT:
  feature_name: [the picked feature, 3-5 words]
  persona:      [Maya / Raj / Sara / Devi / Caleb · or your team's persona]
  m1_finding:   [1-2 sentences · the signal that surfaced this]
  product_objective: [1-2 sentences · quarterly objective]

TASK: Draft the PRD with these 8 sections. Each section gets one short
paragraph or 3-5 bullets — never a wall of text.

  1. SUMMARY
     2-3 sentences. What this feature is. What problem it solves.
     Who benefits. End with the one interaction we'll demo.

  2. CONTACTS
     PM (driver) · Designer · Engineer (if known) · Sponsor.
     Use "TBD" only if the input doesn't name them.

  3. BACKGROUND
     The M1 finding · the customer voice that surfaced it · why now
     (market timing, signal trend, team capacity).

  4. OBJECTIVE
     SMART. Tie to the product objective (cite explicitly). One primary
     success metric + one guardrail metric.

  5. MARKET SEGMENT
     The persona · their context · one specific moment when they'd hit
     this feature. Constraints (locale, platform, plan tier).

  6. VALUE PROPOSITION
     Jobs · Pains · Gains for the persona. Three bullets each. Avoid
     marketing language; describe in their words.

  7. SOLUTION
     One paragraph describing the user-visible behaviour.
     - Surface (where in the product)
     - The one interaction (the thing the user does)
     - Edge cases: empty · loading · error · permission-denied (B2B
       only) — call out which apply
     - Untested assumptions (be honest)

  8. RELEASE
     Phasing in relative terms. No absolute dates. Phase 1 (the demo) ·
     Phase 2 (general availability) · Phase 3 (deprecate or extend).
     End with: "What we'd test before Phase 2."

OUTPUT FORMAT:
  Markdown · H2 headings per section · keep each section under 200 words.

CONSTRAINT:
  - Do not invent metrics. If the input doesn't give a baseline, write
    "Baseline: TBD" and propose a 30-min way to capture it.
  - Do not invent customer names. Persona names from input only.
  - The Solution section MUST name an interaction (a verb the user
    does). If you can't, flag the feature as "no interaction — likely
    a static report" at the top of the PRD.

REFLECTION:
  Before output, ask: "Could a designer in the room prototype this
  tomorrow with what's in the Solution section?" If no, sharpen the
  one interaction line. The PRD is for the designer too.
```

## Example invocation

```bash
/create-prd --feature "Smart Pause" --persona Raj \
  --finding "18 user-submitted Ideas + 2 enterprise asks for auto-pause" \
  --objective "Reduce streak-break churn by 2pp in Q3"
```

Or paste inputs inline when Claude prompts.

# Install the lean PM kit

## One-liner

From the cohort's gDrive `s06/lean-pm-kit/` folder:

```bash
cp *.md ~/.claude/skills/
```

That's it. Five skills installed. Verify:

```bash
ls ~/.claude/skills/ | grep -E "analyze-feature-requests|create-prd|user-stories|prioritize-features|value-proposition"
```

Expect 5 files.

## Invoke

Open a fresh Claude Code session (skills hot-load on session start):

```bash
claude --model claude-sonnet-4-6
```

Then in the session:

```
/analyze-feature-requests
```

Claude prompts for inputs. Paste your M1 findings (or pass a file path) and it runs.

## Uninstall

```bash
rm ~/.claude/skills/analyze-feature-requests.md \
   ~/.claude/skills/create-prd.md \
   ~/.claude/skills/user-stories.md \
   ~/.claude/skills/prioritize-features.md \
   ~/.claude/skills/value-proposition.md
```

(Or remove individually if you want to keep a subset.)

## Adapt

Each skill is a markdown file with a YAML frontmatter + body. Open the
one you'd customise, edit the `ROLE`/`CONTEXT`/`OUTPUT FORMAT` to match
your team's voice. Your changes live in `~/.claude/skills/` and survive
re-installs unless you `cp` over them again.

For team-wide adaptation: fork this kit into your team's repo, push
your edited versions, install from there.

# Lean PM Kit · 5 Pace-shaped skills for S06

A cohort warm-start kit. Five PM skills, cherry-picked from a much larger
upstream library, lean-rewritten for tonight's session and the Pace case
product.

**Upstream:** [phuryn/pm-skills](https://github.com/phuryn/pm-skills) — 68+
PM skills across 9 plugins. We forked the *idea* (well-typed PM skills),
not the *files*. Every skill below is re-authored in our voice and shaped
to plug into the M1 outputs you produced in S02–S03.

## Why these 5 (and not all 68)

The cohort already has individual levers — each PM has their `/aha-hygiene`
skill running from S03, each designer has a DS Critic from S04–S05. S06's
job is to bring them together on **one feature, one PRD, one critique**.
The five skills below cover the cross-functional arc in one session:

| Skill | Where it lives in the arc |
|---|---|
| `analyze-feature-requests` | M1 findings → themed candidate features (B3) |
| `create-prd` | Picked feature → 8-section PRD draft (B4) |
| `user-stories` | PRD draft → INVEST audit (B4 evaluation) |
| `prioritize-features` | PRD draft → impact/effort/risk/alignment fit (B4 evaluation) |
| `value-proposition` | PRD draft → JTBD value-prop reframe (B5 sanity check) |

Three are *generation* (the first two and the value-prop reframe). Two are
*evaluation*. The pattern matches the rest of the bootcamp: skills you run
to write **and** skills you run to critique the same artifact.

## Lean philosophy

Each skill is ~70 lines. One job. Pace-shaped — references our personas
(Maya/Raj/Sara · Devi/Caleb), the M1 chain, and the Pace DS tokens where
relevant. **Swappable**: every cohort team will have their own version of
these skills 90 days from now — this kit is a *starter*, not a contract.

## Install

```bash
# from this folder
cp *.md ~/.claude/skills/
```

Verify in any Claude Code session:

```
/analyze-feature-requests --help
/create-prd --help
/user-stories --help
/prioritize-features --help
/value-proposition --help
```

(See `INSTALL.md` for the long form + uninstall.)

## What's NOT in the kit

The upstream repo has 60+ more skills covering strategy, discovery,
operations, and craft. Notable ones to bring in if you outgrow this kit:

- **`opportunity-solution-tree`** — Teresa Torres framework, links outcomes
  to solutions and experiments. Best after M3 when teams want to audit
  whether the M2 prototype tested the right opportunity.
- **`identify-assumptions-existing`** — risk assumption mapping for a
  feature already in build. Pair with `value-proposition` once your
  prototype has user-test data.
- **`brainstorm-ideas-new`** — multi-perspective ideation. Skip during the
  bootcamp; useful when your team is generating from a blank-page brief.

Add them via the same install pattern from the upstream repo if your team
adopts them.

## Authoring notes (for cohort)

The skills are markdown files with a YAML frontmatter (`name`, `description`,
`when_to_use`, `inputs`, `outputs`). Claude Code reads the frontmatter to
decide *whether* to invoke; the body is the prompt template. Edit any
skill in your install folder — your changes survive cohort end.

⋈ Prasad

---
name: prioritize-features
description: Score a candidate feature or PRD draft on a 4-axis grid (impact · effort · risk · alignment) against the rest of the team's roadmap. Surface "fold up" / "fold down" recommendations. Use to evaluate where a PRD ranks before commit.
when_to_use: When the user has a candidate feature (or PRD draft) and wants to know if it ranks against the others on the roadmap — i.e. before committing to ship.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - target_feature: name + 1-line description · OR a PRD draft (markdown)
  - roadmap_context: other features currently on the roadmap · 3-8 items · each with a one-line description
  - product_objective: 1-2 sentences · the quarterly objective
outputs:
  - target_score: 4-axis score (1-5 each · 4-20 total) with rationale per axis
  - rank: where the target sits in the roadmap (top tier · middle tier · bottom tier)
  - fold_recommendation: "fold up" (extend scope · related features to bundle) OR "fold down" (cut scope · MVP-ify) OR "leave as is"
---

# prioritize-features

Lean evaluation skill. Takes a candidate feature against the roadmap context, scores 4 axes, surfaces where it ranks and how to fold it.

## The prompt

```
ROLE: Senior PM running a quarterly prioritisation review. You're not
filling in a spreadsheet — you're deciding whether this feature
deserves the team's quarter.

CONTEXT:
- The cohort just drafted a PRD for one feature
- Before committing, we need to know where it sits relative to the
  other things the team could ship this quarter
- The 4-axis frame: Impact · Effort · Risk · Alignment
  - Impact = magnitude × confidence × time-horizon (1-5)
  - Effort = relative size 1 sprint / 1 quarter / 2 quarters (1-5
    where 5 = SMALL)
  - Risk = how likely we are wrong about user need or technical
    feasibility (1-5 where 5 = LOW risk)
  - Alignment = strategic fit with the product objective (1-5)
- Pure scores are useless without rationale — every axis must have
  a one-sentence reason

INPUT:
  target_feature:   [name + 1-line description · OR paste PRD]
  roadmap_context:  [3-8 other features on the roadmap · each one-liner]
  product_objective: [1-2 sentences]

TASK:
  1. Score the target feature on each axis (1-5). One sentence
     of rationale per axis. Sum.

  2. Briefly score each roadmap_context feature on the same 4 axes
     (no rationale needed — just the score). Sum each.

  3. Rank the target against the others. Report which tier it lands
     in: top (top third by total), middle, bottom.

  4. Make a fold recommendation for the target:
     - FOLD UP: extend scope. Bundle 1-2 related features from
       roadmap_context that would compound. Name them.
     - FOLD DOWN: cut scope. MVP-ify — what's the smallest version
       that tests the riskiest assumption from the PRD? Name it.
     - LEAVE AS IS: it's ranked + scoped right.

OUTPUT FORMAT:
  - Target scorecard (4 rows): axis · score · rationale
  - Ranking table: all features (target + roadmap_context) · totals ·
    tier marker (top/mid/bottom)
  - Fold recommendation: 1 paragraph · cite the assumption being
    tested if FOLD DOWN, the compound bet if FOLD UP

CONSTRAINT:
  - Do not invent roadmap items not in the input. If roadmap_context
    has only 3 items, work with 3.
  - Do not score axes you can't substantiate. If the PRD doesn't
    give you what you need for Risk, score 3 (default) and note
    "input gap" in rationale.

REFLECTION:
  Before output, ask: "If the team has 1 quarter and 1 designer-eng
  pair, would I greenlight this feature in this scope?" Your
  recommendation should answer that question, not just rank.
```

## Example invocation

```bash
/prioritize-features --file ./prd-smart-pause-draft.md \
  --roadmap ./q3-roadmap.md \
  --objective "Reduce streak-break churn by 2pp in Q3"
```

Pair with `/user-stories` for the two-skill PRD evaluation pass in S06 Block 4.

---
name: user-stories
description: Audit a PRD draft against the 3 C's (Card · Conversation · Confirmation) and INVEST criteria. Surface missing stories, weak acceptance criteria, and stories that should be split. Use to evaluate a PRD before commit, not to write stories from scratch.
when_to_use: When the user has a PRD draft and wants to know if every user need has a well-formed story behind it — i.e. before passing the PRD to engineering or design for prototyping.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - prd_draft: markdown · the working PRD (from /create-prd or elsewhere)
outputs:
  - story_table: one row per derivable story · INVEST score (1-5 per axis) · gap call
  - missing_stories: list of user needs in the PRD that have NO story
  - top_3_gaps: the three weakest stories with rewrite suggestions
---

# user-stories

Lean evaluation skill. Takes a PRD draft, derives the user stories it implies, audits each against the 3 C's + INVEST, surfaces gaps.

## The prompt

```
ROLE: Senior PM who runs story-audit rituals before specs go to
engineering. You don't write stories from scratch — you audit what's
implicit in the PRD and flag the gaps.

CONTEXT:
- The cohort drafted this PRD in the last 20 minutes
- The point of this audit is to surface what's missing or weak BEFORE
  the team commits the PRD as v2
- 3 C's: Card (the one-line story) · Conversation (what the story
  opens for discussion) · Confirmation (the acceptance criteria)
- INVEST: Independent · Negotiable · Valuable · Estimable · Small ·
  Testable

INPUT:
  prd_draft: [paste the PRD here · or pass --file path]

TASK:
  1. Read the PRD. List every distinct user need the Solution section
     implies. Be generous — include implicit needs (e.g. "user wants
     to know why" if the PRD names a notification).

  2. For each need, write the story it implies in Card form:
        "As a [persona], I want [intent], so that [outcome]."
     If you can't write a coherent Card, that's a gap — flag.

  3. For each story, score INVEST (1-5 per axis). Sum to a 6-30 score.

  4. Pull the three weakest stories (lowest INVEST score). For each:
     - Rewrite suggestion (one sentence)
     - Conversation prompt: what the PM-Designer-Eng triad needs to
       discuss before this story is ready
     - Confirmation: one Given/When/Then acceptance test

  5. List user needs in the PRD that you couldn't derive a story for
     — these are "missing stories" and the PRD likely under-specifies
     them.

OUTPUT FORMAT:
  - Story table (markdown): id · card · I · N · V · E · S · T · total · note
  - Missing stories section: bulleted list with quote from PRD
  - Top 3 gaps section: card · rewrite · conversation prompt ·
    Given/When/Then

CONSTRAINT:
  - Don't invent stories the PRD doesn't imply. If the persona is
    not mentioned in a section, that's a gap, not an invitation to
    backfill.
  - Distinguish gaps in the PRD from weak stories. Both go in the
    output, in their own sections.

REFLECTION:
  Before output, ask: "If I gave this PRD + my story-audit to an eng
  lead, would they commit to a sprint?" If no, the gaps + top-3 are
  the conversation list, not the spec.
```

## Example invocation

```bash
/user-stories --file ./prd-smart-pause-draft.md
```

Or paste the PRD inline. Pair with `/prioritize-features` for a
two-skill evaluation pass.

---
name: value-proposition
description: Reframe a PRD draft into a 6-part JTBD value-prop (Jobs · Pains · Gains · Products · Pain relievers · Gain creators). Use as a sanity-check before commit — if you can't fill the 6 parts, the PRD has a gap.
when_to_use: When the user has a PRD draft and wants a value-prop reframe to test whether the feature actually maps to a customer job (vs solving a feature-request that has no underlying job).
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - prd_draft: markdown · the working PRD
  - persona: the persona the PRD targets (Maya / Raj / Sara · Devi / Caleb · or team's)
outputs:
  - value_prop_canvas: 6-part structure · 2-4 bullets per part
  - mismatch_flags: any of the 6 parts you can't fill from the PRD
  - one_line_reframe: the value prop in one sentence the persona would recognise
---

# value-proposition

Lean evaluation skill. Takes the PRD draft + the target persona, reframes the feature as a JTBD value proposition. If you can't fill the 6 parts, the PRD has a gap.

## The prompt

```
ROLE: Senior product strategist running a JTBD value-prop pass on
a PRD before it commits.

CONTEXT:
- The cohort drafted a PRD in the last 30 minutes
- This is the sanity-check pass: if the PRD doesn't map to a real
  customer job, the feature won't earn its place
- The 6-part value prop is the Strategyzer canvas:
  CUSTOMER side:
    Jobs       — what the persona is trying to get done
    Pains      — what's bad about how they get it done today
    Gains      — what success looks like for them
  PRODUCT side:
    Products    — what you're shipping (features, components)
    Pain relievers — how those features remove specific pains
    Gain creators  — how those features create specific gains
- Each side must map: every Product to at least one Pain reliever or
  Gain creator; every Pain reliever to a real Pain; every Gain creator
  to a real Gain. Asymmetry = gap.

INPUT:
  prd_draft: [paste or pass --file]
  persona:   [Maya / Raj / Sara / Devi / Caleb · or named persona]

TASK:
  1. CUSTOMER side: read the PRD's Background, Market Segment, and
     Value Proposition sections. Extract 3-4 Jobs, 3-4 Pains, 3-4
     Gains. Cite the PRD line each comes from.

  2. PRODUCT side: from the PRD's Solution section, list 2-4 Products
     (the things being shipped — features, components, behaviours).
     For each, write the Pain reliever AND Gain creator it offers.
     Cite the PRD line.

  3. Match each Product to the Pains/Gains it addresses. If a Product
     doesn't address a real Pain or Gain — flag it (probably
     scope creep). If a Pain has no Pain reliever in the Products —
     flag it (likely PRD gap).

  4. Write the value prop in one sentence the persona would actually
     recognise. Format:
        "We help [persona] who wants to [job], by [products], so they
         can [primary gain] without [primary pain]."

OUTPUT FORMAT:
  - Customer side (3 bulleted lists): Jobs · Pains · Gains (with PRD
    citations)
  - Product side (table): Product · Pain reliever · Gain creator · PRD line
  - Mismatch flags: bulleted list · each one a gap or scope creep
  - One-line value prop

CONSTRAINT:
  - Customer-side bullets must be in the persona's voice. "I want X"
    not "the user wants X."
  - Do not invent Jobs/Pains/Gains the PRD doesn't surface. If you
    can only extract 2 Jobs, list 2 — the gap is the signal.
  - The one-line value prop must use the persona's name (or "I" if
    quoting), not "user" or "customer."

REFLECTION:
  Before output, ask: "Would [persona] read this and say 'yes, that's
  me'?" If you'd hedge, the PRD's Market Segment or Value Proposition
  section is the gap — flag it.
```

## Example invocation

```bash
/value-proposition --file ./prd-smart-pause-draft.md --persona Raj
```

Pair with `/user-stories` and `/prioritize-features` — together they're the three-skill PRD evaluation pass before commit.