decide
作成者 alirezarezvanidecide は、decision-logger を通じて創業者承認済みの取締役会メモを永続的な会社の記憶として記録します。Knowledge Capture ワークフローで、承認済みの意思決定と生の議事録を切り分けて扱えます。
スコア: 68/100。明確なトリガーがあり、Cレベル向けアドバイザーワークフロー内での役割も具体的です。さらに、承認済みの意思決定をエージェントが汎用プロンプトより少ない推測で記録できるだけの手順説明があります。そのため、掲載対象としては妥当です。一方で、これはより大きなエコシステムを薄く包んだものに近く、外部の `decision-logger` スキルと、ここでは十分に文書化されていないメモの前提形式に依存する点は、ディレクトリ利用者が理解しておくべきです。
- トリガーが明確です。frontmatter と本文で、創業者が承認した取締役会メモを永続的な記憶にする際、`/cs:boardroom` の後に実行するコマンドが `/cs:decide <memo-path>` だと明示されています。
- ワークフロー上の役割が明確です。検討段階と永続的な会社の記憶を分けるゲートとして、承認確認、タイトル、日付、選択した案、判断基準、反対意見、レビュー時点の抽出まで定義しています。
- メモリモデルが実用的です。生の記録と承認済み意思決定を分ける2層の保存モデルにより、未解決の議論を最終決定として扱ってしまうリスクを抑えられます。
- このスキルは別の `decision-logger` スキルと、より広い `/cs:*` ワークフローに依存しています。ただし、このリポジトリパスには、その依存関係のサポートファイル、インストールコマンド、参照資料へのリンクがありません。
- 運用面の説明は主に概念レベルです。承認済みメモ入力の例やスクリプト、記録フィールドの説明を超える具体的な出力例は用意されていません。
decide skillの概要
decideの役割
decideは、承認済みの戦略メモを、後から参照できる会社の記憶として定着させるためのCレベル向けアドバイザースキルです。実務上、/cs:decide <memo-path>は、取締役会のような検討プロセスの後、実行に移る前に使います。創業者が承認したメモが本当に承認済みであることを確認し、意思決定の記録を抽出して、関連するdecision-loggerワークフローへ流します。
このスキルの中心的な仕事は「何を選ぶべきか相談する」ことではありません。「すでに承認した選択を記録し、今後のAIセッションが会社の文脈として扱えるようにする」ことです。
Knowledge Captureワークフローに向いているケース
decide skillは、Claudeやエージェントワークフローを使って、定例の経営会議、戦略レビュー、創業者による意思決定セッションを回しているチームのKnowledge Captureに向いています。特に、次の2つを明確に分けたい場合に有効です。
- 生の議論、反対意見、会議の文字起こし
- 今後の計画に影響させるべき、承認済みの意思決定
この分離は重要です。まだ結論の出ていない議論が、誤って会社の記憶として残ってしまうのを防ぐためです。
主な違い:二層のメモリモデル
上流のスキルでは、decision-loggerが管理する二層モデルが説明されています。
~/.claude/decisions/raw/配下の生の文字起こし~/.claude/decisions/approved/配下の承認済み意思決定
将来の/cs:office-hoursや/cs:founder-mode呼び出しに渡すことが想定されているのは、承認済みの意思決定だけです。そのためdecideは、一般的な「この会議を要約して」というプロンプトよりも保守的です。議論と組織の記憶の間に、明確なゲートを作ります。
decideが適していないケース
decideを、汎用的な意思決定支援アシスタント、ブレインストーミングツール、プロジェクト管理システムとして期待してインストールするべきではありません。このスキルは、すでに取締役会向けメモがあり、承認ステータスがあり、周辺にCレベル向けアドバイザーパイプラインがあることを前提にしています。ワークフローが場当たり的なメモだけで成り立っている場合は、安定した承認プロセスが整うまで、より軽量なメモ作成や要約プロンプトを使うほうが適しています。
decide skillの使い方
decideのインストール前提
GitHubのスキルリポジトリから、次のコマンドでインストールします。
npx skills add alirezarezvani/claude-skills --skill decide
その後、ソースを確認します。
c-level-advisor/c-level-agents/skills/decide/SKILL.md
このスキルが触るファイル範囲はかなり狭く、主な判断材料はSKILL.mdです。提供されているツリー上では、補助スクリプト、参照ファイル、README、リソースフォルダは見当たりません。そのため導入可否は、あなたの環境が周辺のCレベル向けコマンドとdecision-loggerスキルをすでにサポートしているかどうかに大きく左右されます。
decide利用に必要な入力
コマンド形式は次のとおりです。
/cs:decide <memo-path>
入力には、通常/cs:boardroomで作成された取締役会向けメモファイルを指定します。良い入力には、次の要素が含まれているべきです。
- 意思決定のタイトル
- 決定日
- 採用した選択肢
status: APPROVED、または同等の創業者承認マーカー- 成功基準
- 中止基準
- 残しておくべき反対意見
- レビューチェックポイントの日付
「営業を拡大することに決めた」のような弱い入力では不十分です。より良いプロンプトは、たとえば次のようになります。「Use /cs:decide ./memos/2026-02-enterprise-sales.md. Confirm founder approval, extract the chosen option, preserve dissent, and log success criteria, kill criteria, and the Q2 review checkpoint.」
実践的なdecideワークフロー
信頼性の高いdecideワークフローは、次の流れになります。
/cs:boardroomで検討を完了する。- 承認済みメモを安定したパスに保存する。
- メモに、創業者が承認したことが明記されているか確認する。
/cs:decide <memo-path>を実行する。- 承認済みメモリが、生の文字起こし素材とは別に書き込まれたことを確認する。
- 記録された意思決定を、
/cs:executeや将来の計画セッションの文脈として使う。
この手順により、意図しないメモリ汚染を減らせます。decideは、意思決定パイプラインの同じ地点で一貫して使うと、もっとも価値を発揮します。
導入前に読むべきファイル
まずSKILL.mdを読み、特に次のセクションに注目してください。
Pipeline PositionTwo-Layer Memory ModelInputWorkflow
プレビュー上では追加のサポートファイルがないため、主な導入判断ポイントはリポジトリの複雑さではありません。重要なのは適合性です。承認済みメモがあり、スキルが説明しているパスや期待値に合う、長期的に使えるメモリ運用ルールを持っているかどうかを確認してください。
decide skill FAQ
decideは意思決定を支援するスキルですか?
いいえ。decideは承認済みの意思決定を記録するスキルであり、議論そのものを進行するものではありません。通常は/cs:boardroomの後など、意思決定が完了した後に使います。選択肢の生成、リスク分析、アドバイザー間の議論が必要な場合は、先にそれらのワークフローステップを使ってください。
decideは通常のプロンプトと何が違いますか?
通常のプロンプトでもメモを要約することはできます。しかしdecideは、ガバナンス上の境界を組み込んでいます。生の文字起こしは参照資料であり、承認済みの意思決定だけが長期的な記憶になります。この区別こそが、Claudeに「これを覚えて」と頼む代わりにdecide skillを使う主な理由です。
初心者でもdecideを使えますか?
はい。ファイルベースのプロンプトを理解しており、メモが用意できていれば使えます。ただし、より広いc-level-advisorのコマンド構造を使っていない場合、初心者には難しく感じられるかもしれません。decideはパイプラインを前提にしており、decision-loggerを参照するためです。業務上のメモリとして依存する前に、まず1つの承認済みメモで試してください。
decideのインストールや実行を妨げる要因は何ですか?
大きな障害になるのは、周辺スキルの不足、承認ステータスの曖昧さ、構造化されていないメモです。環境から/cs:decideを呼び出せない、メモのパスにアクセスできない、互換性のあるdecision-logger設定がない、といった場合は、意図したメモリ書き込みまで完了しない可能性があります。
decide skillを改善する方法
実行前にdecideへの入力を整える
decideの出力を改善する最短の方法は、メモの内容を明示的にすることです。スキルを呼び出す前に、短い意思決定ヘッダーを追加してください。
Status: APPROVEDDecision: Choose Option BOwner: Founder / CEOSuccess criteria: ...Kill criteria: ...Review checkpoint: ...Dissent to preserve: ...
これにより、エージェントが承認の有無を推測したり、不足している構造を勝手に補ったりする余地を減らせます。
避けるべきよくある失敗
もっとも多い失敗は、議論を意思決定として記録してしまうことです。どの選択肢が採用されたのかがメモに明確に書かれていない限り、文字起こし、未解決のメモ、競合する選択肢を送るのは避けてください。もう1つの失敗は、中止基準を省くことです。中止基準がなければ、将来のレビューで「継続すべきか」「止めるべきか」を判断できません。
また、decideを何でも記憶させるための汎用コマンドとして使うのも避けてください。このスキルの価値は、選別して使うことにあります。
初回出力後に見直す
初回実行後は、記録された意思決定が簡潔で、監査可能で、将来の利用に耐えるものになっているか確認してください。記録が曖昧な場合は、メモを修正し、より明確なフィールドを入れて再実行します。良い長期メモリは、将来のエージェントが次の問いに答えられる状態であるべきです。何を決めたのか、なぜそれを選んだのか、何が起きればその判断が誤りだと分かるのか、いつ見直すべきか。
自社の運用に合わせてdecideを拡張する
チームは、メモテンプレートを標準化し、必須の承認文言を追加し、メモリパスを社内の運用ルールに合わせることで、decide skillを改善できます。リポジトリを保守している場合は、README、承認済みメモの例、検証チェックリスト、decision-loggerの依存関係に関するより明確な注記を追加すると有用です。こうした追加により、decideのインストール判断がしやすくなり、セットアップ時の曖昧さも減らせます。
