product-init

product-init

このスキルの機能

既存のプロダクトを対象に、3 フェーズの分析パイプラインを用いてプロダクトの意思決定をリバースエンジニアリングします。

1. Discovery Agent：各機能領域をスキャンし、生のプロダクトシグナル（コード、ドキュメント、価格設定）を収集します
2. Pattern Agent：シグナルを PDR カテゴリに分類し、戦略的重要度をスコアリングします
3. Synthesis Agent：機能領域を横断して分析し、不整合を検出します

出力：.adlc/drafts/pdr/ にステータスが Discovered の個別の PDR-{NNN}.md ファイルを作成し、自動生成された pdr.md インデックスも作成します。

使用する場合

• 正式な PDR がない既存プロダクト
• プロダクトドキュメントが必要なブラウンフィールドのコードベース
• チームのオンボーディング — プロダクトの背景にある理由を確認する場合
• 買収後、または引き継いだコードベース

使用しない場合

• 新規プロダクト（代わりに /product-specify を使用）
• 軽微な PDR の更新（代わりに /product-clarify を使用）

実行手順

フェーズ 0：環境のセットアップ

セットアップスクリプトを実行してパスを解決し、機能領域を検出します。

sh: scripts/bash/setup-product-init.sh [--json]
ps: scripts/powershell/setup-product-init.ps1

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

セットアップの出力（JSON）：

{
  "REPO_ROOT": "/path/to/project",
  "PDR_DRAFTS_DIR": "/path/to/project/.adlc/drafts/pdr",
  "PRD_FILE": "/path/to/project/PRD.md",
  "feature_areas": ["core", "business", "growth"],
  "next_pdr": "001"
}

ディレクトリを作成：

mkdir -p "{REPO_ROOT}/.adlc/drafts/pdr"
mkdir -p "{REPO_ROOT}/.adlc/product"

フェーズ 1：機能領域の検出

3 つの情報源から機能領域を検出します。

情報源	検出パターン
ディレクトリ構造	src/auth/、features/payments/、modules/
ドキュメント	README のセクション、既存の PRD、ROADMAP
価格プラン	Starter／Pro／Enterprise の機能マッピング

検出した領域を提示：

## Detected Feature-Areas

| # | Feature-Area | Sources | Evidence |
|---|--------------|---------|----------|
| 1 | **Core** | Directory + Docs | src/users/, README "Core Features" |
| 2 | **Business** | Directory + Pricing | src/billing/, pricing.md tiers |

Reply: Y to confirm, n for monolithic, or suggest changes.

しきい値の判定：

• ≤3 領域：自動承認
• 4-6 領域：ユーザーに確認

• 6 領域：グループ化を提案

フェーズ 2：Discovery Agent（機能領域ごと）

各機能領域について、順番に以下を実行します。

1. ディレクトリをスキャンし、収益化のシグナル、ユーザーフロー、機能を確認します
2. ドキュメントを分析します（README、PRD、価格設定）
3. 価格プランとの対応関係を特定します
4. 根拠を記録します

領域ごとの進捗レポート：

Discovery Agent: business feature-area
├── Directory signals: 4
├── Documentation signals: 2
├── Pricing signals: 1
└── Status: ✓ Completed

フェーズ 3：Pattern Agent（機能領域ごと）

各機能領域について、以下を実行します。

1. シグナルを PDR カテゴリ（問題、ペルソナ、スコープ、指標など）に分類します
2. 戦略的重要度をスコアリングします（0.0-1.0）
3. 既存の PDR と照合して重複を確認します
4. 領域横断の候補を特定します

フェーズ 4：Synthesis Agent（機能領域横断）

1. 領域横断パターンの検出：

{
  "pattern_id": "P001",
  "pattern_name": "Admin Persona",
  "feature_area_presence": {"core": true, "business": true},
  "is_cross_area": true
}

2. 不整合の検出：

• 優先度の競合
• 問題の重複
• 指標の不整合
• フラグを生成します（該当する PDR に埋め込みます）

3. PDR の生成：戦略性の高いパターン（>0.7）および領域横断パターン（2 領域以上）

フェーズ 5：個別の PDR ファイルを作成

検出された各 PDR について、以下を実行します。

1. ID を割り当てます：次に使用可能な番号を使った PDR-{NNN}
2. ファイルを作成します：{REPO_ROOT}/.adlc/drafts/pdr/PDR-{NNN}.md

PDR ファイルの形式（個別ファイル、YAML フロントマター — 共通テンプレートを使用）：

正規の PDR 形式として、{REPO_ROOT}/.agents/skills/product/../templates/pdr-template.md のテンプレートを使用します。このテンプレートには、インデックス生成における唯一の情報源となる YAML フロントマター（status、date、owner、category、feature-area、title）と、標準の PDR 本文セクションが含まれます。

---
status: discovered
date: YYYY-MM-DD
owner: [Inferred from codebase/authors]
category: [Problem | Persona | Scope | Metric | Prioritization | Business Model | Feature | NFR]
feature-area: [core | business | growth | ...]
title: [Decision Title]
---

# PDR-001: [Decision Title]

### Cross-Feature-Area Metadata
- **Appears in**: [business, growth]
- **Cross-area count**: 2
- **Is cross-area pattern**: ✓

### ⚠️ Inconsistency Flags
*None* (or flag details if detected)

### Context
**Problem/Opportunity:**
[Clear description]

**Market Forces:**
- [Market factor 1]
- [Customer feedback]

### Decision
**Decision Statement:**
[Clear statement]

**Rationale:**
[Why this option]

### Consequences
#### Positive
- [Benefit 1]

#### Negative
- [Trade-off 1]

#### Risks
- [Risk with mitigation]

### Success Metrics
| Metric | Target | Measurement Method |
|--------|--------|-------------------|
| [Metric] | [Target] | [Method] |

### Alternatives Considered
#### Option A: [Alternative Name]
**Description:** [Brief description]
**Trade-offs:** [Neutral comparison]

フェーズ 6：PDR インデックスの再生成

すべての PDR-*.md ファイルから {REPO_ROOT}/.adlc/drafts/pdr/pdr.md を生成します。

# For each PDR-*.md file, extract ID, title, status, date
# Build index table

インデックスの形式：

# Product Decision Records

## PDR Index

| ID | Feature-Area | Category | Status | Date | Owner |
|----|--------------|----------|--------|------|-------|
| PDR-001 | business | Business Model | Discovered | 2026-01-20 | [Inferred] |
| PDR-002 | core | Persona | Discovered | 2026-01-20 | [Inferred] |

---

## Cross-Feature-Area Analysis Summary

### Cross-Area Patterns
| Pattern | Feature-Areas | PDR |
|---------|---------------|-----|
| Admin Persona | core, business | PDR-002 |

### Inconsistencies Flagged
| Flag ID | Type | PDRs Affected | Severity |
|---------|------|---------------|----------|
| FLG-001 | Priority Conflict | PDR-003 | Medium |

---

*Individual PDR files are in this directory (PDR-*.md)*

フェーズ 7：出力の概要

## Product Init Complete ✓

### Execution Stats
- **Feature-areas analyzed**: 3
- **Discovery Agent runs**: 3
- **Pattern Agent runs**: 3
- **Synthesis Agent runs**: 1

### PDRs Generated
| Category | Count | Cross-Area |
|----------|-------|------------|
| Business Model | 2 | ✓ |
| Persona | 3 | ✓ |
| Problem | 2 | |
| Prioritization | 1 | |
| **With Inconsistency Flags** | **2** | |

### Next Steps
1. Review PDRs: `{REPO_ROOT}/.adlc/drafts/pdr/`
2. **Resolve inconsistencies**: Run `/product-clarify`
3. Generate PRD: Run `/product-implement`

PDR の採番ルール

• {REPO_ROOT}/.adlc/drafts/pdr/ 内の既存の PDR-*.md ファイルをスキャンします
• 数値の接尾辞を抽出し、最大値を見つけます
• 次の PDR = 最大値 + 1。3 桁になるようゼロ埋めします（PDR-001、PDR-002、...）
• 削除済みの PDR であっても、番号を再利用しません

状態管理

状態ファイル：{REPO_ROOT}/.adlc/product/state.json

{
  "version": "1.0",
  "command": "product-init",
  "created_at": "2026-01-20T10:00:00Z",
  "phase": "completed",
  "feature_areas": [
    {"id": "core", "name": "Core", "progress": {"discovery": "completed", "pattern": "completed"}}
  ],
  "pdrs_generated": 9,
  "cross_area_patterns": 5,
  "inconsistencies": 2
}

設定

• PDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/pdr（個別の PDR ファイル）
• PDR_INDEX — {REPO_ROOT}/.adlc/drafts/pdr/pdr.md（自動生成されるインデックス）
• PRD_FILE — {REPO_ROOT}/docs/adlc/product/PRD.md
• STATE_FILE — {REPO_ROOT}/.adlc/product/state.json

12-Factor との整合性

• Factor III（ミッション定義）：既存のコードの背後にある「何を、なぜ」を明らかにします。
• Factor IX（トレーサビリティ）：推測した判断にはすべて、根拠を記録します。

よくある正当化

正当化	実態
「コードを読めばすべてわかります。」	コードに示されるのは 方法 であり、理由 ではありません。コードでは伝えられない根拠を PDR に記録します。
「README を読むだけで十分です。」	README に記載されるのは機能であり、判断ではありません。PDR に判断の経緯を記録します。
「既存のコードベースを持つ製品には PDR は不要です。」	どの製品にも暗黙の判断があります。それを明示すれば、同じ間違いを繰り返さずに済みます。

危険信号

• コードベースの根拠なしに PDR を生成する — 既存のコードベースをもとに作成する PDR は、捏造した根拠ではなく、実際のコードやドキュメントに基づいている必要があります。
• 矛盾のフラグ付けを省略する — 領域間の不整合は実際のシグナルであり、ノイズではありません。
• 発見した PDR に「Proposed」ステータスを割り当てる — 既存のコードベースをもとに作成する PDR のステータスは、提案済みではなく Discovered です。

検証

• セットアップスクリプトが、すべてのパスを含む有効な JSON を返す
• .adlc/drafts/pdr/ ディレクトリが存在する
• ステータスが「Discovered」の PDR-*.md ファイルが少なくとも 1 つ作成されている
• pdr.md インデックスが正しい表とともに自動生成されている
• 状態ファイルが .adlc/product/state.json に書き込まれている
• 不整合のフラグが別ファイルではなく、該当する PDR に埋め込まれている
• インデックスに機能領域を横断した分析の概要が記載されている
• PDR ID が重複していない