product-capability

name	product-capability
description	PRD の意図、ロードマップの要求、製品ディスカッションを、マルチサービス作業を開始する前に制約、不変条件、インターフェース、未解決の決定事項を明示する実装可能なケイパビリティプランに翻訳します。ユーザーが曖昧な計画の散文ではなく、ECC ネイティブな PRD-to-SRS レーンを必要としている場合に使用します。
origin	ECC

Product Capability

このスキルは製品の意図を明示的なエンジニアリング制約に変換します。

ギャップが "何を作るべきか？" ではなく "実装開始前に正確に何が真でなければならないか？" である場合に使用します。

使用タイミング

• PRD、ロードマップ項目、ディスカッション、またはファウンダーノートが存在するが、実装制約がまだ暗黙的である場合
• 機能が複数のサービス、リポジトリ、またはチームにまたがり、コーディング前にケイパビリティ契約が必要な場合
• 製品の意図は明確だが、アーキテクチャ、データ、ライフサイクル、またはポリシーの含意がまだ曖昧な場合
• シニアエンジニアがレビュー中に同じ隠れた前提を繰り返し述べている場合
• ハーネスやセッションを横断して生き残る再利用可能なアーティファクトが必要な場合

正規アーティファクト

リポジトリに PRODUCT.md、docs/product/、またはプログラム仕様ディレクトリのような永続的な製品コンテキストファイルがある場合は、そこで更新します。

ケイパビリティマニフェストがまだ存在しない場合は、次のテンプレートを使って作成します:

• docs/examples/product-capability-template.md

目的は別の計画スタックを作ることではありません。隠れたケイパビリティ制約を永続化して再利用可能にすることが目的です。

ノンネゴシャブルなルール

• 製品の真実を発明しない。未解決の質問は明示的にマークする
• ユーザーに見える約束を実装詳細から分離する
• 何が固定ポリシーか、何がアーキテクチャの好みか、何がまだオープンかを明示する
• リクエストが既存の repo 制約と矛盾する場合、平滑化せずに明確に伝える
• 散在するアドホックノートよりも 1 つの再利用可能なケイパビリティアーティファクトを優先する

入力

必要なもののみを読む:

1. 製品の意図
   • issue、discussion、PRD、ロードマップノート、ファウンダーメッセージ
2. 現在のアーキテクチャ
   • 関連する repo ドキュメント、契約、スキーマ、ルート、既存のワークフロー
3. 既存のケイパビリティコンテキスト
   • PRODUCT.md、設計ドキュメント、RFC、マイグレーションノート、運用モデルドキュメント