ce-strategy について
ce-strategyは、ユーザーへの質問を通じてプロジェクトの `STRATEGY.md` を作成・更新するスキルです。機能案や計画と戦略を分け、既存文書の構成や編集権限に関するルールを保ちます。
主な機能
- 01`STRATEGY.md` の作成と更新
- 02戦略の各項目についての質問
- 03既存文書の構成の維持
- 04関連スキルへの戦略情報の引き継ぎ
活用シーン
- 01対話形式でのプロジェクト戦略の作成
- 02他の内容を変えずに戦略項目を更新
- 03構想や計画スキルへの戦略情報の提供
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ everyinc/ compound-engineering-plugin --skill ce-strategyインストール後、Claude Code で/ce-strategyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/grounding.mdinterview.mdstrategy-template.mdupdate-run.md詳細
プロダクト戦略
現在は2026年です。文書の日付にはこの年を使用してください。
ce-strategy は、STRATEGY.md の担当部分を作成し、維持します。これはリポジトリのルートに置かれるプロジェクト文書で、プロジェクトの内容、対象ユーザー、成功の定義、チームが投資している領域を記録します。このファイルはほかのツールや人とも共有されます。このスキルが作成するのは、references/strategy-template.md に記載されたセクションのみです。後続のスキルは、ファイルが存在する場合、戦略に沿った作業の判断には ce-ideate、ce-brainstorm、ce-plan を、プロダクト名と主要指標には ce-product-pulse を、主要なペルソナには ce-dogfood を使用します。フロントマターのキーと、このスキルのセクション見出しは、これらのスキルが解析する契約です。このスキルが作成するすべてのセクションで維持してください。既存のセクションがすでに持つ意味は、そのセクションに統合します(references/update-run.md)。
完了条件: STRATEGY.md がリポジトリのルートに存在し、ユーザーが書き込まれる内容を確認して編集する機会を得ていること。このスキルの所定の形式のファイルでは、必須セクションすべてに、異論への対応を経た回答(またはリンク先の既存文書に明示的に委ねた内容)が記載され、ファイルが references/strategy-template.md に準拠していること。それ以外の形式のファイルでは、ユーザーが承認した最小限の編集が適用され、文書の形式が維持されていること。2回のやりとりを経てもユーザーが明確化できなかったセクションは、提示された内容のまま記載し、今後見直す価値があるものとしてチャットで伝えます。これは完了した実行であり、ブロックされた実行ではありません。
範囲
- 計画ではなく、拠り所です。 戦略とは、プロダクトの内容とその理由です。機能は
ce-brainstorm、スケジュールと優先順位付けはイシュートラッカー、実装計画はce-planの担当です。それらを文書に持ち込まず、トラッカーを更新したり、進行中の作業を調整したりしないでください。 - 回答するのはユーザーです。リポジトリは質問の根拠にすぎません。 根拠を使って質問をより明確にしてください。セクションの内容を埋めるために使ってはいけません。リポジトリから戦略を導き出さないでください。
- 簡潔さも機能です。 セクションを追加するのではなく、内容の拡張には異議を唱えてください。
- 重要な指標とその保存場所を記録し、現在の数値は記録しないでください。
- 契約となるのは意味であり、形式は文書の作成者に委ねられます。 このスキルだけが作成したファイル(判定基準は
references/update-run.mdに記載)は、書き込むたびに所定の形式で維持します。見出しを変更し、テンプレートの現在の順序に合わせ、必須セクションが欠けていれば追加を提案します。原則としてファイルを共有する場合があるというだけで、複数の作成者がいるファイルとして扱わないでください。手書きでも別のツールで作成されたものでも、それ以外の形式のファイルは、意味を読み取り、元の形式や書き方に合わせて編集します。テンプレートへの再構成や、求められていないフロントマターや見出しの追加はしません。いずれの場合も、編集してはならないものが2つあります。作成者の承認を示すマーカー(例:``)を含むセクションと、ユーザーが所有していない文書です。その場合は競合を報告するか、元の文書にリンクする別ファイルを作成してください。特定のセクションだけを更新する場合、ほかのすべてのセクションの内容をそのまま保持します。セクションの配置順は、同じ所有者判定に従います。単独所有のファイルではテンプレートの順序を使い、複数の作成者がいるファイルでは順序を変更しません。詳細はreferences/update-run.mdに定められており、既存ファイルを編集する前に必ず読んでください。
質問と振り分け
現在のツール一覧にすでにある、ホストの質問をブロックするツールを使って、一度に1つだけ質問してください。機能に基づいて選び、ユーザー向けツールを試して見つけようとしないでください。該当するツールが一覧にない場合、または実際の質問呼び出しでエラーが発生した場合に限り、画面に見えるチャット上で番号付きの選択肢を提示してください。質問を黙って省略してはいけません。
このスキルの呼び出し時に渡された引数は、現在のプロンプトまたは会話のどこに含まれているか、ユーザーから渡されたか呼び出し元のスキルから渡されたかを問わず、すべて焦点のヒントです。これは、見直すべきセクション(metrics、positioning、tracks。旧称の approach や who it's for などは現在のセクションに対応します)または範囲のヒントになります。引数がない場合は、対象を限定せずに進め、ファイルの状態に応じて進め方を決めてください。
フェーズ 0:現状把握と振り分け
フェーズ 0 では、ハーネスが何を読み込むかにかかわらず、リポジトリのモデルと、次に実行するフェーズを決定します。references/grounding.md は必ず読み込んでください。ここには、ソースの完全な一覧、意見の相違について尋ねる質問の文言、焦点に関するヒントが記載されています。
リポジトリのモデルとは、この製品が何であるかについての作業上の理解です。STRATEGY.md があれば読みます。この製品が何であるかは、明示された意図と構成から把握します。README、CONCEPTS.md、docs/、PRODUCT.md などの関連ドキュメント、コードがどのように整理されているかを参照し、リポジトリ全体のプロファイリングではなく、「これは何で、誰を対象としているのか」に絞ります。最近のコミットや PR から、現在注目されている点を把握します。注目されている点が判断材料になるのは Tracks の質問と、更新時の古さの確認に限ります。明示された意図と食い違う場合は、結論を出すのではなく、ユーザーへの質問とします。最初の質問の前に、チャットでモデルを示します。この製品を何と捉えているか、誰を対象としているように見えるか、どこに注目が集まっているかを、情報源をそれぞれ明記して 3~5 行で説明し、訂正を促します。モデルから製品名がわからない場合は、この時点で尋ねます。テンプレートのフロントマターとタイトルに製品名が必要です。実質的な内容のないリポジトリも通常のケースです。その旨を 1 行で伝え、リポジトリの情報に基づかないインタビューを行います。
次のフェーズは、ファイルの状態に応じて 1 行で伝えます。ファイルがない場合はフェーズ 1(「戦略ドキュメントが見つかりません。作成しましょう。」)。該当する場合は references/grounding.md にある既存の関連ファイルの提案を行ってから伝えます。ファイルがある場合はフェーズ 2(「既存の戦略が見つかりました。確認して更新しましょう。」)。
フェーズ 1:初回インタビュー
最初の質問の前に、必ず references/interview.md を読み込みます。冒頭の質問、反論への対応ルール、アンチパターンの例、品質基準、ホストごとのブロッキング質問ツール、2 ラウンドの上限は、すべてここに記載されています。記憶を頼りに即興で進めると、戦略ドキュメントではなく、受け身の書き起こしになってしまいます。
以下の順序でインタビューを進めます(ドキュメント自体はテンプレートの順序に従います。Boundaries の内容はストレステストから導くため、ストレステストの後に尋ねます)。
- 目的
- ポジショニング
- ユーザー
- 主要指標
- Tracks
- ストレステスト
- Boundaries(必ず記載)
- マイルストーン(任意)
- ブランド(任意)
すべてのセクションの内容をまとめたら、references/strategy-template.md を読み込んで記入し、ドラフト全体をチャットに提示します。編集を 1 ラウンド受け付けた後、STRATEGY.md に書き込みます。
フェーズ 2:更新実行
要約、ずれの確認、質問のいずれかを行う前に、必ず references/update-run.md を読み込みます。ずれの候補をどのように提示するか、どのセクションを再検討するか、どの内容を変更せずに残すかは、ここに記載されています。更新実行では、ファイルの現在の状態を 3~5 行で要約し、リポジトリのモデルから古くなっている可能性が示唆されるセクションがあれば、断定ではなく候補として挙げます。その後、焦点のヒントで指定されたセクション、または質問を受けてユーザーが選んだセクションを再検討します。ユーザーは任意のセクションを選べます。ずれの候補は、唯一の選択肢ではなく提案として、まず一覧にします。それ以外のすべてのセクションの内容は変更せず、その位置は references/update-run.md の所有権テストに従います。質問と反論への対応には引き続き references/interview.md を用い、初回実行の場合と同じように適用します。
フェーズ 3:後続処理への引き継ぎ
ファイルの保存場所と、次回実行時に ce-ideate、ce-brainstorm、ce-plan がそれを前提情報として利用することを、1 行で伝えます。ここで後続スキルがまだ実行されていない場合は、次のステップとして ce-ideate または ce-brainstorm を提案します。