ops-yolo

ランタイムコンテキスト

YOLO 分析の前に、以下を読み込みます。

1. 設定：cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — owner、timezone、yolo_enabled、すべてのチャンネル設定を読み込みます
2. デーモンの健全性：cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — 包括的な分析には、すべてのサービスが正常である必要があります
3. シークレット：すべてのキーを環境変数 → Doppler → パスワードマネージャーの順に解決します：GITHUB_TOKEN、SENTRY_AUTH_TOKEN、LINEAR_API_KEY、AWS_ACCESS_KEY_ID
4. Ops メモリ：${CLAUDE_PLUGIN_DATA_DIR}/memories/ 内のすべてのファイルを読み込みます — 連絡先プロフィール、設定、トピック、禁止事項。YOLO エージェントには最大限のコンテキストが必要です。

OPS ► YOLO モード

CLI/API リファレンス

aws CLI（Cost Explorer）

コマンド	用途	出力
aws ce get-cost-and-usage --time-period Start=<YYYY-MM-DD>,End=<YYYY-MM-DD> --granularity MONTHLY --metrics "UnblendedCost" --output json	今月の支出	コスト JSON

gh CLI（GitHub）

コマンド	用途	出力
gh pr list --repo <owner/repo> --json number,title,statusCheckRollup,reviewDecision,mergeable,isDraft	ステータス付きのオープン PR	JSON 配列
gh pr merge <n> --repo <repo> --squash --admin	PR をスカッシュマージ	マージ結果
gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt	最近の CI 実行	JSON 配列

---

Agent Teams のサポート

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が設定されている場合、C-suite 分析（フェーズ 2）では、ファイア・アンド・フォーゲット方式のサブエージェントの代わりに Agent Teams を使用します。これにより、次のことが可能になります。

• エージェントが分析中に調査結果を共有できます（CEO が収益の障害を発見 → CFO が ROI に反映）
• 初期の調査結果によって優先順位が変わった場合、エージェントに指示できます
• エージェントが合意に基づく提案をまとめられます

チームのセットアップ（フラグが有効な場合のみ）：

TeamCreate("yolo-csuite")
Agent(team_name="yolo-csuite", name="ceo", subagent_type="ops:yolo-ceo", ...)
Agent(team_name="yolo-csuite", name="cto", subagent_type="ops:yolo-cto", ...)
Agent(team_name="yolo-csuite", name="cfo", subagent_type="ops:yolo-cfo", ...)
Agent(team_name="yolo-csuite", name="coo", subagent_type="ops:yolo-coo", ...)

初期分析の後、SendMessage(to="cto", content="CFO flagged $400/mo in waste — does this change your tech-debt ranking?") などを使用して、ピアエージェント間で調査結果を共有します。メインの /ops:yolo オーケストレーター（このスキル）は、4 つすべての分析ファイル（ceo-analysis.md、cto-analysis.md、cfo-analysis.md、coo-analysis.md）を読み込み、統合して「厳しい現実」レポートを作成します。yolo-ceo は並列で動作するピアであり、統合役ではありません。

フラグが設定されていない場合は、標準の並列サブエージェント（ファイア・アンド・フォーゲット方式、中断中の指示なし）にフォールバックします。

フェーズ 1 — すべてのデータを事前に収集

以下をすべて同時に実行します。

${CLAUDE_PLUGIN_ROOT}/bin/ops-infra 2>/dev/null || echo '{}'

${CLAUDE_PLUGIN_ROOT}/bin/ops-git 2>/dev/null || echo '[]'

${CLAUDE_PLUGIN_ROOT}/bin/ops-prs 2>/dev/null || echo '[]'

${CLAUDE_PLUGIN_ROOT}/bin/ops-ci 2>/dev/null || echo '[]'

${CLAUDE_PLUGIN_ROOT}/bin/ops-unread 2>/dev/null || echo '{}'

aws ce get-cost-and-usage --time-period "Start=$(date +%Y-%m-01),End=$(date +%Y-%m-%d)" --granularity MONTHLY --metrics "UnblendedCost" --output json 2>/dev/null || echo '{}'

cat "${CLAUDE_PLUGIN_ROOT}/scripts/registry.json" 2>/dev/null || echo '{}'

${CLAUDE_PLUGIN_ROOT}/bin/ops-external 2>/dev/null || echo '[]'

for d in $(jq -r '.projects[] | select(.gsd == true) | .paths[]' "${CLAUDE_PLUGIN_ROOT}/scripts/registry.json" 2>/dev/null); do
  expanded="${d/#\~/$HOME}"
  [ -f "$expanded/.planning/STATE.md" ] && echo "=== $(basename $expanded) ===" && cat "$expanded/.planning/STATE.md" && echo "---"
done

---

フェーズ 2 — C-suite エージェント 4 つを並列で起動

事前に収集したすべてのデータをコンテキストとして使用し、以下の 4 つのエージェントを同時に起動します。それぞれが分析を /tmp/yolo-[session]/ 内のファイルに書き込みます。

エージェント 1 — CEO（戦略）

agents/yolo-ceo.md を使用します。/tmp/yolo-[session]/ceo-analysis.md に書き込みます。

• 現在、成長を妨げている最大の要因は何ですか？
• 正しいものを構築していますか？
• 価値を生み出すのではなく、時間を浪費しているのはどこですか？
• 今日、投資家に率直に何を伝えますか？

エージェント 2 — CTO（技術）

agents/yolo-cto.md を使用します。/tmp/yolo-[session]/cto-analysis.md に書き込みます。

• 致命的な問題になりかねない、最悪の技術的負債は何ですか？
• どのサービスが時限爆弾になっていますか？
• チームとアーキテクチャはスケールできる体制になっていますか？
• 省略した対応のうち、今すぐ修正が必要なものは何ですか？

エージェント 3 — CFO（財務）

agents/yolo-cfo.md を使用します。/tmp/yolo-[session]/cfo-analysis.md に書き込みます。

• 実際の資金消費率と資金が尽きるまでの期間
• 無駄になっている AWS サービスはどれですか？
• 何も変わらなければ、いつ資金がゼロになりますか？
• 現在の作業の ROI はどれくらいですか？

エージェント 4 — COO（オペレーション）

agents/yolo-coo.md を使用します。/tmp/yolo-[session]/coo-analysis.md に書き込みます。

• 現在、見落とされていることは何ですか？
• どのプロセスが機能していませんか？
• 今週、最も大きな実行リスクは何ですか？
• 自動化されていないもののうち、自動化すべきなのは何ですか？

フェーズ 3 — 厳しい現実のレポート（オーケストレーターによる統合）

このスキル（メインオーケストレーター）が統合役です。yolo-ceo ではありません。4 つの並列エージェントがすべて完了し、それぞれの分析ファイルを /tmp/yolo-[session]/{ceo,cto,cfo,coo}-analysis.md に書き込んだら、メインコンテキストで 4 つのファイルをすべて読み込み、統合レポートにまとめます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 YOLO ► HARD TRUTHS REPORT — [date]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 CEO: [1-2 brutal strategic truths]

 CTO: [1-2 brutal technical truths]

 CFO: [1-2 brutal financial truths]

 COO: [1-2 brutal operational truths]

──────────────────────────────────────────────────────
 CONSENSUS: The #1 thing that matters today is:
 [single most important action, no sugar-coating]
──────────────────────────────────────────────────────

 Full analysis files saved to:
 /tmp/yolo-[session]/ceo-analysis.md
 /tmp/yolo-[session]/cto-analysis.md
 /tmp/yolo-[session]/cfo-analysis.md
 /tmp/yolo-[session]/coo-analysis.md

──────────────────────────────────────────────────────
 Type YOLO to hand over the controls.
 I'll run your business autonomously for the next day.
 This means: closing inbox, merging ready PRs,
 fixing fires, advancing GSD phases, triaging issues.

 Or pick an analysis to read:
──────────────────────────────────────────────────────

AskUserQuestion の呼び出しは分割して行います（オプションは最大 4 つ）。

AskUserQuestion の呼び出し 1：

  [Read CEO analysis]
  [Read CTO analysis]
  [Read CFO analysis]
  [More...]

AskUserQuestion の呼び出し 2（「More...」が選択された場合のみ）：

  [Read COO analysis]
  [Execute top recommendation now]
  [Type YOLO to go autonomous]

---

フェーズ 4 — YOLO 自律モード

ユーザーが YOLO（すべて大文字）と入力した場合は、/loop で自律モードに入ります。

開始する前に、AskUserQuestion を使用して対象範囲を確認します。

YOLO mode will autonomously execute these steps:
  1. Inbox — reply to humans, archive automated
  2. Fires — fix CRITICAL/HIGH production issues
  3. PRs — merge ready PRs (CI green, approved)
  4. Triage — auto-resolve confirmed-fixed issues
  5. GSD — advance highest-priority phase
  6. Linear — sync sprint board
  7. Deploy — trigger pending deploys
  8. Report — summary

  [Run all 8 steps]  [Pick which steps to run]  [Cancel]

ユーザーが「Pick which steps」を選んだ場合は、分割した AskUserQuestion の呼び出し（オプションは最大 4 つ）でステップを multiSelect として表示します。

呼び出し 1：[Inbox]、[Fires]、[PRs]、[More steps...] 呼び出し 2（「More steps...」が選択された場合）：[Triage]、[GSD]、[Linear]、[More steps...] 呼び出し 3（「More steps...」が選択された場合）：[Deploy]、[Report]、[Done selecting]

選択されたステップを順番に実行し、各ステップの後に報告します。

ステップごとの確認（破壊的な操作の前に毎回 AskUserQuestion を使用します）。

• Inbox：返信案を表示し、メッセージを送信する前に [Send all N replies] / [Review each one] / [Skip inbox] を尋ねます
• Fires：提案する修正内容を表示し、エージェントをディスパッチする前に [Dispatch fix agent] / [Skip] を尋ねます
• PRs：PR の一覧を表示し、マージする前に [Merge all N ready PRs] / [Pick which ones] / [Skip] を尋ねます
• Triage：クローズする課題を表示し、クローズする前に [Auto-resolve all N confirmed-fixed] / [Review each] / [Skip] を尋ねます
• Deploy：保留中のデプロイを表示し、実行を開始する前に [Deploy all] / [Pick which] / [Skip] を尋ねます
• インフラストラクチャの変更：破壊的なインフラ操作（ALB の削除、RDS の停止、Multi-AZ の無効化、イメージの削除など）については、必ず操作内容を C-suite レポートの情報とともに提示し、個別に [Execute] / [Skip] を尋ねます。破壊的なインフラ操作をまとめて実行してはいけません。

レポートに基づく実行：ユーザーが「Hard Truths」レポートの推奨事項の実行を承認した場合：

1. C-suite の分析ファイルをすべて読み込みます（/tmp/yolo-[session]/*.md）。
2. ⚠️ REQUIRES CONFIRMATION と記された、具体的で実行可能な項目を抽出します。
3. 実行する正確なコマンド、想定される結果、出典レポート（CTO／CFO／COO）とともに、各操作を個別に AskUserQuestion で提示します。
4. 操作ごとに明示的な承認を得てから実行します。
5. 各操作の後に結果を確認し、次の操作に進む前にユーザーへ報告します。

各ステップの後、次に進む前に新たな火急の問題が発生していないか確認します。 完了したら、最終的な概要を報告します。

$ARGUMENTS が analyze または空の場合は、フェーズ 1 に進みます。 $ARGUMENTS が YOLO の場合は、フェーズ 4 に進みます。 $ARGUMENTS が report の場合は、フェーズ 3 に進みます（既存の分析ファイルがあれば読み込みます）。

---

ネイティブツールの使用

Tasks — 進捗の追跡

フェーズ 4 の開始時に TaskCreate を使用して、YOLO の各ステップのタスクを作成します。各ステップが完了するたびに TaskUpdate で更新します。これにより、自律実行中の進捗をユーザーがリアルタイムで確認できます。

PlanMode — 自律実行前の確認

フェーズ 4 の実行前に EnterPlanMode を使用して、実行計画全体を提示します。ユーザーは YOLO の実行内容を確認して承認または変更し、その後 ExitPlanMode で実行を開始します。

Cron — YOLO の毎日実行をスケジュール

フェーズ 4 の完了後、AskUserQuestion を使って YOLO の定期実行をスケジュールするかどうかを確認します。

  [Schedule daily YOLO at 9am]  [Schedule weekly Monday briefing]  [No schedule]

選択された場合は CronCreate を使用します。既存のスケジュールを管理するには CronList／CronDelete を使用します。

Monitor — CI／デプロイのリアルタイム監視

YOLO が修正エージェントをディスパッチしたり、デプロイを開始したりする場合は、sleep ループでポーリングする代わりに Monitor を使用して CI の出力をリアルタイムでストリーミングします。

WebFetch／WebSearch — 情報の補足

MCP が利用できない場合は、WebFetch を使用して Grafana ダッシュボード、Sentry のイベント詳細、または AWS のステータスページを取得します。WebSearch を使用して、本番環境のエラーに関する情報（例：既知の AWS 障害）を検索します。