product-capability

product-capability の概要

product-capability は、あいまいなプロダクト意図を、実装可能な capability plan に落とし込むための planning-to-spec スキルです。すでに機能のゴールは分かっているものの、開発を始める前に、制約、インターフェース、ライフサイクルルール、データへの影響、未決定事項を整理する必要がある場面で特に役立ちます。

最適な用途: まだ曖昧な PRD

PRD、ロードマップ項目、創業者メモ、プロダクトスレッドはあるが、エンジニアリング上の形がまだ暗黙的なときに product-capability を使ってください。複数サービスにまたがる作業、チーム横断の依存関係、あるいはレビューのたびに「実装前に何が満たされている必要があるのか？」と確認される機能で、特に威力を発揮します。

通常のプロンプトでは足りない点

一般的な「仕様を書いて」というプロンプトと違い、product-capability は永続的な capability 契約を前提にしています。プロダクトの約束と実装上の制約を切り分け、推測で埋めずに未解決の論点を表に出し、チャット履歴に埋もれて終わるのではなく、セッションをまたいで再利用できる成果物を作るのが目的です。

インストールする価値があるケース

レビューのたびに、隠れていた前提を何度も掘り起こすことが多いなら、product-capability install は導入する価値が高いです。一方で、単一ファイルで完結する作業、リスクが低い作業、あるいは既存のアーキテクチャ文書ですでに十分に定義されている作業では、軽いプロンプトのほうが適していて、このスキルの追加価値は小さめです。

product-capability の使い方

ワークスペースにインストールして読み込む

次のコマンドでスキルをインストールします。

npx skills add affaan-m/everything-claude-code --skill product-capability

その後は、まず SKILL.md を開いてください。product-capability usage を使う場合は、リポジトリが想定している永続的なプロダクトコンテキストファイル、特に PRODUCT.md、docs/product/、または program-spec ディレクトリも確認します。存在しない場合は、スキルで参照されるテンプレートのパスを使ってください。

ざっくりした依頼を、強い入力に変える

このスキルは、機能名だけではなく、プロダクト目標とその背景を一緒に与えたときに最もよく働きます。たとえば「チーム共有を追加して」とだけ書くと、抜け落ちる前提が多すぎます。より強い依頼は、例えば次のようになります。「web と API にまたがるチーム共有の capability plan を設計してください。権限、監査イベント、招待のライフサイクル、ワークスペースがダウングレードされたときの挙動も含めてください。」

Requirements Planning における product-capability のおすすめワークフロー

まずプロダクトのステートメントを示し、そのうえで capability の境界、不変条件、前提、未解決の問い、実装への含意を求めます。優れた product-capability guide の出力は、単なる機能一覧ではなく、作業開始前に何が真でなければならないかを明確に述べるものです。依頼がサービスやチームをまたぐ場合は、所有権と契約境界を明示するようスキルに指示してください。

先に読み、あとで自分のリポジトリ向けに拡張する

このリポジトリは意図的に軽量なので、最初に読むべきなのは SKILL.md です。ルールセットと成果物の対象を理解したうえで、サンプルをそのまま写すのではなく、自分のリポジトリに合わせて構成を調整してください。すでに環境内に標準のプロダクト文書の配置先がある場合は、並行した計画ファイルを作らないよう、そのパスに出力を合わせましょう。

product-capability スキルの FAQ

product-capability は PRD 専用ですか？

いいえ。product-capability は、ロードマップ項目、議論メモ、創業者の方向性にも適しています。重要なのは、意図を実装可能な契約に変換するための十分なプロダクトシグナルがあることです。前提を勝手に作らずに制約を定義できることが条件です。

通常のプロンプト作成と何が違うのですか？

通常のプロンプトは、要約や下書きの計画を生成するかもしれません。product-capability はもっと狭い目的に絞られており、エンジニアリング上重要な事実を保ち、未確定事項を明示し、再利用できる成果物を作ることを狙います。そのため、制約の見落としコストが高いときに向いています。

初心者でも使えますか？

はい。機能とその背景を説明できるなら使えます。product-capability を使うのにアーキテクチャの専門知識は必須ではありませんが、分かっている事実はできるだけ正確に渡す必要があります。重要な入力を省くと、出力はそのままではレビューが必要です。

どんなときに使うべきではありませんか？

些細な作業、単独の UI 調整、あるいは詳細な仕様ですでに管理されている作業には product-capability を使わないでください。洗練されたマーケティング文や実装コードがほしいだけなら、Requirements Planning 用の材料としては不向きです。

product-capability スキルを改善する方法

重要な事実を最初に渡す

品質を最も大きく上げるのは、ユーザーから見える挙動、システム境界、既知の制約を最初に明示することです。データフロー、アクセスルール、ロールバック時の期待動作、依存システム、そして実装を変える可能性のあるポリシーやコンプライアンス上の懸念も含めてください。

暗黙にせず、未確定事項を明示する

良い product-capability 入力は、確定済み要件と未解決の質問を分けて書きます。ある処理が同期かどうか、監査ログが必要かどうか、どのサービスが正本を持つのかがまだ決まっていないなら、そのまま明言してください。そうすれば、スキルが不確実性を都合よくならしてしまうのを防げます。

निर्णयに使える成果物を求める

初稿の範囲が広すぎるなら、スキルに対してスコープを絞り、譲れない条件を列挙し、設計判断の障害になるトレードオフを強調するよう依頼してください。こうした反復のほうが、product-capability usage の出力を改善するうえで、あちこちに詳細を追加してもらうより効果的なことが多いです。

同じ capability フレームを再利用する

繰り返し発生するプロダクト業務では、セッションごとに同じ capability 構造を保つと、レビュー担当者が計画を一貫して比較できます。入力がチームの実際の運用モデルに近いほど、product-capability は汎用的な計画文ではなく、実務に役立つガイダンスを返しやすくなります。