# 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 (baseline · fallback Tab 1 input if a PM has none) |
| **`prd-prompt-reviewer`** | **PM raw PRD prompt → 7-item coverage map (S06 gdoc · Tab 2 · step 2)** |
| **`prd-prompt-fuser`** | **All raw prompts + coverage maps → fused group PRD skill (S06 gdoc · Tab 2 · step 3 → Tab 4)** |
| **`ux-critique-seed`** | **Seed UX critique prompt for Gauri's refinement (S06 gdoc · Tab 3 → Tab 5 once refined)** |
| `prd-critic` | PRD draft → six-item checklist critique + the one change to lock it (reference baseline · runs in shared Claude Project) |
| `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) |

The S06 B3 flow runs on the three **bold** prompts above — a meta layer that takes each PM's raw existing PRD-writing prompt and fuses the group's inputs into one team skill, while the designer side seeds a UX critic for Gauri to refine. The other six are generation/evaluation tools for PRD content itself (`create-prd` writes, `prd-critic` audits, etc.) and stay available throughout the build break.

## 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: prd-critic
description: Run a constructive, checklist-driven critique on a PRD draft. Surfaces what's covered, what's partially covered, and what's uncovered — with one specific suggestion per gap. Paste into a shared Claude Project, attach the PRD, run.
when_to_use: When you have a PRD draft (your own or your group's) and want a structured, ship-rigor critique before locking it. Use right after /create-prd or before the build break.
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 or attached doc · the PRD to critique
  - audience: 1 line · who this PRD is for (your group · the build break · S10 leadership)
outputs:
  - critique: markdown · per-item verdict (covered · partially · uncovered) + one specific suggestion per gap + the one change that locks the PRD
---

# prd-critic

A checklist-driven PRD critic. Six items. Constructive wording — every gap gets one specific suggestion, not a generic complaint. Ends with the **one change** that moves the PRD from draft to ready.

## How it fits the bootcamp

Pair it with `create-prd` — that one generates, this one critiques the same artifact. Both live in your group's **shared Claude Project** alongside the design Critic Skill so the PM and design surfaces converge.

## The prompt

```
ROLE: Constructive PRD critic for a product team about to enter a one-week
build break. Your job is not to judge — your job is to surface the one
specific change that moves this PRD from draft to ready.

CONTEXT:
- The team has one week to prototype against this PRD
- A senior-leadership showcase happens four weeks from now
- The PRD must answer six questions (see CHECKLIST)
- Constructive wording: name the gap AND the specific add that closes it
- No vague feedback (avoid "this could be clearer" — say what would make it clearer)

INPUT:
  prd_draft:  {{PRD_DRAFT}}   # paste PRD markdown OR attach the doc
  audience:   {{AUDIENCE}}    # your group · the build break · S10 leadership

TASK: Review the PRD against the six-item checklist below. For each item,
give one of three verdicts and a single specific suggestion.

  CHECKLIST
  1. PROBLEM
     One sentence, grounded in a real workflow. Not a hypothetical.
     Not a feature description dressed up as a problem.

  2. TARGET PERSONA
     A named persona (real one if possible) + why this persona for this
     problem. "Everyone" is uncovered.

  3. SMALLEST M2 PROOF
     One screen, one flow. The smallest version that still demonstrates
     the value to a non-engineer. If it needs three screens, it's not
     small enough.

  4. DATA SOURCE + WIRING TIER
     Where does the data live today (sheet, API, existing dataset)?
     Which wiring tier — T1 real API · T2 Google Sheet · T3 JSON fixture?
     If the source isn't named, this is uncovered.

  5. DEMO-ABLE IN 90 SECONDS
     Can a non-engineer in the audience see the value in 90 seconds?
     If the demo needs a 5-minute setup, it's not demo-able yet.

  6. OUT OF SCOPE
     What this PRD explicitly will NOT do. Without this, scope creeps
     during the build break.

OUTPUT FORMAT: markdown, in this exact shape.

  # PRD critic · [PRD title]

  ## 1. PROBLEM
  Verdict: covered | partially | uncovered
  What's there: [quote or paraphrase what the PRD says]
  What's missing: [one specific gap, or "nothing — covered"]
  Suggestion: [one concrete change. e.g., "Replace 'users struggle to
  find content' with 'goal reviewers can't see goal history older than
  90 days during quarterly reviews' — name the workflow and the time
  constraint."]

  ## 2. TARGET PERSONA
  [same shape]

  ## 3. SMALLEST M2 PROOF
  [same shape]

  ## 4. DATA SOURCE + WIRING TIER
  [same shape]

  ## 5. DEMO-ABLE IN 90 SECONDS
  [same shape]

  ## 6. OUT OF SCOPE
  [same shape]

  ## The one change
  If the team can only fix one thing before the build break, it's this:
  [one sentence. Specific. Actionable. Names the section + the exact edit.]

REFUSAL: If the PRD draft is too short or too vague to evaluate against
the checklist (under ~150 words or no concrete details), refuse with:
"PRD draft needs at least a problem statement, a persona, and one
proposed flow before this critic can give useful feedback. Add those
and re-run."
```

## How to use it

1. Open your group's **shared Claude Project**.
2. Paste the prompt above as a starter asset (or attach this whole file).
3. Attach your PRD draft (markdown, doc, or paste inline).
4. Fill `audience` based on which lens you want (group review · build break · S10 leadership).
5. Run. The output is paste-able into the PRD doc as a "review pass" section.

Re-run after edits. Track which items move from `partially` to `covered` between runs — that's the ship-rigor signal.

## What this isn't

- Not a PRD generator. Use `create-prd` for that.
- Not a UX/prototype critic. The **UX critic** prompt lands in S07 (once prototypes exist to critique).
- Not a final verdict. The team decides what to fix. The critic just surfaces the choices.

---

*Built by Prasad Gupte · Product Builder · v0.1.0*

---
name: prd-prompt-fuser
description: Merge multiple PM raw PRD prompts + reviewer coverage maps into one fused group PRD skill. Preserves each prompt's named strength; adds every "one specific add" surfaced by the reviewer. Output is a Claude Skill ready to upload to the shared Project.
when_to_use: After every PM in the group has run prd-prompt-reviewer and a coverage map exists for each raw prompt. Fuses 3-5 PRD prompts into one group skill.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - raw_prompts: markdown · all PM raw prompts (each as a clearly labeled section)
  - coverage_maps: markdown · all reviewer outputs (each as a clearly labeled section)
  - group_name: 1 line · the group's chosen name (e.g., "Goals Velocity")
outputs:
  - fused_skill: markdown · a complete Claude Skill (YAML frontmatter + body) ready to upload to the group's shared Claude Project
---

# prd-prompt-fuser

Takes raw PM prompts + reviewer outputs → one fused group PRD skill. The fused skill keeps each contributor's named strength and incorporates every "one specific add" the reviewer surfaced.

## The prompt

```
ROLE: Senior prompt engineer fusing multiple PRD-writing prompts
into one team skill. Your output will be uploaded to the group's
shared Claude Project and used for every PRD they write through
the build break and beyond.

CONTEXT:
- Each PM in the group contributed a raw prompt + a reviewer
  coverage map for that prompt
- Your job is to PRESERVE each contributor's named strength AND
  ADD every "one specific add" the reviewer surfaced
- The output must be a complete, paste-able Claude Skill —
  frontmatter + body, not a sketch
- Aim for ~70-100 lines total. Lean. Pace-shaped.
- The skill is for PRD WRITING (drafting), not PRD critique

INPUT:
  group_name:     {{GROUP_NAME}}
  raw_prompts:    {{RAW_PROMPTS}}     # paste all PM raw prompts, clearly labeled
  coverage_maps:  {{COVERAGE_MAPS}}   # paste all reviewer outputs

TASK: Produce the fused skill in this exact shape.

  STEP 1 — Extract DNA
  For each input prompt, identify the one strength the reviewer
  named ("strength to preserve"). List them in a hidden scratch
  block (don't output this — use it to inform the fuse).

  STEP 2 — Extract adds
  For each coverage map, identify the "one add that locks it."
  Aggregate. De-dupe. Keep the unique ones.

  STEP 3 — Fuse
  Write one Claude Skill that:
  - Drafts a PRD in 6 sections (problem, persona, smallest M2
    proof, data source + wiring tier, demo-able test, out-of-
    scope)
  - Embeds the strengths from STEP 1 (named contributors get
    credit in a comment)
  - Embeds every add from STEP 2
  - Has a REFUSAL clause for thin inputs
  - Is ~70-100 lines (lean — not a kitchen sink)

OUTPUT FORMAT: a complete markdown file with this structure.

  ---
  name: {{GROUP_NAME}}-prd-skill
  description: [one line — what this skill does and when to use it]
  when_to_use: [one line — the trigger signal]
  model: claude-sonnet-4-6
  authors: [list the PMs whose raw prompts contributed]
  version: 0.1.0
  inputs:
    - feature_name: [3-5 words]
    - persona: [named BW persona]
    - ...
  outputs:
    - prd_draft: markdown · 6 sections · Pace-shaped
  ---

  # {{GROUP_NAME}} PRD skill

  [one paragraph — what this skill does. Name the contributor
  strengths inline: "Builds on Veronica's checklist discipline
  and Paul's wiring-tier rigor."]

  ## The prompt

  ```
  ROLE: ...

  CONTEXT:
  - ...

  INPUT:
    feature_name:      [3-5 words]
    persona:           [BW persona]
    m1_finding:        [the signal that surfaced this]
    product_objective: [quarterly objective]

  TASK: Draft the PRD with these 6 sections.

    1. PROBLEM
       [instructions, embedding the strengths + adds for this section]

    2. TARGET PERSONA
       ...

    3. SMALLEST M2 PROOF
       ...

    4. DATA SOURCE + WIRING TIER
       ...

    5. DEMO-ABLE TEST
       ...

    6. OUT OF SCOPE
       ...

  OUTPUT: markdown PRD, 6 sections, paste-able into the gdoc.

  REFUSAL: [the refusal clause — Claude refuses if inputs are too
  thin to draft against]
  ```

  ---

  *Fused by {{GROUP_NAME}} · S06 · Product Builder bootcamp · v0.1.0*

REFUSAL: If you receive only one raw prompt (nothing to fuse) or
no coverage maps (nothing to add), refuse with: "Need at least 2
raw prompts + their coverage maps to fuse. Run prd-prompt-reviewer
on each PM's prompt first, then come back."
```

## How to use it

1. Open the **S06 gdoc** → **Tab 2 (PM master prompts)**.
2. Paste this prompt into your Claude tab.
3. Collect all PM raw prompts (from Tab 1) + all coverage maps (the reviewer outputs you pasted back into Tab 1).
4. Fill `group_name`, `raw_prompts`, `coverage_maps`.
5. Run. Output is a complete fused Claude Skill.
6. Paste the fused skill into **Tab 4 (Final group PRD skill)**.
7. Upload to your group's shared Claude Project as a skill.

## What this isn't

- Not a critic. Doesn't evaluate the fused skill (run it on a real PRD to evaluate).
- Not a writer. Doesn't draft a PRD — it produces the skill that drafts PRDs.
- Not a designer-side fuser. The UX critique side has its own seed prompt that Gauri will refine separately.

---

*Built by Prasad Gupte · Product Builder · v0.1.0*

---
name: prd-prompt-reviewer
description: Audit one PM's existing PRD-writing prompt/skill against a 7-item checklist. Constructive wording — names what's covered, what's partial, and what could be added. Output is paste-able into the gdoc to anchor the fuse step.
when_to_use: When a PM has exported their current PRD-writing prompt as markdown and wants a constructive coverage map before fusing with the group's other prompts.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - raw_prompt: markdown · the PM's existing PRD-writing prompt or skill, pasted as-is
  - author_name: 1 line · whose prompt this is (for the output header)
outputs:
  - coverage_map: markdown table · 7 items × verdict + specific add suggestion
---

# prd-prompt-reviewer

A constructive coverage audit for an existing PRD-writing prompt. Reviews against a 7-item checklist drawn from the bootcamp's PRD discipline: problem, persona, smallest M2 proof, data source + wiring tier, demo-able, out-of-scope, refusal clause.

Output is a paste-able coverage map. Use it to feed `prd-prompt-fuser` next.

## The prompt

```
ROLE: Constructive prompt-engineering reviewer with PRD discipline.
Your job is not to grade — your job is to surface what each PM's
prompt already does well and what one specific add would make it
ship-rigor for the build break.

CONTEXT:
- The PM wrote this prompt for their own PRD work; it's their tool
- The group will fuse 3-5 of these into one shared group PRD skill
- Your output becomes input for the fuser — be specific, not vague
- Constructive wording: "covered" / "partial" / "absent" + one concrete add per gap
- Never say "this prompt is weak." Say what would make it stronger.

INPUT:
  raw_prompt:    {{RAW_PROMPT}}
  author_name:   {{AUTHOR_NAME}}

TASK: Audit the prompt against the 7-item PRD checklist. For each
item, name the verdict and give one specific add that would close
the gap.

  CHECKLIST
  1. PROBLEM STATEMENT
     Does the prompt force a one-sentence, real-workflow problem
     (not a feature description)?

  2. TARGET PERSONA
     Does it require naming a specific persona + why this one?

  3. SMALLEST M2 PROOF
     Does it ask for the one screen / one flow that demonstrates
     value (not a full feature spec)?

  4. DATA SOURCE + WIRING TIER
     Does it require naming where data lives (sheet, API, dataset)
     and the wiring tier (T1 / T2 / T3)?

  5. DEMO-ABLE IN 90 SECONDS
     Does it test for whether a non-engineer would see value in 90s?

  6. OUT-OF-SCOPE
     Does it require explicit out-of-scope listing (anti-scope-creep)?

  7. REFUSAL CLAUSE
     Does the prompt instruct Claude to refuse when input is too thin
     to evaluate? (e.g., missing problem, missing persona)

OUTPUT FORMAT: markdown, in this exact shape.

  # Coverage map — {{AUTHOR_NAME}}'s PRD prompt

  | # | Item | Verdict | What's there | One specific add |
  |---|------|---------|--------------|------------------|
  | 1 | Problem statement | covered / partial / absent | [quote or paraphrase] | [one specific change, named] |
  | 2 | Target persona | ... | ... | ... |
  | 3 | Smallest M2 proof | ... | ... | ... |
  | 4 | Data source + wiring tier | ... | ... | ... |
  | 5 | Demo-able in 90s | ... | ... | ... |
  | 6 | Out-of-scope | ... | ... | ... |
  | 7 | Refusal clause | ... | ... | ... |

  ## The one strength to preserve
  [One sentence — what this prompt does better than a generic PRD
  template, named specifically. The fuse step keeps this DNA.]

  ## The one add that locks it
  [One sentence — the single most important add. The fuse step
  must include this.]

REFUSAL: If the raw_prompt is under ~100 words or is not actually a
PRD prompt (e.g., it's a meeting agenda or a roadmap doc), refuse
with: "Input doesn't look like a PRD-writing prompt — paste a
prompt that instructs Claude to draft or scope a PRD, then re-run."
```

## How to use it

1. Open the **S06 gdoc** → **Tab 2 (PM master prompts)**.
2. Paste this prompt into your Claude tab.
3. Open **Tab 1 (PM raw prompts)** and copy one PM's raw prompt + name.
4. Run. Output is the coverage map.
5. Paste the coverage map back into Tab 1 under the same PM's section.
6. Repeat for each PM. Then move to `prd-prompt-fuser`.

## What this isn't

- Not a grader. Verdicts are descriptive, not evaluative.
- Not a fuser. This audits one prompt at a time; the fuse step is a separate prompt.
- Not a PRD critic. (That's `prd-critic.md`, which runs on PRDs, not on PRD prompts.)

---

*Built by Prasad Gupte · Product Builder · v0.1.0*

---
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: ux-critique-seed
description: Starting-point UX critique prompt — persona-lens, DS-token-grounded, refusal-bearing. A seed Gauri (or the lead designer) refines inside her Claude Design Project to produce the group's final UX critic.
when_to_use: When a group needs a UX critic for their prototype but hasn't yet refined one. The designer runs this seed inside their Claude Design Project (Figma connector active, DS files loaded), iterates against 1-2 real screens, and produces the final UX critic for S07 + the build break.
model: claude-sonnet-4-6
author: Prasad Gupte <grow@prasadgupte.com>
copyright: "© 2026 Prasad Gupte · Product Builder"
version: 0.1.0
inputs:
  - screen_or_proto: image or Figma frame · what's being critiqued
  - persona: 1 line · named BW persona (Maya / Raj / Sara / Devi / Caleb · or your team's persona)
outputs:
  - critique: markdown · 5 interaction-level findings + token adherence + one specific suggestion per gap
---

# ux-critique-seed

A seed UX critique prompt. Five interaction beats (entry · primary action · error · empty · exit) viewed through one persona lens, refused against the loaded DS tokens.

This is a **starting point** — Gauri (or your group's lead designer) refines it inside her Claude Design Project against 1-2 real screens, then promotes the refined version into the group's shared Claude Project as the final UX critic.

## The prompt

```
ROLE: Constructive UX critic for an in-progress prototype. Your
output will be read by a designer mid-iteration, not by leadership.
Specificity over politeness — name the gap and the specific fix.

CONTEXT:
- The DS files (tokens, components, personas) are loaded in this
  Project — treat them as the source of truth
- One screen / one flow at a time. Don't critique the whole product.
- Persona-lens — the same screen has different P0s for different
  personas; one persona per run.
- Cite tokens by path when calling out adherence (e.g.,
  color.semantic.primary, not "the blue button")

INPUT:
  screen_or_proto:  {{SCREEN_OR_PROTO}}   # attach the frame or paste the image
  persona:          {{PERSONA}}           # named BW persona

TASK: Critique against 5 interaction beats + DS-token adherence.
For each beat, give: what's there, what's missing for this persona,
one specific add.

  THE 5 BEATS
  1. ENTRY — How does {persona} arrive here? What's the source
     surface? Is the entry expectation set?

  2. PRIMARY ACTION — What's the one thing {persona} came to do?
     Is it visually unmistakable? One tap / one scan?

  3. ERROR STATE — What breaks for {persona}? (Wrong input, no
     network, no permission, no data yet.) Is the recovery one tap?

  4. EMPTY STATE — First-run / no-data view. Does it teach the
     interaction, not just decorate the void?

  5. EXIT — How does {persona} leave with something? (Success
     state, save, share, hand-off.) Is the next surface obvious?

  DS-TOKEN ADHERENCE
  Walk the screen. For each visible component, cite the token or
  flag the off-system value. Specific paths.

OUTPUT FORMAT: markdown, in this exact shape.

  # UX critique — [screen name] · viewed as {persona}

  ## 1. Entry
  What's there: [observation]
  Gap for {persona}: [what's missing / unclear]
  Suggestion: [one specific add, named]

  ## 2. Primary action
  [same shape]

  ## 3. Error state
  [same shape]

  ## 4. Empty state
  [same shape]

  ## 5. Exit
  [same shape]

  ## DS-token adherence
  - color.semantic.primary — used correctly on CTA ✓
  - typography.body.large — off-system (custom size 17px instead of token) ⚠
  - spacing.lg — used correctly between sections ✓
  ...

  ## The one change
  If the designer can only fix one thing before the next sprint,
  it's this: [one sentence. Specific. Names the element + the edit.]

REFUSAL: If no DS files are attached / loaded in this Project,
refuse with: "DS files (tokens, components, personas) need to be
loaded in this Project before I can cite token adherence. Drop
the DS files in, then re-run." If no persona is named, refuse
with: "Name a specific persona — UX critique without a persona
lens drifts to generic."
```

## How Gauri refines this

1. Open her Claude Design Project (Figma connector active, DS files loaded).
2. Paste this seed prompt.
3. Run it on 1-2 real BW screens with a named persona.
4. Iterate the prompt based on what landed and what didn't:
   - Did Claude cite tokens by path? If not, tighten the "cite by path" instruction.
   - Did the persona lens make the critique different from generic? If not, add persona-specific constraints to the CONTEXT block.
   - Did the REFUSAL fire when it should? If not, tighten the refusal conditions.
   - Did the output format paste cleanly into Figma comments? If not, simplify the output shape.
5. Promote the refined version into the group's **shared Claude Project** as the final UX critic.
6. Paste the final into **Tab 5 (Final design critique skill)** of the S06 gdoc so the rest of the cohort can see it.

## What this isn't

- Not the final UX critic. This is the seed Gauri refines.
- Not a PRD critic. (That side runs separately — see `prd-prompt-reviewer` + `prd-prompt-fuser`.)
- Not a design system audit. Token adherence is one section, not the whole job.

---

*Built by Prasad Gupte · Product Builder · v0.1.0*

---
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.

# AI Leadership Team — 5 stress-test personas

**Purpose:** PRD stress-test pattern. Generate the 5 cross-functional reviews your PRD would face — *before* the actual reviews.

**When to use:** Once you have a PRD draft. Run all 5 personas. Consolidate findings. Revise.

**Model:** Claude Sonnet 4.6 for all 5.

**Cost:** ~$0.05 per PRD per persona on a 1-page PRD. Total per stress-test: ~$0.25.

---

## How to run

Option A — five parallel Claude windows, one persona each.
Option B — one Claude window with a multi-persona orchestrator:

```
Run these 5 critiques on the attached PRD, in sequence. After each, label
the section <persona> findings. Do not blur them into a single voice.

[paste all 5 persona prompts below, separated by ---]
```

Option C (most cost-effective) — Claude Code with a sub-task per persona using parallel tool calls.

---

## Persona 1 — Senior Engineering Lead

```
ROLE: You are a senior engineering lead at <Company> (10+ years
      shipping production systems). You review every PRD before it
      enters sprint planning.

CONTEXT: <Company> = <one-line product>. Stack: <attach stack notes>.
         Engineering capacity is finite; we're trying to spot the
         hidden complexity early.

INPUT: <paste PRD>

TASK: Critique this PRD as an engineering review.

  - What's the *real* complexity here? Name it.
  - Where will this break? Concurrency, data shape, edge cases, latency.
  - What dependencies aren't named in the PRD but you can infer?
  - What's the smallest thing that could ship and prove the thesis?
    (You don't need the full feature to learn.)
  - Where are the implicit performance budgets? (Page load? Cold start?
    Background sync?)
  - What's the testing strategy? Where's the eval surface?

OUTPUT FORMAT: Ranked findings (P0 / P1 / P2), with rationale per item.
              Then a "smallest ship" proposal — 1 paragraph.

REFLECTION: Before output, name the one thing the PM didn't address that
            will cause a sprint-2 surprise.

CONSTRAINT: Be direct. Engineering reviews aren't here to be polite.
            But also: no gatekeeping. If something is genuinely possible,
            say so.
```

---

## Persona 2 — Senior Design Lead

```
ROLE: You are a senior design lead at <Company> (10+ years in product
      design). You review every PRD for design implications before
      designer time is committed.

CONTEXT: <Company> = <one-line product>. DS: <attach DS overview>.
         Design system maturity affects what's actually feasible.

INPUT: <paste PRD>

TASK: Critique this PRD as a design review.

  - What's the design's hidden constraint? Where does it strain the DS?
  - What patterns have we used before? Are we reinventing?
  - What state coverage is missing? (Default / empty / loading / error /
    partial / offline.)
  - Accessibility: contrast, touch targets, screen reader behavior?
  - Where does this fit in the user's journey? Is this a *new* surface,
    a re-use of an existing one, or a contested one?
  - Microcopy: is the voice in the PRD already drifting? Flag it.

OUTPUT FORMAT: Ranked findings (P0 / P1 / P2), with rationale per item.
              Then: one "best DS reuse" recommendation — 1 paragraph.

REFLECTION: Before output, identify any moment where the PRD assumes
            a designer will improvise. Name those moments — they're
            where DS gaps emerge.

CONSTRAINT: No "could be more delightful" hand-waving. Name the
            specific design move.
```

---

## Persona 3 — CFO / Finance

```
ROLE: You are the CFO at <Company>. You review PRDs that have
      revenue, cost, or unit-economics implications.

CONTEXT: <Company> = <one-line product>. Business model: <one line>.
         ARPU: <if known>. Gross margin target: <if known>. We're
         capital-disciplined.

INPUT: <paste PRD>

TASK: Critique this PRD from a finance / unit-economics lens.

  - What does this cost to BUILD? (Person-weeks, infrastructure.)
  - What does this cost to RUN? (Per-user compute, AI inference,
    third-party APIs, support volume.)
  - What's the gross-margin impact? Express as % of ARPU.
  - What's the cheapest variant that proves the thesis?
  - What's the upside? (Retention lift, conversion, ARPU expansion.)
  - When does this pay back? (Months to break even on build cost.)
  - What's the cost-of-being-wrong? (Sunk build + opportunity cost.)

OUTPUT FORMAT: Numbered findings with numbers (even rough estimates).
              Don't hand-wave. Then: a "cheapest variant" proposal.

REFLECTION: Before output, name the one cost assumption in this PRD
            that is most likely wrong. Flag it.

CONSTRAINT: No "this looks expensive but". Make the case explicitly.
            And no "we'll figure it out" — finance reviews require
            specific numbers, even if rough.
```

---

## Persona 4 — Legal / Compliance

```
ROLE: You are senior counsel at <Company>. You review PRDs for
      data, privacy, IP, and regulatory implications.

CONTEXT: <Company> = <one-line product>. Jurisdictions: <list, e.g.,
         US, EU, UK, IN>. Data sensitivity: <e.g., health data,
         financial, employment, consumer behavior>.

INPUT: <paste PRD>

TASK: Critique this PRD from a legal / compliance lens.

  - What user data does this collect, process, or transmit?
  - What's the consent story? Is it explicit, implicit, or assumed?
  - What's the data retention story? Default vs user-controlled?
  - What jurisdictions does this complicate? (GDPR, DPDP, CCPA,
    HIPAA, COPPA, etc.)
  - Third-party APIs — what's the data-sharing posture?
  - AI model usage — are we training on user data? Inference logging?
    Who owns the outputs?
  - Accessibility regulations — anything in scope?
  - IP — anything trademark / copyright / patent adjacent?

OUTPUT FORMAT: Ranked findings (P0 / P1 / P2) with rationale.
              Then: a "minimum-viable compliance" recommendation.

REFLECTION: Before output, name the one decision in this PRD that is
            functionally a legal commitment (e.g., "we'll delete data
            within 30 days") and confirm it's deliverable.

CONSTRAINT: No "consult legal" punt — you ARE legal. Specific findings.
            But also no over-lawyering — name only what genuinely
            requires attention.
```

---

## Persona 5 — VP Sales / GTM

```
ROLE: You are VP Sales at <Company>. You review PRDs to understand
      how the feature changes the GTM motion.

CONTEXT: <Company> = <one-line product>. Sales motion: <e.g., PLG,
         enterprise, hybrid>. Customer segments: <list>. Pricing:
         <one line>.

INPUT: <paste PRD>

TASK: Critique this PRD from a GTM lens.

  - Will customers pay MORE for this? (Premium feature, upsell, plan
    upgrade?)
  - Which customer segment moves first? Which is the laggard?
  - What's the upsell story? (Free → Pro, Pro → Team, Team → Enterprise.)
  - What's the churn-reduction story? Who would leave without this?
  - What does the sales motion look like? (Self-serve, sales-assisted,
    enterprise?)
  - Where does this position vs competitors?
  - What's the demo-ability? (Can a sales person show this in 90s?)
  - Pricing implications — does this need re-packaging?

OUTPUT FORMAT: Ranked findings (P0 / P1 / P2) with rationale.
              Then: a "monetization angle" recommendation.

REFLECTION: Before output, name the one customer conversation that this
            feature would change. Be specific (segment + persona).

CONSTRAINT: Be commercial, not optimistic. If this doesn't move revenue
            or retention, say so. "Vague delight" is not a GTM story.
```

---

## Consolidating findings

After running all 5, produce a "PRD diff" doc:

```
FOR EACH FINDING, mark:
- Which persona surfaced it
- Severity (P0 / P1 / P2)
- Resolution: accept (will change PRD), defer (later), reject (not in scope)
- Owner + deadline

THE THREE MOST-SURPRISING FINDINGS:
1. <persona>: <finding> — why it surprised you
2. <persona>: <finding> — why it surprised you
3. <persona>: <finding> — why it surprised you
```

Save the diff. It's the artifact of the stress-test, and it's gold for the showcase.

---

## Gotchas

- **Don't blend personas.** Five separate critiques > one blurred summary. The whole point is the *different* lenses.
- **Don't auto-accept.** Some findings are wrong. The PM's job is to triage, not capitulate.
- **Pay attention to silence.** If a persona has nothing to say, that's data — the PRD genuinely isn't in their wheelhouse, *or* the persona prompt isn't strong enough. Iterate.
- **Run BEFORE designer + eng time.** Stress-test is cheap; rework is expensive.
- **Reuse the diff for the rest of life.** Same 5 personas critique sprint plans, roadmaps, launch plans. Don't let them die after this PRD.

---

## Reuse across products

Same 5 personas. Swap the CONTEXT line for the new product. Swap the attached files. The personas stay; the company changes.

---

*Built by Prasad Gupte · Product Builder*

# AI-Output Reviewer

Catch what an AI got confidently wrong before you ship it — invented components, missing states, and the persona-fit it can't know. Evaluative.

**Prompt** — paste the AI-generated screen/flow + your persona:

You are my design QA reviewer. An AI generated this screen/flow:

`<AI OUTPUT: the generated screen or flow>`
`<DESIGN SYSTEM: the components/tokens that actually exist>`
`<PERSONA: the real user + their moment>`

Find, specifically:
1. INVENTED — components, patterns, or tokens that aren't in my design system.
2. FAKED UX — plausible-looking flows that skip a real edge case or state.
3. PERSONA MISFIT — where it ignores how the persona actually feels in this moment.
4. OVERLOAD — choices or content the screen doesn't need.

For each, quote the offending part and give the correction. End with a one-line verdict: ship, revise, or restart.

# Fidelity Brief

Turn a prototype question into a build brief — which of the four fidelity axes to dial up, and the leanest spec that answers it. Generative.

**Prompt:**

You are my prototyping strategist. My prototype must answer this question:

`<QUESTION: the one thing this prototype needs to learn>`

For each fidelity axis — VISUAL, CONTENT, FUNCTIONAL, INTERACTIVE — tell me HIGH or LOW and one line why, given only this question. Then:
- Draft the leanest prototype spec that answers the question at those settings.
- Flag any axis I'd be tempted to over-invest in, and what that would waste.

Do not default everything to HIGH. The question sets the dial.

# Mobile Screen Generator

Generate a mobile screen that respects your design system, thumb ergonomics, and *all* the states — not just the happy one. Generative.

**Prompt** — attach or paste your DS tokens + persona:

You are a senior mobile product designer. Design one screen for this spec:

`<SPEC: the screen + its job>`
`<PERSONA: who uses it, in what moment>`
`<DS TOKENS: paste or attach your design-system tokens>`

Constraints:
- Use ONLY the attached tokens — no invented colours, type, or components.
- Thumb-first: primary action in the natural thumb zone; destructive actions out of the easy arc; targets >= 44pt.
- Produce EVERY state: default, pressed, loading, empty, error, success.
- For each state, give the layout, the copy (in the persona's world), and the one microinteraction that sells it.

Output as a state-by-state spec a designer could build in Figma without asking a question.

# Mobile-UX Critic

A senior interaction reviewer for a mobile screen — scores it against the laws, not taste. Evaluative.

**Prompt** — paste a screenshot or a screen description:

You are a senior mobile interaction critic. Here is a screen:

`<SCREEN: screenshot or a precise description of layout + actions>`

Critique it against these lenses, citing the specific element each time:
- FITTS — target size and reach; is the most-used action the easiest to hit?
- THUMB ZONE — what needs a stretch or grip-shuffle one-handed?
- FEEDBACK — does every tap get an immediate visual response?
- STATES — are loading / empty / error / disabled handled, or only the happy path?
- DISCOVERABILITY — any action hidden behind a gesture with no cue?

Rank findings P0/P1/P2. For each, give the fix in one line. Refuse to comment on anything you can't see — say "not visible" instead of guessing.

# Riskiest-Assumption Finder

Before you prototype anything, find the assumption that could kill the idea — so you build *that* first, not the easy screen. Generative.

**Prompt** — paste your idea in the brackets and run:

You are my prototyping strategist. Here is a product idea:

`<IDEA: one paragraph — the feature, who it's for, what it does>`

Do four things, briefly:
1. List the assumptions this idea depends on to succeed.
2. Score each on (a) how uncertain it is and (b) how badly the idea breaks if it's wrong.
3. Name the single RISKIEST assumption — highest uncertainty × highest cost.
4. Tell me the smallest thing I could prototype to test just that assumption, and which of the four prototype jobs it does (explore / validate / communicate / specify).

Be blunt. If my idea has no real risk, say so.

# Test-Plan Drafter

Turn your riskiest assumption into a 15-minute test you can actually run. Generative.

**Prompt:**

You are my research partner. My prototype tests this riskiest assumption:

`<ASSUMPTION: the thing that, if wrong, kills the idea>`
`<PROTOTYPE: what I built to test it>`

Draft a lightweight test plan:
- The one decision this test will inform.
- 3 tasks to give a user (behavioural, not opinion — what they DO).
- 3 questions to ask after, that surface belief without leading.
- The signal that would tell me the assumption is WRONG (so I can't fool myself).

Keep it to something I can run in 15 minutes with 5 users.

# API as a Tool

Hand Claude your backend's API docs as context, have it configure the endpoints as tools it can call, then actually use one. This is the "by hand" version of what MCP standardizes. Generative.

**Prompt (step 1 — configure):**

Here are the docs for my backend API (paste the Swagger/OpenAPI-style notes as a markdown file, or attach `backend-context.md`):

`<API DOCS: base URL, auth, and each endpoint — method, path, params, request body, response shape, one example>`

Do this:
1. List each endpoint as a TOOL: a clear name, what it does, its inputs, and what it returns.
2. For each, note whether it READS (safe, e.g. GET) or WRITES (needs confirmation, e.g. POST/DELETE).
3. Flag anything I should never send in a request (secrets, PII), and the least-access version of each call.
4. Tell me what you'd need from me to actually make a real call (a base URL, a token) versus what you can mock.

**Prompt (step 2 — use it):**

Using the tools you just defined, do this task for me:

`<TASK: e.g. "list the open goals for owner 42", or "create a goal titled X for owner 42">`

Show me the exact request you would send (method, path, headers, body) and the response you'd expect. If it's a WRITE, stop and confirm with me before you'd send it.

**Then — make it reusable:** ask Claude to package the whole thing as a SKILL — name, when-to-use, the tools it wraps, and a guardrail — so you can invoke "talk to my backend" without re-pasting the docs every time.

# Call a Real API as a Tool

See a model reach live data — call a real, public, no-auth API and answer from what comes back. Works in Claude Code (it runs the request) or claude.ai (it fetches the URL).

**A public API you can call right now — Open-Meteo (weather, no key):**

```
https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,wind_speed_10m
```

Swap `latitude`/`longitude` for your city (Google "<city> lat long").

**Prompt:**

Call this public API and use the result to answer me — don't rely on your training, actually fetch it:

`<PASTE THE URL — e.g. the Open-Meteo forecast for your city's lat/long>`

Then tell me, in one line: the current temperature and whether I'd want a jacket.
Show me the exact request you made (method + URL) and the raw fields you used.
If you can't reach it, say so plainly — do not guess the numbers.

**What to notice:** this is the model acting as a *tool user* — it made a real GET request and grounded its answer in live data, not its memory. That's the jump from "chat" to "system." For a backend that needs auth (a token), you don't paste a public URL — you hand Claude the API docs as context and confirm before any write. See `api-as-tool.md` + `backend-context.md`.

# Connector Brief

Scope the one live data connection that would turn your prototype from a demo into a tool. Generative.

**Prompt:**

You help me scope data connectors (MCP). Here is my prototype and a data source:

`<PROTOTYPE: what it does>`
`<SOURCE: the system I'd connect — Aha!, Jira, a sheet, an API — and what lives in it>`

Produce a connector brief:
- WHAT TO READ — the exact entities/fields the prototype needs (no more).
- LEAST ACCESS — read-only? which scope? what it must NOT touch.
- UNLOCKS — what the prototype can do live that it can't with pasted data.
- RISKS — any PII or sensitive fields in that data, flagged now.

Keep the field list minimal — connect the narrowest slice that does the job.

# Data-Safety Check

Before you wire live data, find what must never leave your machine. Evaluative.

**Prompt:**

You are my data-safety reviewer. Here is a connector I'm about to wire:

`<CONNECTOR: the source, the fields I plan to read, where the model runs>`

Assess:
- PII / SECRETS — which fields are personal, confidential, or credentials. Flag each.
- MINIMISE — what I can drop, mask, or aggregate and still do the job.
- SCOPE — the least-access setting that works (read-only? a single project? a view?).
- KEEP LOCAL — what must never go to a shared demo, log, or third party.

End with a clear GO / NO-GO for wiring this on a shared screen, and why.

# Eval Starter

Build a small test set so you know your skill still works after you change it. Generative.

**Prompt:**

You help me write evals. Here is a skill:

`<SKILL: what it takes in and what good output looks like>`

Draft a starter eval set:
- 6-8 test cases covering: a typical input, two edge cases, one adversarial/garbage input, one that should be REFUSED.
- For each: the input, the expected behaviour, and how I'd score pass/fail (be specific — not "looks good").
- The one metric I should watch over time.

Keep it runnable by hand in ten minutes.

# Goals API — backend context

A tiny fake backend so you can see how an API becomes a tool Claude can call.
Paste this whole file into Claude as context, then run the **API as a Tool** prompt.

**Base URL:** `https://api.example-goals.dev/v1`
**Auth:** every request sends a bearer token — `Authorization: Bearer <API_TOKEN>`
**Format:** JSON in, JSON out.

---

## GET /goals — list goals

Read the goals for one owner. Safe, read-only.

**Query params**

| name    | type   | required | notes                                  |
|---------|--------|----------|----------------------------------------|
| owner   | int    | yes      | the user id whose goals to return      |
| status  | string | no       | filter: `open` \| `done` (default all) |
| limit   | int    | no       | max rows, 1–100 (default 20)           |

**Request**

```
GET /v1/goals?owner=42&status=open HTTP/1.1
Host: api.example-goals.dev
Authorization: Bearer <API_TOKEN>
```

**200 OK**

```json
{
  "owner": 42,
  "count": 2,
  "goals": [
    { "id": 1001, "title": "Ship v2 onboarding", "status": "open", "due": "2026-08-15", "progress": 0.4 },
    { "id": 1002, "title": "Cut activation time to <10 min", "status": "open", "due": "2026-09-01", "progress": 0.1 }
  ]
}
```

---

## POST /goals — create a goal

Create a new goal for an owner. This WRITES — confirm before calling.

**Request body**

| field  | type   | required | notes                             |
|--------|--------|----------|-----------------------------------|
| owner  | int    | yes      | user id the goal belongs to       |
| title  | string | yes      | 3–120 chars                       |
| due    | string | no       | ISO date `YYYY-MM-DD`             |

**Request**

```
POST /v1/goals HTTP/1.1
Host: api.example-goals.dev
Authorization: Bearer <API_TOKEN>
Content-Type: application/json

{ "owner": 42, "title": "Interview 5 churned users", "due": "2026-08-30" }
```

**201 Created**

```json
{ "id": 1003, "owner": 42, "title": "Interview 5 churned users", "status": "open", "due": "2026-08-30", "progress": 0 }
```

---

## Errors

| status | meaning                    |
|--------|----------------------------|
| 401    | missing / bad bearer token |
| 404    | owner not found            |
| 422    | validation failed (see `errors[]` in body) |

```json
{ "error": "validation_failed", "errors": [{ "field": "title", "msg": "too short" }] }
```

# Skill Spec Writer

Promote a task you keep re-explaining into a reusable skill spec. Generative.

**Prompt:**

You help me design Claude skills. Here is a task I do repeatedly:

`<TASK: what I do, the inputs I start with, the output I need, how often>`

Write a skill spec:
- NAME — a verb-first, memorable name.
- WHEN TO USE — the trigger, in one line.
- INPUTS / OUTPUTS — what it takes, what it returns.
- STEPS — the ordered instructions the skill follows.
- TOOLS — any actions or data it needs to call.
- GUARDRAIL — the one refusal or check that keeps it honest.

Then tell me: is this genuinely reusable, or a one-off prompt in disguise? Be strict.

# Stack Locator

Find which layer of the stack your project is stuck at — and the next rung to add. Diagnostic.

**Prompt:**

Here is the AI stack, bottom to top: PROMPT -> SKILL -> TOOL -> CONNECTOR -> AGENT.
- Prompt: a one-off request.
- Skill: a packaged, reusable capability.
- Tool: an action the model can take.
- Connector: live access to a real data source.
- Agent: a model running a loop, choosing its own steps.

Here is my project:

`<PROJECT: what it does today, and how — where data comes from, what's automated>`

Tell me:
1. The highest layer my project currently reaches, with evidence.
2. The single next layer that would unlock the most, and why.
3. The concrete first step to add that layer.

Be honest if I'm over-reaching (calling a workflow an "agent") or under-reaching (pasting data I could connect).

# Turn This Into an Agent

Take one action you already do by hand — or that "Where Am I Really?" flagged as agent-worthy — and turn it into a real, runnable agent. Then learn how to run it. Generative.

**Prompt:**

Here is one thing I do repeatedly, by hand, today:

`<ACTION: what I do, the steps I take, what data/tools it touches, and what "done" looks like>`

Design the simplest agent that could do this for me:
1. GOAL — one sentence: what the agent is trying to achieve.
2. LOOP — the perceive -> decide -> act -> observe steps it repeats, and the STOP condition.
3. TOOLS & CONNECTORS — what it needs to read and what it needs to act on (name real ones where you can).
4. GUARDRAIL — the one thing it must never do, and where a human stays in the loop.
5. RUN IT — the concrete way I'd actually run this today (e.g., a Claude Project + skill, a Claude Code command, or a scheduled job), with the exact first command or setup step.

If this honestly doesn't need an agent — a fixed workflow or even a single prompt would do — tell me that instead, and give me the simpler version. Don't manufacture autonomy I don't need.

# Weather → Telegram agent (live-demo recipe)

The S09 climax: a real agent that GETs the weather and POSTs it to your Telegram — invoked manually, schedulable daily. Runs in **Claude Code** (the primary agent harness). Ties together GET + POST + the agent loop + running it locally.

## One-time setup (~3 min)

1. **Make a bot:** Telegram → message **@BotFather** → `/newbot` → copy the token (looks like `123456:ABC-DEF...`).
2. **Get your chat id:** message your new bot once, then open
   `https://api.telegram.org/bot<TOKEN>/getUpdates` in a browser → find `"chat":{"id":<YOUR_CHAT_ID>}`.
   (Or message **@userinfobot** for your id.)
3. Keep the token out of any shared screen.

## The two calls the agent makes

- **GET (read the weather):**
  `https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,wind_speed_10m`
- **POST (send the message):**
  `https://api.telegram.org/bot<TOKEN>/sendMessage` with body `chat_id=<YOUR_CHAT_ID>&text=<message>`

## Run it in Claude Code (invoke manually)

Open Claude Code in a scratch folder and give it this task:

```
You are a weather agent. Do this, then stop:
1. GET the current weather for Berlin from Open-Meteo:
   https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,wind_speed_10m
2. Write a one-line, friendly summary (temp + jacket-or-not).
3. POST it to my Telegram:
   curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
     --data-urlencode "chat_id=$TG_CHAT" --data-urlencode "text=<your summary>"
4. Confirm the message id you got back.
Never print the token.
```

Set the secrets in the shell first (not in the prompt):
```
export TG_TOKEN='123456:ABC...'   TG_CHAT='<your chat id>'
```

Claude Code runs the GET, composes the line, runs the POST — you get a real Telegram ping. That's the aha: **the model chose the steps, used two tools, and did real work.**

## Schedule it (the "agent that runs")

Turn the same task into a cron line so it fires every morning at 07:30:
```
30 7 * * *  cd ~/weather-agent && TG_TOKEN='…' TG_CHAT='…' claude -p "run the weather agent" >> run.log 2>&1
```
Manual invoke any time: `claude -p "run the weather agent"`.

## PG shortcut (own stack)

For your own demo you can skip BotFather and use the existing pipe:
`python3 /Users/Shared/career-agent/tools/aaka_send.py "Berlin: 15°C, light wind — no jacket."`
or the gateway's `schedule_outbound` / `schedule_job` for the scheduled version.

## Honest framing for the room

The *weather-fetch-and-send* is a fixed path — a **workflow**. It becomes an **agent** the moment you let it decide something: which city based on your calendar, whether the weather is even worth messaging about, escalating only if rain > 60%. Reliability first; autonomy only where the path genuinely can't be fixed.

# Weather agent

A tiny, real agent: check the weather and message it to me. One file, runs in **Claude Code** (primary) or **Cowork**. This is the S09 live-climax artifact — and it's built to work for *everyone*, even with nothing set up.

## The task (this is the agent)

You are my weather agent. When invoked, do this and then stop:

1. **GET** the current weather for my city from Open-Meteo (no key needed):
   `https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,wind_speed_10m`
   (Berlin is pre-filled — change the lat/long for another city.)
   If you cannot reach it (some sandboxes block outbound calls), say so plainly and stop — do not invent numbers.
2. Read `current.temperature_2m` and `current.wind_speed_10m`. Write ONE friendly line: the temperature, and jacket-or-not.
3. **Deliver it**, trying these in order and using the FIRST that works:
   - if `TG_TOKEN` and `TG_CHAT` are set → send via Telegram (curl, below);
   - else if `/Users/Shared/career-agent/tools/aaka_send.py` exists → send via that (PG only);
   - **else just PRINT the line to the terminal**, prefixed with `Telegram not configured — here's your message:`.
4. **Never error out because you couldn't send.** Printing the message counts as success. Never print any token.

## How to run it

### In Claude Code (primary)
From this folder:
```
claude -p "$(cat AGENT.md)"
```
…or just type `/weather` (this folder ships a `/weather` command). On Windows PowerShell:
```
claude -p "$(Get-Content AGENT.md -Raw)"
```

### In Cowork (no-code)
New task → attach this `AGENT.md` (or paste the task section) → "run this now" or schedule it daily. Note: some Cowork sandboxes block outbound API calls and have no Telegram connector — if so, it will fetch via its own web tool where possible and otherwise just report the message. That's the failsafe doing its job.

## The Telegram send (option 1 — portable, works for anyone)

One-time: message @BotFather → `/newbot` → copy the token; get your chat id from `https://api.telegram.org/bot<TOKEN>/getUpdates`. Then set them in your shell (not in the prompt) and the send is:
```
export TG_TOKEN='123456:ABC...'   TG_CHAT='<your chat id>'
curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
  --data-urlencode "chat_id=$TG_CHAT" --data-urlencode "text=<your one-line summary>"
```
No token set? No problem — the agent just prints the message to your terminal.

## Why it's an *agent*, honestly

The fetch-and-send is a fixed path — a **workflow**, and that's fine. It becomes an **agent** the moment you let it decide something: which city from your calendar, whether the weather's even worth a ping, escalate only if rain > 60%. Reliability first; autonomy only where the path can't be fixed.

---
description: Check the weather and message it to me (or print it if no messenger is set up)
---

You are my weather agent. Do this, then stop:

1. GET the current weather from Open-Meteo (no key needed):
   `https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,wind_speed_10m`
   (Berlin is pre-filled — change the lat/long for another city.) If you can't reach it, say so and stop; don't invent numbers.
2. Read `current.temperature_2m` and `current.wind_speed_10m`. Write ONE friendly line: temperature + jacket-or-not.
3. Deliver it, first method that works: (a) if `TG_TOKEN` and `TG_CHAT` are set, curl Telegram `sendMessage`; (b) else if `/Users/Shared/career-agent/tools/aaka_send.py` exists, use it; (c) else PRINT the line, prefixed `Telegram not configured — here's your message:`.
4. Never error because you couldn't send — printing is success. Never print any token.

# Where Am I Really?

Paste this into *any* Claude conversation to see what's actually happening under the hood — is it just a prompt, or is a skill / tool / connector / agent in play? — and what's worth building next. Diagnostic. Works on any chat, not just your capstone.

**Prompt:**

Look back over THIS conversation (everything above) and diagnose it against the AI stack:
PROMPT -> SKILL -> TOOL -> CONNECTOR -> AGENT.
- Prompt: a one-off request.
- Skill: a packaged, reusable capability with its own steps and guardrails.
- Tool: an action you took (search, run code, call an API, write a file).
- Connector: live access to a real data source.
- Agent: you running a loop, choosing your own next steps toward a goal.

Tell me, briefly and honestly:
1. The highest layer this conversation actually reached, with evidence from what happened above.
2. Which tools and connectors (if any) were actually in play.
3. If something I keep asking for here could become a reusable SKILL, name it — its inputs, its output, and the one guardrail it needs. If nothing here is repeatable enough to be worth a skill, say so plainly.
4. If any of this would genuinely be better as an AGENT (a loop that decides its own steps), describe what that agent would do and when it would stop. If an agent would be over-engineering, say so — don't invent a use for one.

Do not make things up to fill the answer. "This is just a prompt, and that's the right tool for it" is a valid, useful conclusion.

# Workflow-or-Agent Decider

Decide whether your core flow is a fixed workflow or needs an agent — then draft the right one. Evaluative, then generative.

**Prompt:**

You are a pragmatic AI systems designer who defaults to the simplest thing that works. Here is my capstone's core flow:

`<FLOW: the goal, and how it happens step by step today>`

Do this:
1. Argue the WORKFLOW case (I can enumerate the steps in advance).
2. Argue the AGENT case (the model must decide steps at runtime).
3. Recommend one — and bias hard toward workflow unless the path genuinely can't be known.
4. Draft it: if workflow, the ordered steps; if agent, the goal, the tools, and the stop condition.

Call out if I'm reaching for "agent" just because it sounds better.