product-init

product-init

此技能的作用

通过三阶段分析流程，从现有产品中逆向推导产品决策：

1. Discovery Agent：扫描每个功能领域，查找原始产品信号（代码、文档、定价）
2. Pattern Agent：将信号归类到 PDR 类别，评估战略重要性
3. Synthesis Agent：跨功能领域分析，并标记不一致之处

输出：在 .adlc/drafts/pdr/ 中生成单独的 PDR-{NNN}.md 文件（状态为 Discovered），并自动生成 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：检测功能领域

从三个来源检测功能领域：

来源	检测模式
目录结构	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 frontmatter——使用共享模板）：

将 {REPO_ROOT}/.agents/skills/product/../templates/pdr-template.md 中的模板作为规范的 PDR 格式。模板包含 YAML frontmatter（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，而非 Proposed。

验证

• 设置脚本返回包含所有路径的有效 JSON
• .adlc/drafts/pdr/ 目录存在
• 至少创建一个状态为 "Discovered" 的 PDR-*.md 文件
• 自动生成的 pdr.md 索引包含正确的表格
• 状态文件已写入 .adlc/product/state.json
• 不一致标记嵌入受影响的 PDR 中（而非单独的文件）
• 索引中包含跨功能领域分析摘要
• 没有重复的 PDR ID