product-specify

product-specify

このスキルでできること

対話形式の探索とトレードオフ分析を通じて、高レベルの製品アイデアを文書化された Product Decision Record（PDR）に変換します。

重要なポイント：正式な文書にまとめる前に、議論と探索を行います。トレードオフを明らかにし、前提を検証して、協力しながら情報に基づいた意思決定を行うことが目的です。

出力：.adlc/drafts/pdr/ に作成される、個別の PDR-{NNN}.md ファイル（ステータスは Proposed）と、自動生成される pdr.md インデックス。

使用するタイミング

注：日常的な意思決定の記録は、team-boot の継続的な 記録メカニズムが担当し、軽量なドラフトを直接 .adlc/drafts/ に書き込みます。このスキルは、文書化する前に ガイド付きのトレードオフ分析、複数案の比較、または 構造化された意思決定の進行を行いたい場合の、対話形式の詳細な探索に使用します。

• 新しい製品をゼロから作る
• 製品の大幅な方向転換
• 口頭で決定した内容を正式に文書化する
• チームのオンボーディング — 製品の根拠を順に説明する

使用しないタイミング

• 既存の製品（代わりに /product-init を使用）
• 軽微な PDR の更新（代わりに /product-clarify を使用）

実行手順

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

sh: scripts/bash/setup-product-specify.sh [--json]
ps: scripts/powershell/setup-product-specify.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",
  "next_pdr": "001"
}

フェーズ 1：機能領域の分解（任意）

製品を個別のビジネス領域に分解できるか分析します。複数の領域が検出された場合は、自動的に分解します。スキップするには --no-decompose を使用します。

検出された領域を提示：

## Detected Feature Areas

| # | Feature Area | Key Domains | Rationale |
|---|--------------|-------------|-----------|
| 1 | **Auth** | Authentication, Authorization | Core user entry |
| 2 | **Core** | User Management, Profiles | Core data |
| 3 | **Business** | Payments, Subscriptions | Revenue domain |

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

しきい値：

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

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

フェーズ 2：製品分析

製品の推進要因を抽出します。

1. 問題の推進要因：中核となる問題、それを経験する人、現在の回避策
2. 市場の推進要因：対象セグメント、競争環境、トレンド
3. ビジネスの推進要因：収益モデル、拡大の見込み、戦略的重要性
4. 制約の推進要因：技術要件、予算、チームのスキル、規制
5. 憲章の読み込み：{REPO_ROOT}/docs/adlc/memory/constitution.md（レガシー版 {REPO_ROOT}/.adlc/memory/constitution.md はフォールバックとして参照 — 両方を読み込み）を、いずれかが存在する場合に読み込みます
6. 既存ドキュメントの確認：README.md、AGENTS.md、CONTRIBUTING.md を調べて背景情報を確認します

フェーズ 3：製品の探索（対話形式）

主な意思決定領域ごとに選択肢を提示し、議論を進めます。

意思決定領域（主要な決定事項を 5～7 件）：

1. 問題の範囲
2. 対象ペルソナ
3. ソリューションのアプローチ（開発するか、購入するか、提携するか）
4. 収益化
5. 市場投入戦略
6. 成功指標

探索の形式：

## Product Decision: [Decision Area]

**Context**: [Why this decision matters]

**Options**:
| Option | Description | Trade-offs |
|--------|-------------|------------|
| A | [Option A] | Pros: [X] / Cons: [Y] |
| B | [Option B] | Pros: [X] / Cons: [Y] |

**Recommended**: Option [X]

**Questions**:
1. [Question about constraints]
2. [Question about trade-off priorities]

ルール：

• 一度に 1 つの意思決定領域を提示します
• 理由とともに、必ず推奨案を示します
• 隠れた要件を明らかにするため、的を絞った質問をします
• コンテキストや憲章によってすでに決定されている事項はスキップします
• 主要な決定事項は5～7 件に絞ります

フェーズ 4：機能領域をまたぐ事前分析

探索中は、次のパターンに注意します。

パターン	検出方法	対応
共通ペルソナ	複数の領域で同じユーザータイプが登場する	領域横断のメタデータ用に記録
優先順位の相反	領域ごとに優先順位が異なる	⚠️ 潜在的な衝突としてフラグを立てる
機能の重複	異なる領域に類似した機能がある	⚠️ 統合候補としてフラグを立てる
指標の不一致	同じ指標に異なる目標値がある	⚠️ 調整が必要な項目としてフラグを立てる

フェーズ 5：意思決定の文書化

各決定が確認された後、PDR ファイルを作成します。

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

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

---
status: proposed
date: YYYY-MM-DD
owner: [User/AI collaboration]
category: Feature
feature-area: [core | business | growth | ...]
title: [Decision Title]
---

# PDR-[NNN]: [Decision Title]

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

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

## Decision
**Decision Statement:**
[Clear statement of what was decided]

**Rationale:**
[Why this option was chosen]

### 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]

### Constitution/Vision Alignment
| Principle | Alignment | Notes |
|-----------|-----------|-------|
| [Vision Principle] | ✅ Compliant / ⚠️ Deviation | [Explanation] |

フェーズ 6：PDR ファイルを作成し、インデックスを再生成する

1. 順番に番号を付ける：既存の PDR の最大番号 + 1 から開始します
2. 個別ファイルを作成する：{REPO_ROOT}/.adlc/drafts/pdr/PDR-{NNN}.md
3. インデックスを再生成する：{REPO_ROOT}/.adlc/drafts/pdr/pdr.md

インデックスの形式：

# Product Decision Records

## PDR Index

| ID | Feature-Area | Category | Status | Date | Owner |
|----|--------------|----------|--------|------|-------|
| PDR-001 | System | Target Market | Proposed | 2026-03-09 | User/AI |
| PDR-002 | Auth | Primary Persona | Proposed | 2026-03-09 | User/AI |

---

*Individual PDR files: PDR-*.md in this directory*

フェーズ 7：概要レポート

## Feature Area Decomposition Summary

### Feature Areas Identified: 3

| # | Feature Area | PDRs Created |
|---|--------------|--------------|
| 1 | System-Level | PDR-001: Target Market |
| 2 | Auth | PDR-002: Primary Persona, PDR-003: Authentication Approach |
| 3 | Business | PDR-004: Pricing Model, PDR-005: Payment Integration |

### Next Steps
1. Review PDRs with /product-clarify
2. Generate PRD.md with /product-implement

PDR の番号付けルール

• {REPO_ROOT}/.adlc/drafts/pdr/ 内の既存の PDR-*.md ファイルを検索します
• 数値の接尾辞を抽出し、最大値を特定します
• 次の PDR = 最大値 + 1。3 桁になるようゼロ埋めします
• 番号を再利用しないでください

重要なルール

まず探索する

• 製品の説明から PRD を直接生成しないでください
• 前提を検証するために、議論を行ってください
• 決定する前に、トレードオフを明らかにしてください
• 反復を可能にしてください — ユーザーは以前の決定を再検討できます

憲章への準拠

• PDR は憲章の原則に沿う必要があります
• 製品要件と憲章の間にある矛盾を明示してください
• 憲章に違反する場合は、根拠を示した明示的な上書きが必要です

段階的な PDR

• 焦点を絞った PDR を作成します — 1 つの PDRにつき 1 つの決定を扱います
• 決定が相互に影響する場合は、関連する PDR をリンクしてください
• 後から決定できる事項は先送りしてください
• 修正が必要になる可能性がある暫定的な決定には、その旨を記してください

設定

• PDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/pdr
• PDR_INDEX — {REPO_ROOT}/.adlc/drafts/pdr/pdr.md
• PRD_FILE — {REPO_ROOT}/docs/adlc/product/PRD.md
• CONSTITUTION — {REPO_ROOT}/docs/adlc/memory/constitution.md（レガシーの .adlc/memory/constitution.md をフォールバックとして使用）

12-Factor との整合性

• Factor III（ミッションの定義）：実行前に製品のミッションを定義します
• Factor XI（ディレクティブをコードとして扱う）：PDR はバージョン管理された意思決定の記録です

よくある正当化

正当化	実態
「PRD を直接書けばいいだけです。」	PDR のない PRD には、追跡可能な根拠がありません。決定は文書化されていない前提になります。
「何を作るかはもう分かっています。」	「明白」に見える決定にも代替案があります。文書化することで、将来の覆しを防げます。
「探索に時間がかかりすぎます。」	今 10 分話し合えば、後で何週間にもわたる手戻りを防げます。

危険信号

• PDR が承認される前に PRD を生成する — /product-implement では Accepted ステータスが必要です。Proposed の PDR はスキップされます。
• 憲章の確認を省略する — 整合性のない決定が PRD に引き継がれ、修正コストが高くなります。
• 代替案を記録しない — 代替案のない PDR は決定ではなく、単なる表明です。

検証

• セットアップスクリプトが、すべてのパスを含む有効な JSON を返す
• .adlc/drafts/pdr/ ディレクトリが存在する
• ステータスが「Proposed」の PDR-*.md ファイルが少なくとも 1 つ作成されている
• pdr.md インデックスが、正しい表とともに自動生成されている
• 憲章との整合性が確認されている（憲章が存在する場合）
• 機能領域をまたぐ矛盾が明示されている
• PDR ID が重複していない
• 各 PDR に少なくとも 2 つの代替案が記録されている