Product Capability

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

ギャップが「何を構築すべきか？」ではなく「実装開始前に正確に何が真実でなければならないか？」である場合に使用してください。

使用すべき場合

• PRD、ロードマップ項目、ディスカッション、またはファウンダーノートは存在するが、実装の制約がまだ暗黙的である
• 機能が複数のサービス、リポジトリ、またはチームにまたがり、コーディング前に機能契約が必要である
• 製品の意図は明確だが、アーキテクチャ、データ、ライフサイクル、またはポリシーの影響がまだ不明確である
• シニアエンジニアがレビュー中に同じ隠れた仮定を何度も言い直している
• ハーネスとセッションを超えて存続できる再利用可能なアーティファクトが必要である

標準的なアーティファクト

リポジトリに PRODUCT.md、docs/product/、またはプログラム仕様ディレクトリなどの耐久性のある製品コンテキストファイルがある場合は、そこで更新してください。

機能マニフェストがまだ存在しない場合は、以下のテンプレートを使用して作成してください：

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

目標は別の計画スタックを作成することではありません。目標は、隠れた機能の制約を耐久性があり再利用可能にすることです。

譲歩できないルール

• 製品の真実を創作しないこと。未解決の質問は明示的にマークしてください。
• ユーザーに見える約束と実装の詳細を分離してください。
• 何が固定的なポリシーで、何がアーキテクチャの優先事項で、何がまだ未定かを明確にしてください。
• リクエストが既存のリポジトリの制約と矛盾する場合は、それを平滑化する代わりに明確に述べてください。
• 散在するアドホックノートではなく、1つの再利用可能な機能アーティファクトを優先してください。

インプット

必要なものだけを読んでください：

1. 製品の意図
   • issue、ディスカッション、PRD、ロードマップノート、ファウンダーメッセージ
2. 現在のアーキテクチャ
   • 関連するリポジトリドキュメント、契約、スキーマ、ルート、既存のワークフロー
3. 既存の機能コンテキスト
   • PRODUCT.md、デザインドキュメント、RFC、マイグレーションノート、運用モデルドキュメント
4. デリバリー制約
   • 認証、請求、コンプライアンス、ロールアウト、後方互換性、パフォーマンス、レビューポリシー

コアワークフロー

1. 機能を言い直す

質問を1つの正確なステートメントに圧縮してください：

• ユーザーまたはオペレーターは誰か
• これが出荷された後に存在する新しい機能は何か
• それによって何が変わるか

このステートメントが弱い場合、実装はドリフトします。

2. 機能の制約を解決する

実装前に成立しなければならない制約を抽出してください：

• ビジネスルール
• スコープ境界
• 不変量
• トラスト境界
• データ所有権
• ライフサイクル遷移
• ロールアウト / マイグレーション要件
• 失敗と復旧の期待

これらはしばしばシニアエンジニアの記憶の中だけに存在するものです。

3. 実装向けの契約を定義する

SRSスタイルの機能計画を以下で作成してください：

• 機能サマリー
• 明示的な非目標
• アクターとサーフェス
• 必要な状態と遷移
• インターフェース / インプット / アウトプット
• データモデルの影響
• セキュリティ / 請求 / ポリシー制約
• 可観測性とオペレーター要件
• 実装を阻むオープンな質問

4. 実行に変換する

正確なハンドオフで終わってください：

• 直接実装の準備ができている
• 最初にアーキテクチャレビューが必要
• 最初に製品の明確化が必要

有用な場合は、次のECCネイティブレーンを指してください：

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

出力形式

この順序で結果を返してください：

CAPABILITY
- 1段落の言い直し

CONSTRAINTS
- 固定的なルール、不変量、境界

IMPLEMENTATION CONTRACT
- アクター
- サーフェス
- 状態と遷移
- インターフェース/データの影響

NON-GOALS
- このレーンが明示的に所有しないもの

OPEN QUESTIONS
- ブロッカーまたはまだ必要な製品の決定

HANDOFF
- 次に何が起こるべきか、どのECCレーンが対応するか

良い成果

• 製品の意図が今や具体的で、PR中に隠れた制約を再発見せずに実装できる。
• エンジニアリングレビューはメモリまたはSlackコンテキストに依存する代わりに、耐久性のあるアーティファクトを持っている。
• 結果の計画は、Claude Code、Codex、Cursor、OpenCode、およびECC 2.0計画サーフェス全体で再利用可能である。