---
name: concept-slides
description: "Use to produce a marp slide deck that captures a product or feature concept at low fidelity — hook, concept overview, visual sketches, user journey, what's deferred. Iterate with the user before any wireframing or prototyping. The deck is the lowest-fidelity artifact in the pipeline; it answers 'are we building the right thing?' before fidelity escalates."
---

# Concept Slides

## Overview

A concept deck is the cheapest artifact in the pipeline. It exists to verify the WHAT before the team commits to the HOW. The deck has hook + 3-5 sub-concepts + visual sketches + user journey + explicit deferrals. That's it. If the user can't react to a 5-15 slide deck, they can't react to a wireframe either — start here.

**Core principle:** low fidelity is the feature. The deck is meant to be edited, rejected, redirected. It should take an hour or two of dispatched work to produce, not a day. Match that ambition: short, sharp, sketch-grade.

**Announce at start:** "I'm using the concept-slides skill to produce a marp deck for [concept]."

## When to Use

- Phase 1 of a prototype-driven flow (after discovery, before wireframing)
- For `/feature` on existing apps: a 1-3 slide mini-deck — what the feature is, where it sits, the visual sketch. Often a single slide.
- Ad-hoc when a user wants to put a concept on paper before building anything

**Do NOT skip when:**
- The concept "feels obvious" — obvious concepts still benefit from a sketch the user can react to. Skipping the deck is how scope creep starts.
- The user is in a hurry — the deck is the cheap artifact; resist the temptation to skip to wireframes

**Do NOT use this skill for:**
- Marketing decks, sales pitches, finalized presentations (use the underlying `marp-slides` skill directly with full-fidelity intent)
- Replacing the wireframe — the deck has visual sketches, NOT a UI specification. The wireframe comes next.
- Replacing requirements documentation — the deck is a starting artifact; the spec emerges through iteration

## What concept-slides produces

A single marp deck at `decks/{name}/slides.md` that conforms to:

| Slide | Purpose | Length |
|---|---|---|
| 1. Hook | The question the product/feature answers | 1 slide; one sentence |
| 2. Concept overview | 3-5 sub-concepts, one per slide; each with one-sentence description + tiny visual | 3-5 slides |
| 3. Visual sketches | Per concept, low-fidelity sketches (HTML/SVG embedded in marp; NOT full UI mockups) | 2-4 slides |
| 4. User journey | The flow at low fidelity — boxes, arrows, named steps | 1-2 slides |
| 5. Out of scope | Explicit deferrals; what this concept is NOT | 1 slide |

Total target: 8-15 slides for a full product concept; 1-3 slides for a `/feature` concept on an existing app.

The deck is rendered with `marp` and previewed in HTML so the user can click through. Iteration takes 1-3 cycles for full products, often 1 for features.

## What concept-slides does NOT produce

- A wireframe (Phase 2 deliverable; uses `build-wireframe` skill)
- A prototype (Phase 3 deliverable; uses `build-prototype` skill)
- An architecture doc (Phase 5 deliverable; uses `harden`)
- A finalized pitch deck (use `marp-slides` directly for finalized presentations)

If the user asks for "a real deck for the leadership pitch," use `marp-slides` with full presentation intent — concept-slides is intentionally low-fidelity.

## Inputs

| Source | Required | Purpose |
|---|---|---|
| Rough concept brief from the user | yes | One-sentence to one-paragraph description of what's being built |
| Discovery output (if existing repo) | if discovery ran | Codebase conventions, existing UX patterns to align with |
| Reference decks the user likes | optional | Style/composition reference (links or paths) |

## Process

### Step 0: orient

Read:
- `~/.claude/skills/marp-slides/SKILL.md` — the marp engine and its rendering rules
- 2-3 example decks in `~/.claude/skills/marp-slides/examples/` matching the concept's style (overview decks, journey decks, sketch-style decks)
- The user's brief

If no brief is provided, ask the user 1-3 clarifying questions and stop until answered. Do not invent the concept.

### Step 1: dispatch the concept-designer subagent

The deck content (slide drafts, visual sketches, user-journey diagrams) is synthesized by the `concept-designer` subagent in its own context window. The main session aggregates the result and writes the file.

Dispatch with:
- The user's brief
- Discovery output if available
- Reference deck paths if any
- Target output path (`decks/{name}/slides.md`)

The subagent returns slide-by-slide content, with sketch markup inline (HTML/SVG that renders in marp).

### Step 2: write the deck file

Write the deck to `decks/{name}/slides.md` using the marp frontmatter the subagent returned. Common frontmatter:

```yaml
---
marp: true
theme: default
paginate: true
size: 16:9
---
```

### Step 3: render and present

Render with marp:

```bash
npx @marp-team/marp-cli decks/{name}/slides.md --html --output decks/{name}/slides.html
```

Open `decks/{name}/slides.html` in the user's browser. The user clicks through and gives feedback.

### Step 4: iterate

User feedback drives revisions:
- Concept missing → add a slide
- Concept off → revise the description and sketch
- Visual sketch wrong → redraw
- Journey wrong → reorder steps or simplify

Re-dispatch the subagent with the feedback as part of the prompt; rewrite the deck; re-render. 1-3 iterations is typical.

### Step 5: lock

When the user emits "concept locked" (or equivalent), the phase closes. The locked deck is the input to Phase 2 (`build-wireframe`).

Update the manifest at `.forge/work/{type}/{name}/manifest.yaml`:
- `artifacts.concept.deck_path: decks/{name}/slides.md`
- `artifacts.concept.locked_at: <ISO-8601 timestamp>`

Presence of `artifacts.concept.locked_at` is the lock signal that Phase 2 (`build-wireframe`) reads to confirm the concept is locked before proceeding.

## Visual sketch guidance

Sketches inside marp slides use HTML/SVG inline. Keep them low-fidelity:

- Boxes, arrows, named regions — NOT pixel-perfect mockups
- Fonts: system; colors: 2-3 max; no shadows / gradients / animations
- One concept per sketch; if you need multiple sketches per slide, you have multiple concepts (split slides)

Avoid:
- Full UI mockups (that's the wireframe's job)
- Detailed icons (the wireframe will have lucide-react; the deck has emoji or simple shapes)
- Real data (use placeholders like "ITEM 1", "USER A")
- Click interactions (the deck is static; the wireframe handles interactivity)

## Common mistakes

| Mistake | Fix |
|---|---|
| Treating the deck as a finalized pitch | It's a draft; lower the polish bar to "sketch-grade" |
| Embedding real UI mockups | Move that to Phase 2 wireframe; sketches in the deck are boxes-and-arrows |
| Producing a 30-slide deck | Cap at 15 for full products, 3 for features. Cut or split. |
| Skipping the "out of scope" slide | The deferral list IS the spec — what NOT to build is as important as what to build |
| Iterating with the user before the first render | Render first, get feedback against something concrete; don't iterate against imagined slides |
| Inventing concepts the user didn't ask for | Ask 1-3 clarifying questions instead; do not synthesize beyond the brief |

## Red Flags

**Never:**
- Build a polished marketing deck under this skill (different intent — use `marp-slides` directly)
- Skip the "out of scope" slide — defining what's NOT built is half the value
- Iterate without rendering — text-only edits invite imaginary feedback
- Carry a draft to Phase 2 without an explicit user lock

**Always:**
- Render to HTML and let the user click through — that's the iteration surface
- Cap iterations at 3 for full products; surface "are we converging?" on iteration 4
- Update the manifest at lock — the deck path becomes input to wireframe + prototype phases

## I/O Contract

| Field | Value |
|---|---|
| **Requires** | User brief, target output path, optional discovery output |
| **Produces** | `decks/{name}/slides.md` (marp source) + `decks/{name}/slides.html` (rendered preview) |
| **Updates manifest** | `artifacts.concept.{deck_path, locked_at}` |
| **Feeds into** | `build-wireframe` (Phase 2 — wireframe extends the visual sketches into clickable HTML) |

## Integration

| Caller | When |
|---|---|
| Phase 1 of `/feature` and `/greenfield` | Default flow entry point for prototype-driven work |
| Manual invocation | When a concept needs sketching outside a workflow |

| Dispatches | For |
|---|---|
| `concept-designer` subagent | Slide content synthesis in own context window |

| Pairs with | For |
|---|---|
| `marp-slides` (user-level skill) | Underlying rendering engine — concept-slides specializes the format |
| `build-wireframe` | Phase 2 successor — wireframer reads the locked deck as input |
| `discover-codebase-analysis` | If existing repo, supplies UX/convention context |