execute
作成者 alirezarezvaniexecuteは、承認済みの意思決定レコードを、週次マイルストーン、担当DRI、成功指標、完了条件、チェックイン頻度を備えた90日間の運用計画に変換します。/cs:decideの後に、説明責任のある実行へつなげたいProject Managementやリーダーシップ領域のワークフローに適しています。
このスキルの評価は74/100で、ディレクトリ掲載には十分ですが、導入にはいくつか注意点があります。ディレクトリ利用者は、承認済みの意思決定レコードを90日間の実行計画へ変換する、明確に呼び出せるワークフローを得られます。一方で、スクリプト、例、インストール手順まで整った実装というより、markdownのみの軽量なスキルとして捉えるのが適切です。
- トリガーと用途が明確です。`/cs:execute <decision-path>`は、承認済みの`/cs:decide`レコードを運用計画に変換する目的で明確に位置づけられています。
- 保存先となる実行計画のパス、オーナー、チェックポイント、ワークストリーム、週次マイルストーン、DRI、成功指標、完了条件など、実務に使える具体的な出力が含まれます。
- オフィスアワーから事後検証まで続くCレベルアドバイザーフロー全体の中で、エージェントがこのスキルをいつ使うべきか理解しやすい文脈が用意されています。
- サポートファイル、スクリプト、参考資料、README、インストールコマンドは用意されていないため、導入可否はSKILL.mdの手順に大きく依存します。
- このスキルはリポジトリ全体の`/cs:`意思決定ワークフローに結び付いているように見えるため、事前の`/cs:decide`出力がない場合、単体の計画作成スキルとしては有用性が下がる可能性があります。
execute skillの概要
executeができること
executeは、承認済みの意思決定を90日間の実行計画に落とし込むC-level advisor skillです。戦略上の決定を静的なメモで終わらせるのではなく、execute skillは週次マイルストーン、ワークストリーム、指名されたDRI、成功指標、完了条件、チェックインのリズムまで具体化します。中核となる役割は、「決めた」状態と「次の月曜日に何をするのか」の間にあるギャップを埋めることです。
プロジェクトマネジメントとリーダーシップチームに向いている場面
Project Managementでexecuteが最も力を発揮するのは、創業者、経営チーム、プロダクトリード、またはオペレーションチームがすでに明確な意思決定を行い、その展開に責任を持てる実行計画が必要になったタイミングです。典型的な用途には、市場参入、価格変更、採用計画、プロダクトローンチ、営業プロセスの変更、社内オペレーティングモデルの見直しなどがあります。特に、部門横断のワークストリームがあり、失敗要因がアイデア不足ではなくオーナーシップの曖昧さになりそうな場合に有効です。
execute skillならではの違い
一般的な「プロジェクト計画を作って」というプロンプトと違い、executeは意思決定記録を入力として想定し、その決定で確定した結果を維持します。出力形式も明確に設計されています。90日間の時間軸、週次マイルストーン、DRIの担当、成功基準と中止基準、ワークストリーム、チェックインが含まれます。この構造により、ブレインストーミングや初期の戦略探索よりも、実行規律を高める用途に適しています。
導入前に知っておきたいこと
リポジトリ内のパスはc-level-advisor/c-level-agents/skills/executeで、メインファイルはSKILL.mdです。このskillディレクトリには追加のスクリプト、ルール、リソース、READMEファイルはありません。そのため、価値はプロンプト構造そのものに集約されています。Claude skillsワークフローの中で軽量な実行計画コマンドが欲しい場合はexecuteをインストールするとよいでしょう。一方で、本格的なプロジェクト管理ツール連携や自動タスク同期を期待するものではありません。
execute skillの使い方
executeのインストールと前提
リポジトリからskillをインストールするには、次を実行します。
npx skills add alirezarezvani/claude-skills --skill execute
インストール後は、まずSKILL.mdを確認してください。ここにコマンド、期待される入力、パイプライン上の位置づけ、出力形式が記載されています。上流のskillは次のコマンドを前提に設計されています。
/cs:execute <decision-path>
<decision-path>には、承認済みの意思決定記録を指定します。理想的には、同じC-level advisorワークフロー内で/cs:decideによって作成された記録です。
execute skillに必要な入力
executeを有効に使うには、タイトルだけでは不十分です。責任あるマイルストーンを作るために、skillには十分な意思決定コンテキストが必要です。
- 承認済みの意思決定とその理由
- 確定した結果、成功基準、中止基準
- スポンサーまたは経営上のオーナー
- 関係するチームと想定されるDRI
- 期限、ローンチ時期、または90日後のチェックポイント
- 予算、採用、エンジニアリングキャパシティ、コンプライアンス、依存関係などの既知の制約
- 週次の経営レビューやスプリント計画など、既存のツールや運営リズム
弱い入力例: “Create an execution plan for entering Germany.”
より強い入力例: “Use /cs:execute decisions/2026-02-03-germany-entry.md. Preserve the approved success criteria: €250k qualified pipeline by day 90 and kill criteria: CAC payback above 18 months after pilot. Assume Sales, Marketing, Legal, and Product workstreams. Weekly exec check-in is Mondays. Name placeholder DRIs where people are not assigned.”
おすすめのワークフロー
executeは、チームがまだ選択肢を議論している最中ではなく、意思決定が承認された後に使います。実務では次の流れが扱いやすいです。
- 意思決定記録を作成する、または集める。
- 結果と中止基準が明示されていることを確認する。
/cs:execute <decision-path>を呼び出す。- 生成されたワークストリームと週次マイルストーンを確認する。
- プレースホルダーのDRIを実名に置き換える。
- 必要に応じて、マイルストーンを自社のプロジェクト管理システムへ移す。
- チェックインのリズムを使って、リスクや未達の完了条件を追跡する。
skillのデフォルト出力は、Markdownの実行計画として保存されます。ローカルのClaude skill設定にもよりますが、一般的には~/.claude/execution/YYYY-MM-DD-<slug>.mdのようなパスになります。
出力品質を高めるプロンプトのコツ
運営環境は具体的に伝えてください。チームの定例リズム、キャパシティ、依存関係がすでに分かっているなら、それも含めます。マイルストーンが観測可能である必要がある場合は、その旨を明記します。リーダーシップが特定の指標を重視しているなら、関連する各ワークストリームでその指標が見えるように依頼します。
使いやすいプロンプトの型は次のとおりです。
/cs:execute <decision-path>. Build a 90-day plan with weekly milestones, named DRIs where known, placeholder DRIs where unknown, definitions of done, dependency risks, and a Monday check-in cadence. Keep the binding outcome and kill criteria unchanged from the decision record.
これにより、計画が元の意思決定から逸れていくのを防げます。
execute skillのFAQ
executeは経営層だけのものですか？
いいえ。言葉遣いやパイプラインは経営層向けですが、execute skillは、承認済みの意思決定を責任ある計画に変換する必要があるプロダクトマネージャー、オペレーター、創業者、chiefs of staff、プロジェクトリードにも役立ちます。主な前提は、その意思決定がすでに完了していることです。
executeを使うべきではないのはどんな場合ですか？
自由なアイデア出し、選択肢の比較、市場調査、競合する戦略のどれを選ぶかの判断にはexecuteを使わないでください。明確なオーナーがいない、成功指標がない、DRIを割り当てる意思がない場合にも向いていません。その場合は先に、ブリーフィング、意思決定、または計画策定のプロセスを使うべきです。
通常のプロンプトとexecuteは何が違いますか？
通常のプロンプトでも、それらしいタスクリストは作れます。executeは、意思決定から実行計画へ変換する形を強制します。90日間、ワークストリーム、DRI、週次マイルストーン、完了条件、チェックインのリズムが前提です。この制約こそが価値です。曖昧さを減らし、リーダーシップチームがレビューしやすい成果物にします。
executeはJira、Asana、Linearと連携しますか？
executeのリポジトリ上で確認できる内容はSKILL.mdのみで、補助スクリプトやツール連携はありません。出力は、Jira、Asana、Linear、Notion、スプレッドシートにコピーできる構造化されたMarkdown計画として扱ってください。ツール同期が必要な場合は、そのワークフローを自分で追加する前提になります。
execute skillを改善する方法
実行前にexecuteへの入力を改善する
executeの結果を改善する最短ルートは、意思決定記録を強化することです。実際に何を決めたのか、なぜそれを選んだのか、成功とは何か、どの条件なら撤回するのか、誰がその取り組みのスポンサーなのかを必ず含めてください。曖昧な意思決定からは曖昧な実行計画しか生まれません。測定可能な意思決定があってこそ、有用な週次マイルストーンが作れます。
よくある失敗パターンを確認する
最初の出力後は、次の問題がないか確認してください。
- マイルストーンが成果ではなく作業になっている
- DRIが個人ではなくチームに割り当てられている
- 依存関係のオーナーが抜けている
- 成功指標が元の意思決定と一致していない
- 1週目の作業が大きすぎる、または不明確
- 明示的なレビュー頻度やエスカレーション経路がない
すべてを再生成するのではなく、弱い部分だけをexecuteに修正させるのが効果的です。
現実の運用に近づけて反復する
よい2回目のプロンプトは、見栄えではなく実務性を重視します。
“Revise the plan so each weekly milestone has an observable definition of done, no DRI is a department, Legal dependencies are visible by week, and the week 4 checkpoint can determine whether we continue, adjust, or stop.”
この種の反復は、単に長い計画を求めるよりも、マネジメント上の有用性を大きく高めます。
自社の組織に合わせてexecuteを調整する
executeを頻繁に使うなら、チームが重視する項目を標準化しましょう。たとえば、予算オーナー、リスクレベル、顧客影響、報告会議体、ローンチチェックリスト、エスカレーションのトリガーなどです。90日間の構造は維持しつつ、ワークストリームとチェックインのリズムを自社のオペレーティングモデルに合わせて調整します。そうすることで、executeを汎用的なプロジェクトテンプレートにしてしまうことなく、再現性を高められます。