Product Pipeline

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.

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.

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

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

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

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.

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.

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.

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.

The output is a positioning document with POS-/HOOK- IDs.

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.

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.

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

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.

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.

The output is a data model with ENT- IDs and a Mermaid ER diagram.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

This skill runs the phases in dependency order for you, so you don’t need to call each skill individually.