---
title: Productパイプライン
description: /product:* にある全スキルの一覧と、各スキルが発行する追跡用ID(トレーサビリティID)
seo:
  image: /ogp.png
---

/product:* には全部で27個のスキルがあります。そのうち、`full`プロファイル(すべてをひととおり実行する設定)で使われる主要なスキルが下の表です。

この表には専門用語や略語がたくさん出てきますが、一度に全部覚える必要はありません。それぞれのスキルの詳細ページで、あらためて説明されます。

## コマンドと主なオプション

個別のスキルを1つずつ呼ぶ必要はありません。`/product:start`が依存関係の順に実行してくれます。

```
/product:start [作りたいものの説明] [--profile=mvp|core-only|ux-to-spec|full] [--frontend|--no-frontend] [--auto] [--lang=ja|en]
```

| オプション | 意味 |
|---|---|
| `--profile` | 実行するフェーズの範囲。省略時は`full`。詳細は[パイプライン依存関係グラフ](/concepts/dependency-graph) |
| `--frontend` / `--no-frontend` | 任意フェーズの`generate-frontend`を実行するかどうか。省略時は対話で聞かれる |
| `--auto` | 途中の確認を省略して最後まで通す |
| `--lang` | 生成されるドキュメントの言語 |

| スキル | フェーズ | 出力 |
|---|---|---|
| `define-vision` | Phase 1 | Vision Board(将来像を5要素でまとめる図)+ PR-FAQ(想定プレスリリースとQ&Aを先に書く手法。Amazon Working Backwards形式) |
| `define-success-metrics` | Phase 1 | <Tooltip tip="その事業が最も重視する、成功を測る1つの指標。" headline="North Star Metric" cta="用語集で見る" href="/glossary">North Star Metric</Tooltip> + それを支える入力指標3〜5件 + ガードレール(逸脱を防ぐための制限指標) |
| `research-landscape` | Phase 1 | ボトムアップで算出したTAM/SAM/SOM(狙える市場規模を3段階で表す指標)+ 競合マトリクス + Kano分類(機能の魅力度を分ける手法)+ PoD/PoP戦略(競合と差をつける点・合わせる点の戦略) |
| `design-revenue` | Phase 1 | Lean Canvas(ビジネスモデルを1枚にまとめる図)+ 収益モデル + ユニットエコノミクス(顧客1人あたりの採算)テンプレート |
| `define-scope` | Phase 1 | 制約の分類 + MoSCoW(優先度を4段階に分ける手法)+ RICEスコア(影響度などから優先順位を数値化する手法) |
| `validate-assumptions` | Gate | 崩れたときの影響が大きい順に並べた仮説リスト + 検証計画 + Go/No-Go判定(このまま進めるか、やり直すかの判定) |
| `name-product` | Phase 1(optional) | 頭字語(略語)のプロダクト名候補を、Visionで使った言葉から逆算して生成 |
| `generate-persona` | Phase 2 | JTBD(Jobs-to-be-Done。「ユーザーが本当に片付けたい用事」という考え方)ペルソナ、proto-persona(仮のペルソナ)を明記 |
| `map-journey` | Phase 2 | ステージ×レイヤーのジャーニーマップ + Moment of Truth(顧客の評価が決まる決定的な瞬間) |
| `design-positioning` | Phase 2 | Dunford 5要素(ポジショニングを決める5つの要素)+ Hookモデル(ユーザーに習慣的に使ってもらう仕組み)+ タッチポイントマトリクス |
| `create-domain-story` | Phase 2 | Domain Storytelling(業務の流れを図にする手法。登場人物/作業対象/活動で表す)。UIモックの骨格 |
| `design-system` | Phase 2(standalone) | DTCGトークン(色やサイズなどを統一管理する共通規格の値)+ コンポーネントインベントリ(UI部品の一覧) |
| `generate-ui-mock` | Phase 3 | クリックすると画面が切り替わる、単体で動くHTML画面のセット |
| `define-features` | Phase 3 | 画面上の操作をCommand(実行できる機能の単位)に変換 + MoSCoW |
| `example-map` | Phase 3 | Example Mapping(1機能=1セッション)で業務ルール(`RULE-`)・具体例(`EX-`)・未解決の疑問(`OQ-`)を洗い出す |
| `define-data-model` | Phase 3 | エンティティ(データの主体。例: ユーザーや注文)を2段階で抽出(明示的に書かれたもの+CRUDマトリクスから読み取れる暗黙的なもの) |
| `generate-frontend` | Phase 3(optional) | UIモックとデザインシステムから、React + Storybookのフロントエンド実装を`generated/frontend/`に生成(Atomic Designの階層で構成) |
| `map-domains` | Phase 4 | Core/Supporting/Genericサブドメイン分類 + 境界コンテキスト(同じ言葉でも意味が変わる範囲の区切り、DDDの用語)+ コンテキストマップ |
| `design-api` | Phase 4 | System/Process/Experienceという3つの階層でのAPI設計 |
| `design-sla` | Phase 5 | SLI/SLO/SLA(サービス品質の測り方・目標・約束)+ エラーバジェット(許容できる障害の量)+ クリティカリティ階層(重要度によるランク分け) |
| `define-nfr` | Phase 5 | SLO(サービスレベル目標)から導出した、測定可能な<Tooltip tip="非機能要件。性能・信頼性・セキュリティなど、「何ができるか」以外の要件。" headline="NFR(非機能要件)" cta="用語集で見る" href="/glossary">NFR</Tooltip> |
| `design-architecture` | 統合 | ランタイム/クリティカルパス(最も時間のかかる処理の経路)/デプロイメント図 + 技術適合性評価(Kong/ScalarDB/ScalarDL) |
| `review` | Phase R | Consistency/Traceability/Extensibility/Strategyという4つの視点でのレビュー |
| `report` | Phase R | 「重要な仮説と検証状況」を先頭に置いた統合HTMLレポート |

## 各スキルの詳しい流れ

上の表は概要です。実際に何をしているかをフェーズごとに開いて見られます。

### Phase 1 — 方向性を決める

<Accordion>
  <AccordionItem title="/product:define-vision — Vision策定(opus)">
    出力はVision Board(`VIS-`ID)とPR-FAQ(Amazon Working Backwards形式。プレスリリースを先に書く手法)の2文書です。

    - **Vision Board**: Vision(目指す姿)・Target Group・Needs・Product・Business Goalsの5要素と、Mission(実現の仕方)・Values(判断の軸)。
    - **PR-FAQ**: プレスリリース(見出し→サブ見出し→要約→顧客の言葉での課題→解決策→引用とCTA)に加え、外部向けFAQ(価格・機能・購入・サポート)と内部向けFAQ(市場規模・競合・ユニットエコノミクス・リスク・**Go/No-Go基準**)。ここで書くGo/No-Go基準は装飾ではなく、`validate-assumptions`が実際に強制するゲートになります。
    - **Domain Vision Statement**: コアドメイン(最も価値を生む領域)を1段落で名指しする文書(`VIS-`IDの一部)。後続の`map-domains`がCoreドメイン分類の判断根拠として引用し、この文書が名指ししていないCoreがあればfindingとして報告します。
  </AccordionItem>

  <AccordionItem title="/product:define-success-metrics — 成功指標の定義(opus)">
    出力は`NSM-`IDの成功指標文書です。North Star Metricを1つ選び(売上の先行指標で、顧客が受け取る価値を表すもの。生の売上や見栄えだけの指標にはしません)、チームが直接動かせる入力指標を3〜5件選んでAARRRまたはHEART(どちらか1つのユーザー行動モデル)にマッピングします。各指標に測定方法・目標値・ガードレールを添えます。この`NSM-`が、後段のRICEのImpactや収益仮説の基準になります。
  </AccordionItem>

  <AccordionItem title="/product:research-landscape — 市場・競合調査(opus)">
    出力は市場概観(TAM/SAM/SOM、原則ボトムアップで算出)・競合マトリクス・Kano分類(Must-be→PoP/パリティ、Delighter→PoD/差別化)・戦略提言です。すべての数値・競合・主張に出典(名称+URL)を添えます。
  </AccordionItem>

  <AccordionItem title="/product:design-revenue — 収益モデル設計(opus)">
    出力は`REV-`IDの収益モデル文書と、再計算可能な収益評価テンプレートです。Lean Canvas(不確実性の高い新規事業向け)またはBMCの9ブロックで収益モデルを選び、LTV・CAC・LTV:CAC比(目安3以上)・CAC回収期間・ROI/NPVは数式のまま出力します。価格やCACは確定値ではなく「TBD-assumption(検証すべき仮定)」として扱い、「Xを出せば指標Yがある期間内にZ%動く」という形の価値仮説を`NSM-`と結びつけて書きます。
  </AccordionItem>

  <AccordionItem title="/product:define-scope — スコープ定義(sonnet)">
    出力は`CON-`IDの制約一覧(予算・締切・技術・法規制・組織)と`SCP-`IDのスコープ定義です。In-Scope/Out-of-Scopeの表(「やらないことリスト」は必須。スコープが際限なく広がるのを防ぎます)・MoSCoW分類・RICEスコア(NSMがあればImpactの根拠に使う)を作ります。
  </AccordionItem>

  <AccordionItem title="/product:validate-assumptions — 仮説の検証(opus・検証ゲート)">
    出力は`ASM-`IDの仮説一覧・検証計画・Go/No-Go判定です。Phase 1の直後に必ず通る検証ゲートです。

    1. **崩れたときの影響が大きい仮説を並べる**

        戦略が依存している仮説をDesirability(欲しがるか)/Viability(儲かるか)/Feasibility(作れるか)の3種類に分類し、「これが外れたら戦略のどれだけが崩れるか」で優先順位をつけます。

    2. **最も安く確かめる方法を選ぶ**

        上位の仮説それぞれに、最も安価な検証方法(顧客インタビュー、スモークテスト/フェイクドア〈本物のように見せた入口だけ用意して反応を測る手法〉のランディングページ、コンシェルジュMVP〈裏側を人手で回して価値だけ検証する手法〉、Wizard of Oz〈裏側が自動化されているように見せかける手法〉、**先行販売**〈Viabilityを検証する最も強力な方法〉)と、やめる/方向転換する基準(kill/pivot threshold)を割り当てます。

    3. **Go/No-Go判定を出す**

        未検証・高リスクな仮説が残っていればNo-Goとし、`work/pipeline-progress.json`に判定を記録します。証拠が集まるたびに再実行できます。
  </AccordionItem>

  <AccordionItem title="/product:name-product — プロダクト命名(opus、Phase 1のオプション)">
    出力は`NAM-`IDのプロダクト名候補集です。Vision・Values・差別化要因・ドメインの語彙から頭文字ごとの英単語バンクを作り、各候補に「短く発音しやすい文字列」と「1文字1単語のフル展開」をセットで示します。命名基準(識別性・短さ・発音しやすさ・適切さ・展開可能性・保護しやすさ)で採点し、3件の絞り込みと1件の推薦を`VIS-`IDに紐づけた理由とともに出します。商標などの利用可否確認はOpen Questionsとして残し、確認済みとは主張しません。
  </AccordionItem>
</Accordion>

### Phase 2 — ユーザーと画面の骨格を作る

<Accordion>
  <AccordionItem title="/product:generate-persona — ペルソナ生成(opus)">
    出力は`JOB-`IDのジョブストーリー(「[状況]のとき、[目的]したい。それによって[結果]を得たい」という形式。機能的/感情的/社会的の3側面をカバー)と、`PER-`IDのペルソナカード(アーキタイプ・状況と行動・JTBD・Pains・Gains・生の声の引用)です。実データに基づかない場合は`[proto]`と明記します。デモグラフィック情報や引用を創作することはありません。
  </AccordionItem>

  <AccordionItem title="/product:map-journey — カスタマージャーニーマッピング(sonnet)">
    出力は`JNY-`IDのジャーニーマップです。主要ペルソナごとに、ステージ(認知→検討→購入→オンボーディング→利用→更新→推奨)×レイヤー(タッチポイント・行動・感情の生の声と曲線・痛み・機会)の格子を作り、Moment of Truth(ZMOT/FMOT/SMOT。評価が決まる決定的瞬間)を感情曲線が落ち込む箇所に立てます。実質的な出力は優先順位付きの機会リストです。
  </AccordionItem>

  <AccordionItem title="/product:design-positioning — ポジショニング設計(opus)">
    出力は`POS-`/`HOOK-`IDのポジショニング文書です。

    1. **Dunford 5要素のキャンバスを作る**

        競合となる代替手段・独自の強み・価値(と根拠)・対象セグメント・市場カテゴリの5つを整理します。

    2. **差別化とパリティを分ける**

        市場調査で分類したPoD(差別化点)とPoP(パリティ点)のどちらに何を割り当てるかを決めます。

    3. **タッチポイント×デバイス×タイミングの表を作る**

        ジャーニーの各タッチポイントで、どのデバイスに・いつメッセージを届けるかを整理します。

    4. **Hookキャンバスを作る**

        Trigger(きっかけ)→Action(行動)→Variable Reward(変動する報酬)→Investment(蓄積)という、習慣的な利用を生む仕組みを設計します。

    5. **Kano魅力機能の更新計画を立てる**

        Delighter(魅力機能)は時間が経つと「当たり前」に感じられてしまうため、継続的に更新する計画を立てます。
  </AccordionItem>

  <AccordionItem title="/product:create-domain-story — ドメインストーリー作成(opus)">
    出力はペルソナ×主要ジョブごとの`STORY-`IDドメインストーリーです。特定のペルソナ(`PER-`)がジョブ(`JOB-`)を達成する手順を、ジャーニー(`JNY-`)の順に沿って1本のハッピーパスとして書きます。各ステップは後段の`generate-ui-mock`で画面に変換されます(1アクティビティ=1画面操作)。

    Domain Storytelling(業務の流れを図にする手法)の3要素——**Actors**(登場人物。ペルソナ本人と関わる人・システム)・**Work Items**(取り扱う対象。ジャーニーやジョブの語彙から命名)・**Activities**(番号付きの行動)——で構成します。architect側にも同名のスキルがありますが、そちらはレガシー経路の既存アクター定義を起点にする点が異なります。

    `--mode=event-storming`を指定すると、Process Modeling(ステップごとにイベント・コマンド・実行者・リードモデル・ポリシーを書く)という別の進め方に切り替わりますが、書き出す`STORY-`IDやレジストリは変わりません。
  </AccordionItem>

  <AccordionItem title="/product:design-system — デザインシステム構築(opus、Phase 2のスタンドアロン)">
    出力は`design-system/{name}/`配下に個別管理されるデザインシステムです。パイプラインの1回の実行とは別に、再利用・バージョン管理・入れ替えができるように独立して置かれます。

    - **トークン**: `tokens.json`(DTCG形式)+`tokens.css`。色・文字・間隔・角丸・elevation・モーションの生の値と、意味づけされた別名(`color.bg/fg/primary/danger`など)。
    - **コンポーネント一覧**(`CMP-`ID)・**ガイドライン**(アクセシビリティ基準を含む)・**マニフェスト**・**プレビューHTML**。

    ポジショニングやペルソナから新規に組み立てる(build)か、既存のTailwind/DTCG/Figma Tokens/CSSテーマを取り込む(`--import`)かを選べます。ここで作った「見た目の言語」を`generate-ui-mock`が使います。
  </AccordionItem>
</Accordion>

### Phase 3 — 画面と機能を仕様にする

<Accordion>
  <AccordionItem title="/product:generate-ui-mock — UIモック生成(sonnet)">
    出力は`reports/02_spec/ui-mocks/`配下の、クリックで画面遷移できるナビゲート可能なHTMLモック(1画面=1ファイル、インラインCSS)です。

    - 各画面は、対応するドメインストーリーの各アクティビティから導出されます(1アクティビティ=1画面操作)。優先度の高いジョブについては、2〜3案を簡単に比較して1つを選んだ根拠も記録します。
    - 画面遷移は実際の`<a href>`で結線されているため、ストーリーの最初から最後までクリックで通しで確認できます。存在しないステップは無効化された`TBD`リンクになり、リンク切れにはなりません。
    - デザインシステムの`tokens.css`が各画面に注入され、すべてのモックが同じ見た目の言語を共有します(midフィデリティならコンポーネントのスタイルも適用)。
  </AccordionItem>

  <AccordionItem title="/product:define-features — 機能定義(sonnet)">
    出力は`FEAT-`IDの機能一覧です。UIモックの各画面操作をCommand(実行できる機能の単位)に変換し、スコープと突き合わせて(Out-of-Scopeの項目は最初から除外)、`JOB-`/`JNY-`/`NSM-`への根拠づけとMoSCoW優先度を付けます。UIモックが空の場合は実行を止めます。

    同じ`feature-list.md`にUser Story Map(ジャーニーのステージを背骨に、`FEAT-`をストーリーとして並べ、MoSCoWの帯をリリース区切りにした図)も書きます。新しい判断を加えるものではなく、既存の機能一覧を別の切り口で見せるビューです。
  </AccordionItem>

  <AccordionItem title="/product:example-map — Example Mapping(opus)">
    出力は機能(`FEAT-`)ごとの`RULE-`(業務ルール)・`EX-`(ルールの両側の具体例)・セッションで決着しなかった`OQ-`(Open Questions)です。4色カード(ルール/例/疑問/機能)によるExample Mappingセッションの進め方と、実例をどこから拾うか(既存の受入基準・ドメインストーリー・ペルソナの発言など)を`rules/product/example-mapping.md`が定めます。

    この`RULE-`/`EX-`は、`generate-test-specs`では`Rule:`/`Scenario:`ブロックに、`export-backlog`では受入基準に、`design-aggregate`では不変条件の候補に、`define-requirements`ではFRの受入基準に、それぞれ変換されます。
  </AccordionItem>

  <AccordionItem title="/product:define-data-model — データモデル定義(opus)">
    出力は`ENT-`IDのデータモデルとMermaid ER図です。

    1. **Pass 1: 明示的なエンティティを読み取る**

        画面・フォーム・操作から、はっきり書かれているエンティティを抽出します。

    2. **Pass 2: 暗黙のエンティティを洗い出す**

        機能×エンティティのCRUDマトリクスを作り、そこから読み取れる暗黙のエンティティ(結合・履歴・監査ログ・状態遷移など)を、根拠つきで追加します。
  </AccordionItem>

  <AccordionItem title="/product:generate-frontend — フロントエンド生成(sonnet、Phase 3のオプション)">
    出力は`generated/frontend/`配下の、`npm install && npm run storybook`だけで動くReact + TypeScriptのフロントエンド一式です。UIモックが「各画面が何をするか」、デザインシステムが「見た目の言語」を決め、このスキルが両方を実際のコンポーネントに変換します。

    - デザインシステムの各コンポーネント(`CMP-`)を、Atomic Designの適切な階層(atoms/molecules/organisms/templates)に配置します。コンポーネントごとに`.tsx`(型付きprops)・`.module.css`(トークンだけを参照。生の値は書きません)・`.stories.tsx`を生成します。
    - 各UIモック画面が1つのPageコンポーネントになり、ストーリーの遷移(次へ/戻る)はreact-routerで実際のルーティングとして結線されます。
  </AccordionItem>
</Accordion>

### Phase 4-5・統合 — ドメインとアーキテクチャに落とし込む

<Accordion>
  <AccordionItem title="/product:map-domains — ドメインマッピング(opus)">
    出力はドメインマップ(サブドメインをCore/Supporting/Genericに分類し、投資方針〈Coreは自作・Supportingは実用的に・Genericは購入〉を示す)・`CTX-`IDの境界コンテキスト(コンテキストマップ〈ACL・Open Host/Published Language・Shared Kernel・Customer/Supplier・Conformist・Partnershipという関係パターン〉と、粗い一貫性のヒント〈Strong/Eventual/TBD〉)・ユビキタス言語です。

    一貫性のヒントはあくまで「ヒント」で、architect側の`define-requirements`が業務プロセスごとの最終的なACID/Saga/ローカルトランザクションの判定を行います。architectにも同名のmap-domainsがありますが、そちらは`analyze`の分析結果からドメインを分類するもので、入力が異なります。

    各境界コンテキストは9項目のBounded Context Canvasとして記述され、architect側で再設計された同じCanvasと項目ごとに比較できます。`--mode=event-storming`を指定すると、Big Picture EventStorming(イベントの時系列を並べ、転換点となるイベントを境界の候補にする)という別の進め方で境界を見つけられます。
  </AccordionItem>

  <AccordionItem title="/product:design-api — 論理API設計(opus)">
    出力は`API-`IDのAPI設計文書です。System(CRUD)・Process(業務フローの調整)・Experience(チャネルごと)という3階層でAPIを分類し、Experience→Process→Systemの一方向の依存関係グラフと、各APIのOpenAPIスケッチ(主要なパス・メソッド・リクエスト/レスポンスの形)を作ります。再利用の最大化が狙いで、architect側の`design-api`が後でこれを具体的なプロトコル・仕様に落とし込みます。
  </AccordionItem>

  <AccordionItem title="/product:design-sla — SLA設計(sonnet)">
    出力は`SLA-`/`SLO-`IDのサービスごとのSLI/SLO/SLA、エラーバジェット(1−SLO)とその運用方針、重要度階層(critical/standard/best-effort)です。目標は顧客の期待に合わせ、SLOはSLAより厳しく設定します。
  </AccordionItem>

  <AccordionItem title="/product:define-nfr — NFR定義(sonnet)">
    出力は`NFR-`IDの非機能要件(可用性・レイテンシ〈p95/p99〉・スループット・エラー率・耐久性・RPO/RTO、必要に応じてスケーラビリティ/セキュリティ/可観測性も)です。各NFRには数値(またはTBD)と、導出元のSLOを明記します。
  </AccordionItem>

  <AccordionItem title="/product:design-architecture — アーキテクチャ統合設計(opus)">
    出力は`ARCH-`IDのアーキテクチャ文書(ランタイム/コンテナ図・クリティカルパスのシーケンス図・デプロイ/スケーリング図)と、`TECH-`IDの技術適合性評価です。

    Kong(APIゲートウェイ)・ScalarDB・ScalarDB Analytics・ScalarDB Saga・ScalarDLの5つについて、適合度(High/Medium/Low/None)・判断の根拠(引用元のID)・**Adopt/Conditional/Reject**の決定・採用条件とリスクをそれぞれ評価します。ScalarDB Sagaは「コンテキストをまたぐ処理が結果整合でよい場合」または「外部システムを呼ぶステップがある場合」に検討対象になり、ScalarDB自体を採用したからといって自動的に採用されるわけではありません。
  </AccordionItem>
</Accordion>

### 運用・ユーティリティ系

<Accordion>
  <AccordionItem title="/product:review — 4視点レビュー(opus)">
    出力は`reports/report/review.md`です。一貫性(IDの参照切れ・矛盾・用語のブレ)・トレーサビリティ(`work/traceability.json`と文書の対応、孤立参照)・拡張性(将来の機能に対するドメイン境界とAPI再利用性)・戦略(Visionとスコープの整合、ユニットエコノミクスの健全性、差別化の持続性)の4つの視点から、重大度(blocker/major/minor)・場所・具体的な直し方を伴うfindingsを出します。パイプラインの途中でも何度でも再実行できます。
  </AccordionItem>

  <AccordionItem title="/product:report — 統合レポート生成(sonnet)">
    出力は`reports/report/full-report.html`という自己完結型のHTMLレポート(Mermaid図もインライン)です。**「重要な仮説と検証状況」を必ず先頭に置きます**——ゲートの判定・未検証の仮説・すべてのTBD・Open Questionsをステータス別に並べ、「誰にも聞かれていない疑問」と「意図的に保留した疑問」を見分けられるようにします。その後にフェーズ順で各セクションが続きます。
  </AccordionItem>

  <AccordionItem title="/product:adapt-change — 変更の再伝播(opus)">
    出力は変更ログ・影響分析・更新済みの成果物です。`work/traceability.json`から影響範囲を計算し(下流への到達範囲の機械的な洗い出し → opusによる判断 → 人間への確認)、影響を受けたスキルだけを再実行します。architect側が持つIDへの影響は「報告するだけ」で、ここでは再実行しません。

    1. **変更を記録する**

        変更内容・種類(制約/市場/競合/技術/規制)・タイムスタンプと、再実行した成果物ごとのbefore/after差分を記録します(元に戻せるように)。

    2. **影響範囲を分析する**

        「変更→影響を受けたID→再評価するか+理由」を一覧にします。

    3. **最小限だけ再実行する**

        影響を受けたスキルだけを、既存の成果物を入力として再実行し、`work/traceability.json`の該当する繋がりを更新します。
  </AccordionItem>

  <AccordionItem title="/product:init-output — 出力の初期化(sonnet)">
    `product`パイプラインを動かすために必要なディレクトリ構造と状態ファイル(`work/pipeline-progress.json`、トレーサビリティグラフなど)を作ります。既存の状態を`--reset`なしに勝手に破棄することはありません。
  </AccordionItem>

  <AccordionItem title="/product:start — パイプラインの起動(sonnet)">
    このスキルが依存関係の順にフェーズを実行してくれるので、個別のスキルを1つずつ呼ぶ必要はありません。

    1. **プロファイルを選ぶ**

        `mvp`(Vision+Scope+検証だけの最小構成)・`core-only`・`ux-to-spec`・`full`のどれかを選びます(`--profile`で指定可能)。

    2. **init-outputを実行し、依存順に進める**

        フェーズごとに`work/pipeline-progress.json`を更新しながら、依存関係の順にスキルを実行します。

    3. **Phase 1の直後にゲートを通す**

        `validate-assumptions`の判定がno-goなら、その場で先に進まずPhase 1をやり直します。goになるまでは次のフェーズに進みません。

    4. **fullプロファイルではデザインシステムのステップも挟む**

        `design-positioning`の後、`create-domain-story`→`design-system`を実行してから`generate-ui-mock`に進みます。

    5. **フロントエンド生成は選択式**

        `generate-frontend`を実行するかどうかは、`--frontend`/`--no-frontend`で明示するか、対話で確認します(`--auto`時はプロファイルに従う)。
  </AccordionItem>
</Accordion>

<Panel title="全フェーズに共通する設計の特徴">
この設計でいちばん一貫しているのは、**すべてのフェーズが自分のID(識別番号)を発行し、
`work/traceability.json`というファイルに追記していく**ことです。例えば `VIS-001`(Vision)→
`NSM-001`(North Star)→`SCP-001`(Scope項目)→`FEAT-001`(機能)→`ENT-001`(エンティティ)→
`CTX-001`(境界コンテキスト)→`API-001`(API)という順につながり、上流の工程から下流の工程まで
機械的に追跡(トレーサビリティ)できるようになっています。
</Panel>

```mermaid
flowchart LR
  VIS["VIS-001<br/>Vision"] --> NSM["NSM-001<br/>North Star"]
  NSM --> SCP["SCP-001<br/>Scope項目"]
  SCP --> FEAT["FEAT-001<br/>機能"]
  FEAT --> ENT["ENT-001<br/>エンティティ"]
  ENT --> CTX["CTX-001<br/>境界コンテキスト"]
  CTX --> API["API-001<br/>API"]
```

実行プロファイル(どのスキルをどう組み合わせて実行するかの設定)の詳細は、
[パイプライン依存関係グラフ](/concepts/dependency-graph)を参照してください。