| 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 つの再利用可能なケイパビリティアーティファクトを優先する
入力
必要なもののみを読む:
- 製品の意図
- issue、discussion、PRD、ロードマップノート、ファウンダーメッセージ
- 現在のアーキテクチャ
- 関連する repo ドキュメント、契約、スキーマ、ルート、既存のワークフロー
- 既存のケイパビリティコンテキスト
PRODUCT.md、設計ドキュメント、RFC、マイグレーションノート、運用モデルドキュメント
- デリバリ制約
- 認証、課金、コンプライアンス、ロールアウト、後方互換性、パフォーマンス、レビューポリシー
コアワークフロー
1. ケイパビリティを再定義する
依頼を 1 つの正確なステートメントに圧縮する:
- 誰がユーザーまたはオペレーターか
- これが出荷された後に存在する新しいケイパビリティは何か
- そのためにどのような結果が変わるか
このステートメントが弱い場合、実装は漂流します。
2. ケイパビリティ制約を解決する
実装前に成り立つ必要のある制約を抽出する:
- ビジネスルール
- スコープ境界
- 不変条件
- 信頼境界
- データ所有権
- ライフサイクル遷移
- ロールアウト / マイグレーション要件
- 障害および復旧の期待値
これらはシニアエンジニアの記憶にのみ存在することが多いものです。
3. 実装向けの契約を定義する
SRS スタイルのケイパビリティプランを作成する:
- ケイパビリティサマリー
- 明示的なノンゴール
- アクターとサーフェス
- 必要なステートと遷移
- インターフェース / 入力 / 出力
- データモデルの含意
- セキュリティ / 課金 / ポリシー制約
- 可観測性とオペレーター要件
- 実装をブロックするオープンな質問
4. 実行に翻訳する
正確なハンドオフで締めくくる:
- 直接実装する準備ができている
- まずアーキテクチャレビューが必要
- まず製品の明確化が必要
有用な場合は、次の ECC ネイティブレーンを指摘する:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
出力フォーマット
結果を以下の順序で返します:
CAPABILITY
- 1 段落の再定義
CONSTRAINTS
- 固定ルール、不変条件、境界
IMPLEMENTATION CONTRACT
- アクター
- サーフェス
- ステートと遷移
- インターフェース/データの含意
NON-GOALS
- このレーンが明示的に所有しないもの
OPEN QUESTIONS
- まだ必要なブロッカーまたは製品判断
HANDOFF
- 次に何が起こるべきか、どの ECC レーンが引き継ぐべきか
良い成果
- PR の途中で隠れた制約を再発見することなく実装できるほど、製品の意図が具体的になっている
- エンジニアリングレビューが記憶や Slack コンテキストに頼るのではなく、永続的なアーティファクトを持っている
- 結果のプランが Claude Code、Codex、Cursor、OpenCode、ECC 2.0 計画サーフェス全体で再利用可能である
