product-implement

product-implement

このスキルの機能

承認済み PDR を、3 フェーズの DAG を使用して、包括的で自己完結型の PRD.md に変換します。

1. Plan Agent：PDR を分析し、機能領域を検出し、カスタマイズした DAG を生成して、ユーザーの承認を得ます
2. Execute Agent：機能領域ごとにセクションを生成します。Requirements の後に必須チェックポイントがあります
3. Summarize Agent：セクションを集約し、競合を解決して、統合された PRD.md を生成します

出力：

• docs/adlc/product/PRD.md — 自己完結型の製品要件（共通レイアウト。リポジトリルートにある従来の PRD.md も引き続き読み取り可能です）
• {REPO_ROOT}/.adlc/product/sections/{feature-area}/{section}.md — 中間セクションファイル
• 承認済み PDR は {REPO_ROOT}/docs/adlc/memory/pdr/ に移動されます（共通レイアウトの正式なメモリルート）

使用するタイミング

• /product-clarify で PDR が承認された後
• 既存の製品を文書化するための /product-init の後
• PRD の再生成が必要な PDR の更新時

使用しないタイミング

• 承認済み PDR がない場合（先に /product-clarify を実行してください）
• 軽微な PRD の編集時（PRD.md を直接編集してください）

事前検証

開始する前に、前提条件を確認してください。

1. PDR の存在を確認：{REPO_ROOT}/.adlc/drafts/pdr/PDR-*.md
2. 承認済み PDR を確認：ステータスが「Accepted」のファイル数を数えます
   • 0 件の場合：停止して、次の内容を出力します。

     Cannot proceed: No Accepted PDRs found.
     Run /product-clarify to review and approve PDRs first.
     

   • 1 件以上の場合：続行します

3 フェーズの DAG ワークフロー

┌─────────────────────────────────────────────────────────┐
│ PHASE 1: PLAN (Plan Agent)                              │
│ Load PDRs → Detect Feature-Areas → Generate DAG → Approve│
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 2: EXECUTE (Execute Agent)                        │
│ Overview → Problem → Goals → Metrics → Personas         │
│ → [REQUIREMENTS CHECKPOINT] ← MANDATORY USER APPROVAL   │
│ → NFRs → Out-of-Scope → Risks → Roadmap → PDR-Summary   │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│ PHASE 3: SUMMARIZE (Summarize Agent)                    │
│ Read sections → Detect conflicts → Resolve → PRD.md     │
└─────────────────────────────────────────────────────────┘

実行手順

フェーズ 1：計画

ステップ 1.1：PDR を読み込み、分析する

1. .adlc/drafts/pdr/ からすべての PDR-*.md ファイルを読み込みます
2. ステータスがAcceptedのものに絞り込みます
3. 各 PDR から機能領域を解析します
4. 機能領域ごとに PDR をグループ化します

ステップ 1.2：機能領域の特性を検出する

特性	検出パターン	DAG のカスタマイズ
B2B SaaS	エンタープライズ、管理者、SSO	コンプライアンスのセクションを含める
コンシューマーアプリ	モバイル、フリーミアム、ソーシャル	要件を簡素化する
プラットフォーム	API、インテグレーション、開発者	NFR を拡張する
マーケットプレイス	マルチサイド、トランザクション	ビジネスモデルのセクションを追加する

ステップ 1.3：カスタマイズした DAG を生成する

デフォルトの DAG（全 15 セクション）：

Document Information → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [CHECKPOINT: Requirements]
→ NFRs → Out-of-Scope → Risks → Investment
→ Roadmap → Go-to-Market → PDR-Summary

セクション番号（固定）：

• 1. ドキュメント情報
• 1.5 エグゼクティブサマリー
• 2. 概要
• 3. 問題
• 3.5 市場機会
• 4. 目標と目的
• 5. 成功指標
• 6. ペルソナ
• 7. 機能要件
• 8. 非機能要件
• 9. 対象外
• 10. リスクと軽減策
• 10.5 投資とリソース
• 11. ロードマップとマイルストーン
• 11.5 市場投入戦略
• 12. PDR の概要

ステップ 1.4：計画を提示し、承認を得る

## DAG Execution Plan

**Feature-Areas detected**: 3
**Total sections**: 15

**Feature-Area: Core**
**PDRs**: PDR-001, PDR-005, PDR-008
**DAG**: Document Info → Executive Summary → Overview → Problem
→ Market Opportunity → Goals → Metrics → Personas
→ [Requirements Checkpoint] → NFRs → Out-of-Scope → Risks
→ Investment → Roadmap → GTM → PDR-Summary

**Approve this plan?** [Yes/Modify/Cancel]

ステップ 1.5：state.json を書き込む

{
  "version": "1.0",
  "phase": "plan_approved",
  "feature_areas": [
    {
      "id": "core",
      "name": "Core",
      "pdrs": ["PDR-001", "PDR-005"],
      "dag": ["document-info", "executive-summary", "overview", "problem", ...],
      "progress": {}
    }
  ],
  "checkpoint": {
    "enabled": true,
    "after_section": "requirements",
    "status": "pending"
  }
}

フェーズ 2：実行

DAG 内の各セクションについて、次の手順を実行します。

1. 依存関係を確認 — 前提条件がすべて完了していることを確認します
2. セクションテンプレートを読み込む — ../templates/sections/{section}.md
3. コンテンツを生成 — PDR から導出した内容をテンプレートに記入します
4. セクションファイルを書き込む — .adlc/product/sections/{feature-area}/{section}.md
5. 検証 — scripts/bash/validate-prd.sh {section}.md を実行します
6. state.json を更新 — セクションを「completed」としてマークします

セクションテンプレートの使用（必須）：

• 最初にテンプレートを読み込みます
• すべての [PLACEHOLDERS] を埋めます
• 一から生成してはいけません

セクション内の図（必須）：

• ```mermaid コードブロックを使用します
• flowchart キーワードを使用します（非推奨の graph は使用しません）
• ASCII の罫線文字は禁止です
• 図はそれぞれ対応するセクション内に埋め込みます

セクション	図の種類	サブセクション
2. 概要	機能階層（flowchart TD）	2.4
2. 概要	アーキテクチャ（flowchart TB）	2.5
6. ペルソナ	ユーザージャーニー（journey）	6.4
7. 要件	要件の依存関係（flowchart LR）	7.4
7. 要件	機能の依存関係（flowchart LR）	7.5
11. ロードマップ	ガントチャート（gantt）	11.1

要件のチェックポイント（必須）：

要件セクションの生成後：

## CHECKPOINT: Requirements Section Complete

The Requirements section has been generated.

**Why checkpoint here?** Requirements shapes:
- NFRs (how requirements are met)
- Out-of-Scope (what's NOT required)
- Risks (technical feasibility)
- Roadmap (priority and sequencing)

**Options**:
A) Approve — Continue to remaining sections
B) Modify — Edit requirements, then continue
C) Restart — Regenerate from Problem phase
D) Cancel — Stop execution

フェーズ 3：要約

ステップ 3.1：すべてのセクションをディスクから読み込む

重要：各セクションファイルをファイルシステムから読み込んでください。メモリ上の内容を使用してはいけません。

1. .adlc/product/sections/ をスキャンして、すべての .md ファイルを探します
2. 各ファイルを読み込みます
3. 検証します：20 行以上で、適切な見出しがあること

ステップ 3.2：機能領域をまたぐ競合を検出する

競合の種類	検出方法	解決方法
要件の重複	同じ要件が異なる表現で記載されている	PDR の用語に統一します
優先度の不一致	同じ機能の優先度が異なる	PDR に従います
指標の不整合	同じ指標の定義が異なる	PDR の定義を使用します

ステップ 3.3：PRD.md に集約する

重要：PRD.md は必ず自己完結型にしてください。

• すべての図をセクション内に埋め込みます
• 読者向けの .adlc/ パスへのリンクは一切含めません
• ドキュメント内のアンカーのみを使用します：[Section 2.4](#24-feature-hierarchy)
• PDR への参照はプレーンテキストにします：plain-text PDR references（リンクにしません）

PRD の構成（テンプレートと一致させる必要があります）：

# Product Requirements Document: [Product Name]

## 1. Document Information
[Quick Stats, revision history, approval]

## 1.5 Executive Summary
[Business case, ROI, recommendation]

## 2. Overview
[Product description, scope]
### 2.4 Feature Hierarchy [MERMAID flowchart TD]
### 2.5 Architecture Overview [MERMAID flowchart TB]

## 3. The Problem
[Problem statement, validation evidence]

## 3.5 Market Opportunity
[TAM/SAM/SOM, competitive landscape]

## 4. Goals & Objectives
[Primary, technical, business goals traced to PDRs]

## 5. Success Metrics
[Adoption, engagement, quality]
### 5.5 Business Outcome Metrics
### 5.6 Financial Metrics

## 6. Personas
[Primary, secondary, anti-personas]
### 6.4 User Journey [MERMAID journey]

## 7. Functional Requirements [CHECKPOINT]
[User stories, REQ-XXX IDs, priority matrix]
### 7.4 Requirement Dependencies [MERMAID flowchart LR]
### 7.5 Feature Dependencies [MERMAID flowchart LR]

## 8. Non-Functional Requirements
[Performance, security, reliability, scalability]

## 9. Out of Scope
[Feature, technical, market exclusions]

## 10. Risks & Mitigation
[Risk summary, technical, market, operational]
### 10.4 Business Risks

## 10.5 Investment & Resources
[Team, budget, ROI, go/no-go criteria]

## 11. Roadmap & Milestones
### 11.1 Roadmap Overview [MERMAID gantt]
[Milestone details with demo sentences]

### 11.2 Milestone Gates & Progress
[Per milestone: done-means definition, feature rollup, gate table, issue/evidence status — sourced from milestone PDRs]

## 11.5 Go-to-Market Strategy
[Launch phases, pricing, messaging]

## 12. PDR Summary
[Key decisions, constitution alignment — NO external links]

フェーズ 4：PDR ライフサイクル管理（必須）

必要条件： product-clarify スキル（pdr-lib.sh を提供）：adlc-cli skills add tikalk/adlc-team-skills --skill product-clarify

ステップ 4.1：承認済み PDR をメモリに移動する（アトミック — スクリプトで実行）

PDR ライフサイクルライブラリを読み込み、承認済みの各 PDR に対して move_pdr を呼び出します。これによりアトミックな mv が実行され（コピー後に削除する際の重複リスクはありません）、両方のスコープのインデックスが自動的に再生成されます。

source "{REPO_ROOT}/.agents/skills/product-clarify/scripts/bash/pdr-lib.sh"
# Or on Windows: . "{REPO_ROOT}/.agents/skills/product-clarify/scripts/powershell/pdr-lib.ps1"

for pdr_id in <list of Accepted PDR IDs>; do
  move_pdr "$pdr_id" drafts memory
done

• ステータスが「Accepted」の PDR は、.adlc/drafts/pdr/ から docs/adlc/memory/pdr/ にコピーではなく移動します。
• ステータスを「Completed」に変更してはいけません — インデックスのヘッダー（「Accepted PDRs only」）が正確であり続けるよう、「Accepted」のままにします。
• 提案済み／発見済みの PDR はドラフトに残し、移動しません。
• move_pdr により、drafts/pdr/pdr.md と memory/pdr/pdr.md の両方のインデックスが再生成されます。

ステップ 4.2：メモリ PDR インデックスを生成する（必須 — スクリプトで実行）

ステップ 4.1 の move_pdr 呼び出しによって、メモリインデックスはすでに再生成されています。手動で再生成する場合（例：PDR ファイルを一括編集した後）：

source "{REPO_ROOT}/.agents/skills/product-clarify/scripts/bash/pdr-lib.sh"
generate_pdr_index memory

これは、フロントマター優先＋見出しフォールバックのパーサーを使用して {REPO_ROOT}/docs/adlc/memory/pdr/pdr.md を書き込みます。このパーサーは、##（H2 の旧形式）と ###（H3 の現行形式）の両方のメタデータに対応します。セルが空の場合は stderr に警告が出力され、既定値が適用されます。空の行が黙って生成されることはありません。

生成されるインデックスの形式は次のとおりです。

# Product Decision Records (Memory)

> Auto-generated by /product-implement. Accepted PDRs only.
> Source: docs/adlc/memory/pdr/PDR-*.md

## PDR Index

| ID | Feature-Area | Category | Status | Date | Owner | Title |
|----|--------------|----------|--------|------|-------|-------|
| PDR-001 | control-plane | Governance | Accepted | 2026-08-04 | User/AI collaboration | Lit Factory Operating Model |

このインデックスは、セッション開始時の注入に team-boot によって使用されます（チームレベルのコンテキストに CDR.md が使用される方法と同様です）。

ステップ 4.3：state.json を更新する

{
  "phase": "completed",
  "pdr_lifecycle": {
    "pdrs_promoted": [N],
    "memory_pdr_moved": true,
    "drafts_retained": true,
    "drafts_reason": "Proposed/Discovered PDRs remain",
    "memory_index_generated": true
  }
}

フェーズ 5：最終確認

完了とする前に、すべてのチェック項目を確認してください。

#	チェック項目	期待される結果
1	ディスク上のセクションファイル	.adlc/product/sections/ に N 個のファイルがある
2	PRD.md が存在する	はい
3	PRD.md のコンテンツサイズ	200 行超
4	PRD.md にすべてのセクションがある	セクション 1～12 ＋サブセクション
5	PRD.md が自己完結している	.adlc/ リンクが 0 個
6	図が埋め込まれている	mermaid ブロックが 4 個以上
7	メモリ PDR が書き込まれている	docs/adlc/memory/pdr/PDR-*.md が存在する
8	メモリ PDR インデックスが生成されている	docs/adlc/memory/pdr/pdr.md が正しい表とともに存在する
9	state.json に矛盾がない	すべてのセクションが "completed"

ゲートルール：チェック項目に 1 つでも失敗した場合は、完了としてはなりません。失敗を報告してください。

PDR のトレーサビリティルール

• すべてのセクションで、ID を指定してソース PDR を参照する必要があります
• すべての要件（REQ-XXX）を PDR にトレースできる必要があります
• PDR に裏付けられていないコンテンツを含めてはなりません
• 競合の解決では、PDR を信頼できる唯一の情報源とします

設定

• PDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/pdr
• PDR_MEMORY_DIR — {REPO_ROOT}/docs/adlc/memory/pdr
• PRD_FILE — {REPO_ROOT}/docs/adlc/product/PRD.md
• SECTIONS_DIR — {REPO_ROOT}/.adlc/product/sections
• STATE_FILE — {REPO_ROOT}/.adlc/product/state.json

12-Factor との整合性

• Factor III（ミッションの定義）：ミッションに関する決定を実行可能な要件にまとめます
• Factor IV（構造化された計画）：DAG オーケストレーションにより、計画と実行を分離します
• Factor IX（トレーサビリティ）：すべての PRD 要素を PDR にさかのぼって追跡できます

よくある自己正当化

自己正当化	実態
「チェックポイントを省略して、すべてを生成すればよい。」	要件は NFR、対象範囲外、リスク、ロードマップの形を決定します。チェックポイントを省略すると、連鎖的なエラーが発生するおそれがあります。
「PRD からセクションファイルを参照すればよい。」	PRD.md は自己完結していなければなりません。外部参照は、セクションファイルの移動や削除によって機能しなくなります。
「PDR をメモリに移動する必要はない。」	昇格しないと、ドラフトとメモリの内容にずれが生じます。次の明確化セッションでは古いデータが参照されます。

危険信号

• Accepted ではない PDR から PRD を生成している — implement は Proposed／Discovered をスキップするため、PRD が不完全になります。
• PDR から PRD.md に直接書き込んでいる — 検証に合格したことを保証するため、コンテンツはセクションファイルから取得しなければなりません。
• Requirements チェックポイントを省略している — これは中核となるセクションであり、ここでのエラーは連鎖します。
• PRD.md に .adlc/ リンクを残している — 自己完結性が損なわれ、読者が内部パスをたどれなくなります。

検証

• 事前確認：Accepted の PDR が 1 件以上存在する
• ユーザーが計画を承認している
• DAG を含む state.json が書き込まれている
• 各セクションファイルが 20 行以上である
• 各セクションで validate-prd.sh が成功する
• ユーザーが Requirements チェックポイントを承認している
• PRD.md が 200 行を超え、15 セクションすべてを含んでいる
• PRD.md に .adlc/ リンクが 1 つもない
• 4 個以上の Mermaid 図がセクション内に埋め込まれている
• すべての要件を PDR にトレースできる
• Accepted の PDR が docs/adlc/memory/pdr/ に移動されている
• 最終完了確認：8 個すべてのチェックに合格している