---
title: Product Pipeline
description: >-
  A list of all skills under /product:*, and the traceability IDs each skill
  issues
seo:
  image: /ogp.png
---
There are 27 skills in total under /product:*. The table below shows the main skills used in the `full` profile (the configuration that runs everything end to end).

The table below contains a lot of jargon and abbreviations, but you don't need to memorize all of it at once. Each skill's detail page explains it again in full.

## Commands and key options

You don't need to call each skill individually. `/product:start` runs them in dependency order for you.

```
/product:start [description of what you want to build] [--profile=mvp|core-only|ux-to-spec|full] [--frontend|--no-frontend] [--auto] [--lang=ja|en]
```

| Option | Meaning |
|---|---|
| `--profile` | The range of phases to run. Defaults to `full`. See [Pipeline Dependency Graph](/concepts/dependency-graph) for details |
| `--frontend` / `--no-frontend` | Whether to run the optional `generate-frontend` phase. If omitted, you'll be asked interactively |
| `--auto` | Skip intermediate confirmations and run through to completion |
| `--lang` | The language of the generated documentation |

| Skill | Phase | Output |
|---|---|---|
| `define-vision` | Phase 1 | A Vision Board (a diagram summarizing the future vision in 5 elements) + a PR-FAQ (a technique of writing the imagined press release and Q&A first, in Amazon's Working Backwards format) |
| `define-success-metrics` | Phase 1 | A <Tooltip tip="The single metric a business values most as its measure of success." headline="North Star Metric" cta="View in glossary" href="/glossary">North Star Metric</Tooltip> + 3–5 supporting input metrics + guardrails (constraint metrics that prevent drift) |
| `research-landscape` | Phase 1 | Bottom-up TAM/SAM/SOM (a three-tier metric representing the market size you can target) + a competitive matrix + Kano classification (a technique for separating features by appeal) + a PoD/PoP strategy (a strategy for points of differentiation from, and parity with, competitors) |
| `design-revenue` | Phase 1 | A Lean Canvas (a diagram summarizing a business model on one page) + a revenue model + unit-economics (profitability per customer) templates |
| `define-scope` | Phase 1 | Constraint classification + MoSCoW (a technique for splitting priority into four tiers) + RICE scores (a technique for quantifying priority from factors such as impact) |
| `validate-assumptions` | Gate | A list of assumptions ranked by the impact of their failure + a validation plan + a Go/No-Go verdict (a decision on whether to proceed as-is or go back and redo work) |
| `name-product` | Phase 1 (optional) | Generates acronym product-name candidates, working backward from the language used in the Vision |
| `generate-persona` | Phase 2 | JTBD (Jobs-to-be-Done — the idea that "the thing the user actually wants to get done") personas, with proto-personas (provisional personas) clearly marked |
| `map-journey` | Phase 2 | A stage × layer journey map + Moments of Truth (the decisive moments where the customer's evaluation is formed) |
| `design-positioning` | Phase 2 | The Dunford 5 components (the five elements that define positioning) + the Hook model (a mechanism for getting users to adopt habitual use) + a touchpoint matrix |
| `create-domain-story` | Phase 2 | Domain Storytelling (a technique for diagramming business flows in terms of actors/work items/activities). The skeleton of the UI mocks |
| `design-system` | Phase 2 (standalone) | DTCG tokens (values from a common standard for centrally managing colors, sizes, etc.) + a component inventory (a list of UI parts) |
| `generate-ui-mock` | Phase 3 | A set of standalone HTML screens that switch when clicked |
| `define-features` | Phase 3 | Converts on-screen operations into Commands (units of executable functionality) + MoSCoW |
| `example-map` | Phase 3 | Uses Example Mapping (one session per feature) to surface business rules (`RULE-`), concrete examples (`EX-`), and unresolved questions (`OQ-`) |
| `define-data-model` | Phase 3 | Extracts entities (subjects of data — e.g., users or orders) in two passes (explicitly stated ones + implicit ones inferred from the CRUD matrix) |
| `generate-frontend` | Phase 3 (optional) | Generates a React + Storybook frontend implementation into `generated/frontend/` from the UI mocks and design system (structured by Atomic Design layers) |
| `map-domains` | Phase 4 | Core/Supporting/Generic subdomain classification + bounded contexts (a DDD term for the boundary within which the same word can mean something different) + a context map |
| `design-api` | Phase 4 | API design across three layers: System/Process/Experience |
| `design-sla` | Phase 5 | SLI/SLO/SLA (how service quality is measured, targeted, and promised) + error budgets (the amount of failure that's tolerable) + a criticality tier (ranking by importance) |
| `define-nfr` | Phase 5 | Measurable <Tooltip tip="Non-Functional Requirements. Requirements other than 'what it can do,' such as performance, reliability, and security." headline="NFR (Non-Functional Requirements)" cta="View in glossary" href="/glossary">NFRs</Tooltip> derived from the SLOs (Service Level Objectives) |
| `design-architecture` | Integration | A runtime/critical-path (the path of the most time-consuming processing) /deployment diagram + a technology-fit assessment (Kong/ScalarDB/ScalarDL) |
| `review` | Phase R | A review from four perspectives: Consistency/Traceability/Extensibility/Strategy |
| `report` | Phase R | A consolidated HTML report with "Key Assumptions & Validation Status" placed at the top |

## A detailed walkthrough of each skill

The table above is an overview. You can expand each phase below to see what actually happens.

### Phase 1 — Determine direction

<Accordion>
  <AccordionItem title="/product:define-vision — Vision definition (opus)">
    The output is two documents: a Vision Board (`VIS-` ID) and a PR-FAQ (in Amazon Working Backwards format — the technique of writing the press release first).

    - **Vision Board**: The five elements Vision (the aspired-to state), Target Group, Needs, Product, and Business Goals, plus Mission (how it will be realized) and Values (the criteria for judgment).
    - **PR-FAQ**: A press release (headline → sub-headline → summary → problem in the customer's own words → solution → quote and CTA), plus an external FAQ (pricing, features, purchasing, support) and an internal FAQ (market size, competitors, unit economics, risks, and **Go/No-Go criteria**). The Go/No-Go criteria written here are not decorative — they become the gate that `validate-assumptions` actually enforces.
    - **Domain Vision Statement**: A single paragraph naming the core domain (the area that generates the most value), part of the `VIS-` ID. The downstream `map-domains` cites it as the basis for its Core classification, and raises a finding if a Core domain isn't named by this statement.
  </AccordionItem>

  <AccordionItem title="/product:define-success-metrics — Defining success metrics (opus)">
    The output is a success-metrics document with an `NSM-` ID. It selects one North Star Metric (a leading indicator of revenue that reflects value received by the customer — not raw sales or a vanity metric), and selects 3–5 input metrics the team can directly move, mapped to either AARRR or HEART (a single user-behavior model). Each metric comes with a measurement method, target, and guardrail. This `NSM-` becomes the basis for the RICE Impact score and revenue hypotheses in later stages.
  </AccordionItem>

  <AccordionItem title="/product:research-landscape — Market and competitive research (opus)">
    The output is a market overview (TAM/SAM/SOM, computed bottom-up in principle), a competitive matrix, Kano classification (Must-be → PoP/parity, Delighter → PoD/differentiation), and strategic recommendations. Every figure, competitor, and claim is cited with a source (name + URL).
  </AccordionItem>

  <AccordionItem title="/product:design-revenue — Revenue model design (opus)">
    The output is a revenue-model document with a `REV-` ID, plus a recomputable revenue-evaluation template. It selects a revenue model using either a Lean Canvas (for high-uncertainty new ventures) or the BMC's 9 blocks, and outputs LTV, CAC, LTV:CAC ratio (target 3+), CAC payback period, and ROI/NPV as formulas. Price and CAC are treated not as fixed values but as "TBD-assumption" (assumptions to be validated), and value hypotheses of the form "If we invest X, metric Y will move by Z% within some period" are written tied to the `NSM-`.
  </AccordionItem>

  <AccordionItem title="/product:define-scope — Scope definition (sonnet)">
    The output is a constraint list with `CON-` IDs (budget, deadlines, technology, legal/regulatory, organizational) and a scope definition with an `SCP-` ID. It produces an In-Scope/Out-of-Scope table (the "won't-do list" is mandatory — it prevents scope from expanding without limit), MoSCoW classification, and RICE scores (using the NSM as the basis for Impact when available).
  </AccordionItem>

  <AccordionItem title="/product:validate-assumptions — Validating assumptions (opus, validation gate)">
    The output is an assumption list with `ASM-` IDs, a validation plan, and a Go/No-Go verdict. This is the validation gate that always runs right after Phase 1.

    1. **Rank assumptions by the impact of their failure**

        Classify the assumptions the strategy depends on into Desirability (will they want it), Viability (will it be profitable), and Feasibility (can it be built), and prioritize by "how much of the strategy collapses if this turns out wrong."

    2. **Choose the cheapest way to test each**

        For each top-ranked assumption, assign the cheapest validation method — customer interviews; a smoke-test/fake-door landing page (a fake entry point set up just to measure reaction); a concierge MVP (manually operating the back end to validate value alone); Wizard of Oz (making the back end appear automated when it isn't); or **pre-sales**, the strongest method for validating Viability — along with a kill/pivot threshold.

    3. **Produce a Go/No-Go verdict**

        If unvalidated, high-risk assumptions remain, the verdict is No-Go, and it is recorded in `work/pipeline-progress.json`. This can be rerun as evidence accumulates.
  </AccordionItem>

  <AccordionItem title="/product:name-product — Product naming (opus, optional in Phase 1)">
    The output is a collection of product-name candidates with an `NAM-` ID. It builds a per-letter English word bank derived from the vocabulary used in the Vision, Values, and differentiators/domain, and presents each candidate as a pair: a "short, pronounceable string" and its "one-letter-per-word full expansion." Candidates are scored against naming criteria (distinctiveness, brevity, pronounceability, appropriateness, expandability, protectability), narrowed to three, and one is recommended, with the rationale tied back to the `VIS-` ID. Confirmation of availability (e.g., trademark checks) is left as an Open Question and is never claimed to have been confirmed.
  </AccordionItem>
</Accordion>

### Phase 2 — Build the skeleton of users and screens

<Accordion>
  <AccordionItem title="/product:generate-persona — Persona generation (opus)">
    The output is job stories with `JOB-` IDs (in the form "When [situation], I want to [goal], so that I get [outcome]," covering functional, emotional, and social dimensions) and persona cards with `PER-` IDs (archetype, context and behavior, JTBD, Pains, Gains, verbatim quotes). Anything not grounded in real data is explicitly marked `[proto]`. Demographic details and quotes are never fabricated.
  </AccordionItem>

  <AccordionItem title="/product:map-journey — Customer journey mapping (sonnet)">
    The output is a journey map with a `JNY-` ID. For each primary persona, it builds a grid of stages (awareness → consideration → purchase → onboarding → usage → renewal → advocacy) × layers (touchpoints, actions, verbatim emotions and emotion curve, pains, opportunities), and places Moments of Truth (ZMOT/FMOT/SMOT — the decisive moments where evaluation is formed) at the dips in the emotion curve. The substantive output is a prioritized opportunity list.
  </AccordionItem>

  <AccordionItem title="/product:design-positioning — Positioning design (opus)">
    The output is a positioning document with `POS-`/`HOOK-` IDs.

    1. **Build a Dunford 5-component canvas**

        Organize the five components: competitive alternatives, unique attributes, value (and its justification), target market segment, and market category.

    2. **Separate differentiation from parity**

        Decide which items go to PoD (differentiation points) versus PoP (parity points), as classified during market research.

    3. **Build a touchpoint × device × timing table**

        For each touchpoint in the journey, organize which device the message reaches and when it's delivered.

    4. **Build a Hook canvas**

        Design the mechanism that produces habitual use: Trigger → Action → Variable Reward → Investment.

    5. **Plan the refresh of Kano delighter features**

        Because delighters tend to feel "expected" over time, establish a plan to keep refreshing them.
  </AccordionItem>

  <AccordionItem title="/product:create-domain-story — Domain story creation (opus)">
    The output is domain stories with `STORY-` IDs, one per persona × key job. It writes out, as a single happy path, the steps by which a specific persona (`PER-`) accomplishes a job (`JOB-`), following the order of the journey (`JNY-`). Each step is later converted into a screen by `generate-ui-mock` (one activity = one screen action).

    It is composed of the three elements of Domain Storytelling (a technique for diagramming business flows) — **Actors** (the persona themself and the people/systems they interact with), **Work Items** (the objects being handled, named from the journey/job vocabulary), and **Activities** (numbered actions). The architect side has a skill of the same name, but it differs in that it starts from existing actor definitions on the legacy path.

    Specifying `--mode=event-storming` switches to a different approach, Process Modeling (writing an event/command/actor/read model/policy per step), but the `STORY-` IDs and registry it writes stay the same.
  </AccordionItem>

  <AccordionItem title="/product:design-system — Building a design system (opus, standalone in Phase 2)">
    The output is a design system managed independently under `design-system/{name}/`. It is kept separate from a single pipeline run so it can be reused, versioned, and swapped out.

    - **Tokens**: `tokens.json` (DTCG format) + `tokens.css`. Raw values for color, typography, spacing, radius, elevation, and motion, plus semantic aliases (e.g., `color.bg/fg/primary/danger`).
    - A **component inventory** (`CMP-` ID), **guidelines** (including accessibility criteria), a **manifest**, and **preview HTML**.

    You can choose to build it fresh from positioning and personas, or import (`--import`) an existing Tailwind/DTCG/Figma Tokens/CSS theme. The "visual language" built here is what `generate-ui-mock` uses.
  </AccordionItem>
</Accordion>

### Phase 3 — Turn screens and features into specs

<Accordion>
  <AccordionItem title="/product:generate-ui-mock — UI mock generation (sonnet)">
    The output is a set of navigable, click-through HTML mocks (one file per screen, inline CSS) under `reports/02_spec/ui-mocks/`.

    - Each screen is derived from the corresponding activity in a domain story (one activity = one screen action). For high-priority jobs, 2–3 approaches are briefly compared and the rationale for the chosen one is recorded.
    - Screen transitions are wired with real `<a href>` links, so you can click through a story from start to finish. Steps that don't yet exist become disabled `TBD` links rather than broken ones.
    - The design system's `tokens.css` is injected into every screen, so all mocks share the same visual language (at mid fidelity, component styles are applied too).
  </AccordionItem>

  <AccordionItem title="/product:define-features — Feature definition (sonnet)">
    The output is a feature list with `FEAT-` IDs. It converts each screen action in the UI mocks into a Command (a unit of executable functionality), reconciles it against scope (Out-of-Scope items are excluded from the start), and attaches traceability to `JOB-`/`JNY-`/`NSM-` along with a MoSCoW priority. If the UI mocks are empty, execution stops.

    The same `feature-list.md` also carries a User Story Map (journey stages as the backbone, `FEAT-` as stories, MoSCoW bands as release slices). It decides nothing new — just a second view of the same feature list.
  </AccordionItem>

  <AccordionItem title="/product:example-map — Example Mapping (opus)">
    The output is, per feature (`FEAT-`), the business rules (`RULE-`), concrete examples on both sides of each rule (`EX-`), and the questions the session couldn't settle (`OQ-`, Open Questions). `rules/product/example-mapping.md` defines how to run an Example Mapping session with the four-color cards (rule/example/question/feature), and where to harvest examples from (existing acceptance criteria, domain stories, persona quotes, etc.).

    These `RULE-`/`EX-` entries are converted into `Rule:`/`Scenario:` blocks by `generate-test-specs`, into acceptance criteria by `export-backlog`, into invariant candidates by `design-aggregate`, and into FR acceptance criteria by `define-requirements`.
  </AccordionItem>

  <AccordionItem title="/product:define-data-model — Data model definition (opus)">
    The output is a data model with `ENT-` IDs and a Mermaid ER diagram.

    1. **Pass 1: Read explicit entities**

        Extract entities that are clearly stated from screens, forms, and actions.

    2. **Pass 2: Surface implicit entities**

        Build a feature × entity CRUD matrix, and from it add implicit entities (joins, history, audit logs, state transitions, etc.) with supporting rationale.
  </AccordionItem>

  <AccordionItem title="/product:generate-frontend — Frontend generation (sonnet, optional in Phase 3)">
    The output is a complete React + TypeScript frontend under `generated/frontend/` that runs with just `npm install && npm run storybook`. The UI mocks define "what each screen does," the design system defines "the visual language," and this skill turns both into actual components.

    - Each design-system component (`CMP-`) is placed at the appropriate Atomic Design layer (atoms/molecules/organisms/templates). For each component, it generates a `.tsx` (typed props), a `.module.css` (referencing only tokens, never raw values), and a `.stories.tsx`.
    - Each UI mock screen becomes a single Page component, and the story's transitions (next/back) are wired as real routing via react-router.
  </AccordionItem>
</Accordion>

### Phase 4–5, Integration — Translate into domains and architecture

<Accordion>
  <AccordionItem title="/product:map-domains — Domain mapping (opus)">
    The output is a domain map (classifying subdomains into Core/Supporting/Generic, with investment guidance — build Core in-house, be pragmatic about Supporting, buy Generic), bounded contexts with `CTX-` IDs (a context map — using relationship patterns such as ACL, Open Host/Published Language, Shared Kernel, Customer/Supplier, Conformist, and Partnership — plus rough consistency hints: Strong/Eventual/TBD), and a ubiquitous language.

    The consistency hints are just hints — the architect side's `define-requirements` makes the final ACID/Saga/local-transaction determination per business process. architect also has a `map-domains` of the same name, but it classifies domains from `analyze`'s analysis results, so its input differs.

    Each bounded context is written as a nine-part Bounded Context Canvas, so it can be compared part by part against the same Canvas as redesigned on the architect side. Specifying `--mode=event-storming` lets you find boundaries a different way, via Big Picture EventStorming (laying out the timeline of events and treating pivotal events as boundary candidates).
  </AccordionItem>

  <AccordionItem title="/product:design-api — Logical API design (opus)">
    The output is an API design document with `API-` IDs. It classifies APIs into three layers — System (CRUD), Process (business-flow orchestration), and Experience (per channel) — and produces a one-directional dependency graph (Experience → Process → System) along with an OpenAPI sketch for each API (key paths, methods, and request/response shapes). The goal is to maximize reuse; the architect side's `design-api` later turns this into concrete protocols and specs.
  </AccordionItem>

  <AccordionItem title="/product:design-sla — SLA design (sonnet)">
    The output is per-service SLI/SLO/SLA with `SLA-`/`SLO-` IDs, error budgets (1 − SLO) and their operating policy, and a criticality tier (critical/standard/best-effort). Targets are aligned with customer expectations, and SLOs are set stricter than SLAs.
  </AccordionItem>

  <AccordionItem title="/product:define-nfr — NFR definition (sonnet)">
    The output is non-functional requirements with `NFR-` IDs (availability, latency (p95/p99), throughput, error rate, durability, RPO/RTO, and scalability/security/observability where needed). Each NFR states a numeric value (or TBD) and the SLO it was derived from.
  </AccordionItem>

  <AccordionItem title="/product:design-architecture — Integrated architecture design (opus)">
    The output is an architecture document with an `ARCH-` ID (a runtime/container diagram, a critical-path sequence diagram, and a deployment/scaling diagram) and a technology-fit assessment with a `TECH-` ID.

    For each of five technologies — Kong (API gateway), ScalarDB, ScalarDB Analytics, ScalarDB Saga, and ScalarDL — it evaluates fit (High/Medium/Low/None), the rationale (with cited source IDs), an **Adopt/Conditional/Reject** decision, and adoption conditions and risks. ScalarDB Saga is considered only "when cross-context processing can be eventually consistent" or "when a step calls an external system" — adopting ScalarDB itself does not automatically mean ScalarDB Saga is adopted too.
  </AccordionItem>
</Accordion>

### Operations and utilities

<Accordion>
  <AccordionItem title="/product:review — Four-perspective review (opus)">
    The output is `reports/report/review.md`. It produces findings — each with severity (blocker/major/minor), location, and a concrete fix — from four perspectives: consistency (broken ID references, contradictions, terminology drift), traceability (correspondence between `work/traceability.json` and the documents, orphaned references), extensibility (domain boundaries and API reusability against future features), and strategy (alignment between Vision and scope, health of unit economics, durability of differentiation). It can be rerun any number of times, even mid-pipeline.
  </AccordionItem>

  <AccordionItem title="/product:report — Consolidated report generation (sonnet)">
    The output is `reports/report/full-report.html`, a self-contained HTML report (with inline Mermaid diagrams). **"Key Assumptions & Validation Status" is always placed first** — it lists the gate verdict, unvalidated assumptions, every TBD, and Open Questions by status, so you can distinguish "questions no one has asked yet" from "questions intentionally left open." Each phase's sections follow in order after that.
  </AccordionItem>

  <AccordionItem title="/product:adapt-change — Re-propagating a change (opus)">
    The output is a change log, an impact analysis, and updated artifacts. It computes the affected scope from `work/traceability.json` (a mechanical enumeration of downstream reach → opus judgment → human confirmation), and reruns only the affected skills. Impact on IDs owned by the architect side is only reported, not rerun here.

    1. **Record the change**

        Record the change content, its type (constraint/market/competitor/technology/regulation), a timestamp, and a before/after diff for each artifact rerun (so it can be reverted).

    2. **Analyze the affected scope**

        Produce a list mapping "change → affected ID → whether to re-evaluate + why."

    3. **Rerun only the minimum needed**

        Rerun only the affected skills, using existing artifacts as input, and update the corresponding links in `work/traceability.json`.
  </AccordionItem>

  <AccordionItem title="/product:init-output — Output initialization (sonnet)">
    Creates the directory structure and state files (`work/pipeline-progress.json`, the traceability graph, etc.) needed to run the `product` pipeline. It never discards existing state without `--reset`.
  </AccordionItem>

  <AccordionItem title="/product:start — Launching the pipeline (sonnet)">
    This skill runs the phases in dependency order for you, so you don't need to call each skill individually.

    1. **Choose a profile**

        Choose one of `mvp` (a minimal configuration with just Vision + Scope + validation), `core-only`, `ux-to-spec`, or `full` (specifiable via `--profile`).

    2. **Run init-output and proceed in dependency order**

        Run skills in dependency order, updating `work/pipeline-progress.json` after each phase.

    3. **Pass through the gate right after Phase 1**

        If `validate-assumptions` returns a no-go verdict, it doesn't proceed and instead redoes Phase 1 on the spot. It won't move to the next phase until the verdict is go.

    4. **The full profile also inserts design-system steps**

        After `design-positioning`, it runs `create-domain-story` → `design-system` before moving on to `generate-ui-mock`.

    5. **Frontend generation is optional**

        Whether `generate-frontend` runs is either specified explicitly via `--frontend`/`--no-frontend` or confirmed interactively (with `--auto`, it follows the profile).
  </AccordionItem>
</Accordion>

<Panel title="A design trait shared across every phase">
The most consistent trait of this design is that **every phase issues its own ID and appends it to
a file called `work/traceability.json`**. For example, the chain runs `VIS-001` (Vision) →
`NSM-001` (North Star) → `SCP-001` (scope item) → `FEAT-001` (feature) → `ENT-001` (entity) →
`CTX-001` (bounded context) → `API-001` (API), so it can be mechanically traced from the upstream
process all the way to the downstream one.
</Panel>

```mermaid
flowchart LR
  VIS["VIS-001<br/>Vision"] --> NSM["NSM-001<br/>North Star"]
  NSM --> SCP["SCP-001<br/>Scope Item"]
  SCP --> FEAT["FEAT-001<br/>Feature"]
  FEAT --> ENT["ENT-001<br/>Entity"]
  ENT --> CTX["CTX-001<br/>Bounded Context"]
  CTX --> API["API-001<br/>API"]
```

For details on execution profiles (the configuration for which skills run together and how),
see the [Pipeline Dependency Graph](/concepts/dependency-graph).