product-development

プロダクト開発ライフサイクル

アイデアから実装計画まで、プロダクト開発ライフサイクル全体を通じて機能を導きます。各ワークフローで、次の段階に引き継がれる特定の成果物を作成します。ワークフロー間の移行には人によるレビューが必要で、任意で自動レビューを実施できます。

ライフサイクルマップ

[Project Setup]                              ← one-time setup (scripts/init.sh)
  ↓
Foundation Stage
  ├─ Product Constitution approval
  ├─ Product Vision workflow (Vision Grill)
  ├─ additional product-anchor workflows (planned extension point)
  └─ Foundation Gate: approved, versioned constitution + approved, versioned vision before first PRD
  ↓
Discovery and Design
  ↓  [human approves design]
Requirements
  ├─ PRD  [human approves before TRD]
  └─ TRD  [human approves PRD + TRD]  → optional review pass
  ↓
User Stories
  ↓  [human approves stories]         → optional review pass
BDD Scenarios
  ↓  [human approves scenarios]       → optional review pass
Implementation Planning

Foundation Stageは、ブレインストーミングやデザインの検討を妨げません。Foundation Gateでは、最初のPRDの作成を保留します。それ以降のPRDでは、先に進む前に憲章とビジョンとの整合性を確認する必要があります。

ワークフロー

プロジェクトのセットアップ

トリガー： プロジェクトにまだdocs/product/ディレクトリがない場合、またはユーザーが「プロダクトドキュメントを初期化する」あるいは「プロダクトドキュメントをセットアップする」と依頼した場合です。

プロセス： 初期化スクリプト（scripts/init.sh）を実行して、ドキュメント構造をひな形から作成します。スクリプトはプレースホルダーを含むテンプレートを使用し、プロジェクトのコンテキスト（名前、対象サーフェス）を自動検出して、ドメイン固有の値をユーザーに確認します。ワークフロー全体については、references/initialization.mdを参照してください。

出力：

• docs/product/README.md — ドキュメント階層と境界ルール
• docs/product/AGENTS.md — プロダクトドキュメントを整理するためのエージェント向けガイダンス
• docs/product/features/ — 最初の機能に備えた空のディレクトリ

このワークフローはプロジェクトごとに1回実行します。 docs/product/README.mdがすでに存在する場合はスキップしてください。

Foundation Stage

トリガー： docs/product/constitution.mdまたはdocs/product/vision.mdが存在しない場合、ユーザーがプロダクトの基盤ドキュメントの作成または更新を依頼した場合、あるいはエージェントが最初の機能PRDの作成を始める前に、ドラフト作成に先立ってFoundation Gateを確認する必要がある場合です。

プロセス： 次の階層に沿って、プロダクトの基盤ドキュメントを整備します。

1. Product Constitutionワークフロー：承認済みでバージョン管理されたdocs/product/constitution.mdを作成、批准、または改訂します。grill-with-docsの依存関係の動作、Constitution Grillワークフロー、バージョン管理、改訂の動作、憲章との整合性チェックについては、references/product-constitution.mdを参照してください。
2. Product Visionワークフロー：Constitutionの承認後、Vision Grillを実行します。grill-with-docsの依存関係の動作、コンテキスト／ADRの調整、ビジョンのバージョン管理については、references/product-vision.mdを参照してください。
3. 追加のプロダクト基盤ワークフロー：承認されたプロダクト基盤ドキュメント向けの、今後の拡張ポイントです。
4. Foundation Gate：承認済みでバージョン管理されたdocs/product/constitution.mdと、承認済みでバージョン管理されたdocs/product/vision.mdが存在する場合にのみ完了します。

出力： 承認済みでバージョン管理されたdocs/product/constitution.md、承認済みでバージョン管理されたdocs/product/vision.md、および承認され使用される場合は、任意のCONTEXT-MAP.md、docs/product/CONTEXT.md、ADR。

Foundation Gate： ユーザーがdocs/product/constitution.mdを承認し、バージョンメタデータが付与され、承認済みでバージョン管理されたdocs/product/vision.mdが存在するまで、最初のPRDを作成しないでください。

探索と設計

トリガー： アイデア、機能リクエスト、または問題の説明を受け取った場合です。

プロセス： brainstormingスキルを呼び出します。このスキルが、共同での探索、アプローチの提案、設計の承認を担当します。

出力： docs/plans/YYYY-MM-DD-<topic>-design.mdに保存された承認済みの設計ドキュメント。

ゲート： 設計が承認されるまで、要件の段階に進まないでください。

要件

トリガー： 設計ドキュメントが承認されたとき。

必須入力： 承認済みの設計ドキュメント、承認済みかつバージョン管理された docs/product/constitution.md、および承認済みかつバージョン管理された docs/product/vision.md。基盤となるドキュメントが欠落している、未承認、またはバージョン管理されていない場合、初回の PRD 要件作業は開始できません。

プロセス： 製品要件ドキュメントと技術要件ドキュメントを作成します。構成、規約、憲章との整合性、ビジョンとの整合性については references/phase-2-requirements.md を参照してください。

ゲート： PRD は 何をするか を定義し、TRD は どのように実現するか を定義します。TRD を作成する前に、PRD を提示して人間の承認を得てください。これにより、要件が変更された場合にアーキテクチャ作業が無駄になるのを防ぎます。

出力：

• docs/product/features/{feature}/PRD.md
• docs/product/features/{feature}/TRD.md

ゲート： 次に進む前に、両方のドキュメントのレビューと承認が必要です。設定済みのレビュー工程を実行してください（「設定」を参照）。

成果物はプラットフォームレベルに配置します — 要件では、製品がどのサーフェスで利用されるかにかかわらず、その製品が何をするかを記述します。

ユーザーストーリー

トリガー： PRD と TRD のレビューが完了し、内容が確定したとき。

プロセス： PRD の要件を、ユーザー視点のナラティブに分解します。形式、サイズの目安、受け入れ基準の規約については references/phase-3-user-stories.md を参照してください。

出力： docs/product/features/{feature}/stories/ にストーリーファイルを作成します。

ゲート： ストーリーのレビューと承認が必要です。設定済みのレビュー工程を実行してください。

ストーリーはプラットフォームレベルです — サーフェス固有の操作ではなく、ユーザーの意図を記述します。

BDD シナリオ

トリガー： ユーザーストーリーに受け入れ基準が定義されたとき。

プロセス： 受け入れ基準を Gherkin シナリオとして表現します。境界ルール、ファイルの配置場所、記述規約については references/phase-4-scenarios.md を参照してください。

出力：

• プラットフォームレベルのシナリオ：docs/product/features/{feature}/scenarios/*.feature
• サーフェス固有のシナリオ：apps/{surface}/docs/features/{feature}/scenarios/*.feature

ゲート： シナリオのレビューと承認が必要です。設定済みのレビュー工程を実行してください。

境界ルール： Given/When/Then の記述がサーフェスに依存しない場合、そのシナリオはプラットフォームレベルです。特定の操作モデル（スワイプ、D-pad、視線）を参照する場合、そのシナリオはサーフェス固有です。

実装計画

トリガー： シナリオのレビューが完了し、受け入れ基準が網羅されているとき。

プロセス： 承認済みの憲章とビジョンを、レビュー済みのシナリオとともに読み込んでから、writing-plans スキルを呼び出します。このスキルは、TDD の手順、ファイルパス、検証基準を含む、タスクごとの詳細な実装計画を作成します。計画が MUST NOT の記述に違反する、憲章の原則を弱める、承認済みのビジョンと矛盾する、または明確な権限を超える場合は、計画作成に進まないでください。

出力： docs/plans/YYYY-MM-DD-<topic>.md に実装計画を作成します。

ゲートとレビュー工程

ゲートの動作

各ゲートでは、次の手順を実行します。

1. エージェントが成果物を人間に提示してレビューを依頼します
2. このゲートにレビュー工程が設定されている場合、人間によるレビューの前に実行し、その指摘事項を提示内容に含めます
3. 人間が承認、変更の依頼、または却下を行います
4. 承認された場合は次のワークフローに進みます。変更が依頼された場合は修正し、再度提示します。

設定可能なレビュー工程

レビュー工程は、人間によるレビューの前にゲートで実行する任意の自動チェックです。プロジェクト単位またはユーザー単位で設定します（「設定」を参照）。例：

• 憲章との整合性チェック — PRD がすべてのガバナンス原則を満たしていることを確認します
• トレーサビリティ監査 — すべての FR-* がストーリーでカバーされ、すべてのストーリーがシナリオでカバーされていることを確認します
• コードレビュ－エージェント — レビュー用スキル（例：coderabbit:review）を成果物に対して実行します
• カスタムレビュープロンプト — AGENTS.md に記載されたプロジェクト固有のレビュー指示

ゲートにレビュー工程が設定されていない場合、そのゲートでは人間のみがレビューを行います。

設定

設定は2か所にあり、プロジェクトレベルの設定がユーザーレベルの設定を上書きします。

• ユーザーレベル： ~/.config/prometheas-product-development-skill/
• プロジェクトレベル： $PROJECT_ROOT/.config/prometheas-product-development-skill/

settings.toml

どこで何を実行するかを定義する、宣言型の構造化設定です。

[review_gates.requirements]
reviews = ["constitution-check"]

[review_gates.user_stories]
reviews = ["traceability-audit"]

[review_gates.bdd_scenarios]
reviews = ["traceability-audit", "coderabbit:review"]

[workflows]
use_subagents = true      # Delegate heavy writing to sub-agents
prd_before_trd = true     # Human approves PRD before TRD

AGENTS.md

レビューエージェントがコンテキストとして受け取る自然言語の指示です。構造化設定に収まらない、細かなプロジェクト固有のガイダンスに使用します。

## Review Context
When reviewing PRDs, ensure constitution alignment with particular
attention to Principle II (Privacy).

## Requirements Notes
All TRDs must follow the vendor-agnostic facade pattern.

マージ動作

プロジェクトレベルの settings.toml はキーごとにユーザーレベルの設定を上書きします。プロジェクトレベルの AGENTS.md はユーザーレベルの AGENTS.md の後に追加されるため、コンテキストではプロジェクト固有の指示が優先されます。

設定がない場合

どちらの設定場所にも設定がない場合、このスキルはデフォルトで実行されます。つまり、承認ゲートは人間のみ、自動レビューの工程はなく、サブエージェントはコンテキストのサイズに応じてエージェントの判断で使用されます。

コンテキスト管理

要件、ユーザーストーリー、BDD シナリオの作成には、多くの文章が必要です。メインコンテキストをオーケストレーションと人間との協業に集中させるため、文章作成の負荷が高い作業はサブエージェントに委任してください。ライフサイクルは順次進行し、ワークフローを並行して実行してはいけません。

サブエージェントのディスパッチパターン

各文章作成ワークフローでは、必要な入力だけをサブエージェントに渡してディスパッチします。

ワークフロー	サブエージェントが受け取るもの	サブエージェントが返すもの
要件 PRD	設計ドキュメント、規約、ビジョン、references/phase-2-requirements.md、機能の例	ディスクに書き込まれた PRD
要件 TRD	承認済み PRD、規約、ビジョン、references/phase-2-requirements.md、機能の例	ディスクに書き込まれた TRD
ユーザーストーリー	承認済み PRD、TRD、規約、ビジョン、references/phase-3-user-stories.md	ディスクに書き込まれたストーリーファイル
BDD シナリオ	ユーザーストーリー、TRD、規約、ビジョン、references/phase-4-scenarios.md	ディスクに書き込まれた .feature ファイル

メインコンテキストでは人間とともにサブエージェントの出力をレビューし、必要に応じて修正を重ねます。

メインコンテキストで作業する場合

すべてのワークフローにサブエージェントが必要なわけではありません。次の場合はメインコンテキストで作業します。

• 成果物について人間が対話しながら共同作業することを希望している
• 機能が小さく、コンテキスト内で無理なく作成できる
• 人間から一緒に進めるよう明示的に依頼されている

ドキュメント階層

すべてのプロダクトドキュメントは、3層の階層に従います。詳しい仕様については docs/product/README.md を参照してください。

階層	場所	内容
プラットフォーム	docs/product/	PRD、TRD、ユーザーストーリー、プラットフォームレベルのシナリオ
アプリ	apps/{surface}/docs/	サーフェス固有のシナリオ
コード	apps/{surface}/tests/	ステップ定義（テスト自動化）

ワークフローの選択

すべての機能が最初から始まるわけではありません。現在の状態に合った開始地点を選んでください。

開始時の状態	開始地点
docs/product/ ディレクトリがない	プロジェクトのセットアップ
最初の PRD 作成前に、規約またはビジョンがない、未承認、あるいはバージョン管理されていない	基盤ステージ
アイデアが曖昧で、アプローチが明確でない	発見と設計
要件が明確で、ドキュメント化が必要	基盤ゲート通過後の要件定義
PRD があり、分解が必要	ユーザーストーリー
ストーリーがあり、テスト可能な基準が必要	BDD シナリオ
シナリオがあり、実装が必要	実装計画

要件が明確な場合は、基盤ゲートを通過した後に限り、ブレインストーミングを省略できます。これが最初の PRD であり、docs/product/constitution.md または docs/product/vision.md がない、未承認、あるいはバージョン管理されていない場合は、要件定義の前に基盤ステージを実施してください。

スキルの委任

このスキルはライフサイクルをオーケストレーションしますが、前後のワークフローは専門スキルに委任します。

• 発見と設計： brainstorming スキルに委任します
• 要件定義、ユーザーストーリー、BDD シナリオ： このスキルのリファレンスファイルに従います
• 実装計画： writing-plans スキルに委任します

仕様の進化

製品仕様は継続的に更新される成果物です。成果物の種類によって、進化する速度は異なります。手法の全容については、docs/METHODOLOGY.md を参照してください。概要：

成果物	方針
憲章、ビジョン	不変＋後継版で置き換え（セマンティックバージョニング）
PRD、TRD	変更履歴付きの継続的に更新されるドキュメント
ユーザーストーリー	継続的に更新 — 追加、完了、アーカイブ
プラットフォームシナリオ	継続的に更新＋自己検証
サーフェスシナリオ	継続的に更新＋自己検証

既存の仕様を更新する場合は、日付、変更内容、理由を変更履歴に追記してください。変更が大規模で、元の文書とは見分けがつかないほどになる場合は、代わりに新しい文書で置き換えてください。

参照ファイル

各ワークフローの詳細なガイダンスは、コンテキストを対象に絞るため、参照ファイルに記載されています。phase-* というファイル名は旧来の互換パスです。以下のワークフロー名に従って読み込んでください。

• references/initialization.md — プロジェクト初期化ワークフロー、プレースホルダー、初期化後の手順
• references/product-constitution.md — 製品憲章ワークフロー、Foundation Gate、Constitution Grill、バージョン管理、改定時の動作、整合性チェック
• references/product-vision.md — 製品ビジョンワークフロー、Foundation Gate、Vision Grill、バージョン管理、コンテキスト／ADR の調整
• references/phase-2-requirements.md — PRD と TRD の構成、規約、憲章およびビジョンのチェック
• references/phase-3-user-stories.md — ストーリーの形式、受け入れ基準、規模の見積もり
• references/phase-4-scenarios.md — Gherkin の規約、境界ルール、ファイルの配置
• docs/METHODOLOGY.md — 仕様の進化方針、変更履歴の規約、後継版への置き換えルール

正確なソースの詳細が必要な場合に限り、references/source/product-constitution-guide.md は references/product-constitution.md を通じて読み込んでください。正確なソースの詳細が必要な場合に限り、references/source/vision-document-guide.md は references/product-vision.md を通じて読み込んでください。

スクリプト

• scripts/init.sh — プロジェクト初期化スクリプト。プレースホルダーを置換し、テンプレートから docs/product/ を生成します。対話型プロンプト、CLI 引数、--dry-run に対応しています。

テンプレート

• templates/README.md.tmpl — ドキュメント階層のテンプレート
• templates/AGENTS.md.tmpl — エージェント向けガイダンスのテンプレート