プロダクト能力計画 は何をしますか？
このスキルは、プロダクトの意図を明示的なエンジニアリング制約に変換します。
「何を構築すべきか？」ではなく、「実装開始前に真実であるべきものは何か？」というギャップがある場合に使用します。
使用すべきタイミング
- PRD、ロードマップ項目、議論、ファウンダーノートは存在するが、実装制約がまだ暗黙的である場合
- 機能が複数のサービス、リポジトリ、チームにまたがり、コーディング前に能力契約が必要な場合
- プロダクト意図は明確だが、アーキテクチャ、データ、ライフサイクル、ポリシーの影響がまだ不明瞭な場合
- シニアエンジニアがレビュー中に同じ暗黙の前提を繰り返し述べている場合
- ハーネスやセッションを超えて持続可能な再利用可能なアーティファクトが必要な場合
正規アーティファクト
リポジトリに PRODUCT.md、docs/product/、プログラムスペックディレクトリなどの耐久性のあるプロダクトコンテキストファイルが存在する場合は、そこを更新します。
能力マニフェストがまだ存在しない場合は、以下のテンプレートを使用して作成します：
docs/examples/product-capability-template.md
目標は別の計画スタックを作成することではありません。目標は隠れた能力制約を耐久性があり再利用可能にすることです。
絶対的なルール
- プロダクトの真実を発明してはいけません。未解決の質問は明示的にマークしてください。
- ユーザーが見える約束と実装の詳細を分離してください。
- 固定されたポリシー、アーキテクチャの好み、まだオープンなものを明確に区別してください。
- リクエストが既存のリポジトリ制約と矛盾する場合は、ごまかさずに明確に伝えてください。
- 散発的なアドホックなメモよりも、一つの再利用可能な能力アーティファクトを優先してください。
入力
必要なものだけを読みます：
- プロダクト意図
- issue、議論、PRD、ロードマップノート、ファウンダーメッセージ
- 現在のアーキテクチャ
- 関連するリポジトリ文書、契約、スキーマ、ルート、既存のワークフロー
- 既存の能力コンテキスト
PRODUCT.md、設計文書、RFC、移行ノート、運用モデル文書
- 配信制約
- 認証、課金、コンプライアンス、ロールアウト、後方互換性、パフォーマンス、レビューポリシー
コアワークフロー
1. 能力の再定義
要求を一つの正確な文に圧縮します：
- ユーザーまたはオペレーターは誰か
- この機能がリリースされた後、どのような新しい能力が存在するか
- それによってどのような結果が変わるか
この文が弱いと、実装は漂流します。
2. 能力制約の解決
実装前に保持すべき制約を抽出します：
- ビジネスルール
- スコープ境界
- 不変条件
- 信頼境界
- データ所有権
- ライフサイクル遷移
- ロールアウト / 移行要件
- 障害および復旧期待値
これらは、しばしばシニアエンジニアの記憶にのみ存在するものです。
3. 実装向け契約の定義
SRSスタイルの能力計画を作成します：
- 能力概要
- 明示的な非目標
- アクターと表面
- 必要な状態と遷移
- インターフェース / 入力 / 出力
- データモデルへの影響
- セキュリティ / 課金 / ポリシー制約
- 可観測性とオペレーター要件
- 実装を妨げる未解決の質問
4. 実行への変換
正確なハンドオフで終了します：
- 直接実装可能
- 最初にアーキテクチャレビューが必要
- 最初にプロダクトの明確化が必要
必要に応じて、次のECCネイティブレーンを指します：
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
出力形式
結果を次の順序で返します：
能力
- 一段落の再定義
制約
- 固定ルール、不変条件、境界
実装契約
- アクター
- 表面
- 状態と遷移
- インターフェース / データへの影響
非目標
- このレーンが明示的に担当しないこと
未解決の質問
- ブロッカーまたはまだ必要なプロダクト決定事項
ハンドオフ
- 次に何が起こるべきか、どのECCレーンが引き継ぐべきか
良い成果
- プロダクト意図が、PRの途中で隠れた制約を再発見することなく実装可能なほど具体的になる。
- エンジニアリングレビューが、記憶やSlackのコンテキストに頼る代わりに耐久性のあるアーティファクトを持つ。
- 結果の計画が、Claude Code、Codex、Cursor、OpenCode、ECC 2.0の計画面で再利用可能になる。