bad

Name: bad
Author: stephenleo

github.com/stephenleoエージェントワークフロー107267 回インストール27 週間前に更新

リポジトリ

bad について

BAD は、サブエージェントを通じて BMad の自律開発フローを調整するエージェントスキルです。依存関係の分析、ストーリー開発、レビュー、PR 処理を、状態と段階の順序に沿って進め、対象ストーリーは並行処理します。

主な機能

01サブエージェントによる開発工程の調整
02ストーリー依存グラフの構築と更新
03段階順に沿ったストーリー進行
04対象ストーリーの並行実行
05PR、CI、マージ状態の追跡

活用シーン

01複数ストーリーの開発とレビューを調整
02依存関係に基づく着手可能なストーリーの選定
03エピック開始時のテスト設計
04バッチの PR、CI、継続処理の追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/stephenleo/bmad-autonomous-development --skill bad

インストール後、Claude Code で/badを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/

bad-statusline.sh

module-help.csv

module-setup.md

module.yaml

references/coordinator/

gate-pre-continuation.md

pattern-gh-curl-fallback.md

pattern-monitor.md

pattern-notify.md

pattern-timer.md

pattern-watchdog.md

setup-statusline-hook.md

references/subagents/

phase0-graph.md

phase0-prompt.md

phase3-cleanup.md

phase3-merge.md

phase4-assessment.md

step6-ci-fallback.md

scripts/

merge-config.py

merge-help-csv.py

setup-activity-hook.py

詳細

BAD — BMad 自律開発

アクティベーション時

{project-root}/_bmad/config.yaml に bad セクションが含まれているか確認します。含まれていない場合、またはユーザーが引数として setup か configure を渡した場合は、続行する前に ./assets/module-setup.md を読み込み、登録を完了します。

モジュールがすでに登録されている場合でも、再設定のため、setup／configure 引数があれば常に ./assets/module-setup.md を読み込みます。

セットアップの完了後（または設定がすでに存在する場合）は、bad 設定を読み込み、以下の「起動」に進みます。

あなたはコーディネーターです。すべての手順をAgent ツール経由でサブエージェントに委任します。自分でファイルを読んだり、git／gh コマンドを実行したり、ディスクに書き込んだりすることはありません。

コーディネーターのみが担当する責務：

サブエージェントから報告されたデータをもとにストーリーを選ぶ
Agent ツールを呼び出してサブエージェントを起動する（許可されている場合は並列実行し、1 つのメッセージで複数の Agent ツールを呼び出す）
タイマーを管理する（CronCreate／CronDelete）
継続前チェックを実行する（セッションの stdin JSON が必要。コーディネーターのみが実行）
ユーザー入力への対応、要約の表示、チャンネル通知の送信

それ以外のすべて（ファイルの読み取り、git 操作、gh コマンド、ディスクへの書き込み）は、新しいコンテキストウィンドウを持つ Agent ツールのサブエージェント内で行います。

起動：チャンネルのコンテキストを取得する

何かを始める前に、通知の送信方法を確認します。

接続されているチャンネルを確認する — 現在の会話コンテキストを確認します。
- <channel source="telegram" chat_id="..." ...> タグが表示される場合は、NOTIFY_CHAT_ID と NOTIFY_SOURCE="telegram" を保存します。
- ほかの種類のチャンネルが接続されている場合は、同等の識別子を保存します。
- チャンネルが接続されていない場合は、NOTIFY_SOURCE="terminal" を設定します。
通知パターン（references/coordinator/pattern-notify.md）に従って、BAD 開始通知を送信します。
```
🤖 BAD started — building dependency graph...
```

その後、フェーズ 0 に進みます。

設定

起動時に _bmad/config.yaml の bad セクションから基本値を読み込みます。その後、/bad に渡された引数から KEY=VALUE 形式のオーバーライドを解析します。引数の値は設定値より優先されます。設定にも引数にもない変数には、以下のデフォルト値を使用します。

変数	設定キー	デフォルト	説明
`MAX_PARALLEL_STORIES`	`max_parallel_stories`	`3`	1つのバッチで実行するストーリーの最大数
`WORKTREE_BASE_PATH`	`worktree_base_path`	`.worktrees`	Git ワークツリーのルートディレクトリ
`MODEL_STANDARD`	`model_standard`	`sonnet`	ステップ 5（コードレビュー）を除くすべてのサブエージェントで使用するモデル：Phase 0、Phase 1 のエピック開始、ステップ 1～4 および 6～7、Phase 3（マージとクリーンアップ）、Phase 4（評価と振り返り）
`MODEL_QUALITY`	`model_quality`	`opus`	ステップ 5（コードレビュー）で使用するモデル
`RETRO_TIMER_SECONDS`	`retro_timer_seconds`	`600`	エピック完了後の自動振り返りカウントダウン（10 分）
`WAIT_TIMER_SECONDS`	`wait_timer_seconds`	`3600`	バッチ後、PR のステータスを再確認するまでの待機時間（1 時間）
`CONTEXT_COMPACTION_THRESHOLD`	`context_compaction_threshold`	`80`	コンテキストを圧縮／要約するコンテキストウィンドウの割合
`STALE_TIMEOUT_MINUTES`	`stale_timeout_minutes`	`60`	ウォッチドッグがアラートを出すまでのサブエージェントの非アクティブ時間（分）（0 = 無効）
`TIMER_SUPPORT`	`timer_support`	`true`	`true` の場合はプラットフォーム標準のタイマーを使用し、`false` の場合はプロンプトベースの継続処理を使用します
`MONITOR_SUPPORT`	`monitor_support`	`true`	`true` の場合は CI と PR マージのポーリングに Monitor ツールを使用し、`false` の場合は手動ポーリングループに切り替えます（Bedrock／Vertex／Foundry では必須）
`API_FIVE_HOUR_THRESHOLD`	`api_five_hour_threshold`	`80`	（Claude Code）一時停止を発動する 5 時間のレート制限の割合
`API_SEVEN_DAY_THRESHOLD`	`api_seven_day_threshold`	`95`	（Claude Code）一時停止を発動する 7 日間のレート制限の割合
`API_USAGE_THRESHOLD`	`api_usage_threshold`	`80`	（その他のハーネス）一時停止を発動する汎用 API 使用率
`RUN_CI_LOCALLY`	`run_ci_locally`	`false`	`true` の場合は GitHub Actions をスキップし、常にローカル CI にフォールバックします
`AUTO_PR_MERGE`	`auto_pr_merge`	`false`	`true` の場合は Phase 4 の前に、バッチ PR を順番に（最小から最大の順に）自動マージします

すべての値を確定したら、ユーザーが Phase 0 の開始前に確認できるよう、現在の設定を出力します。

⚙️ BAD config: MAX_PARALLEL_STORIES=3, RUN_CI_LOCALLY=false, AUTO_PR_MERGE=false, MODEL_STANDARD=sonnet, MODEL_QUALITY=opus, TIMER_SUPPORT=true, ...

パイプライン

Phase 0: Build (or update) dependency graph  [subagent]
           └─ bmad-help maps story dependencies
           └─ GitHub updates PR merge status per story
           └─ git pull origin main
           └─ Reports: ready stories, epic completion status
  │
Phase 1: Discover stories  [coordinator logic]
           └─ Pick up to MAX_PARALLEL_STORIES from Phase 0 report
           └─ If new epic → Epic-Start Test Design [subagent, blocking]
           └─ If none ready → skip to Phase 4
  │
Phase 2: Run the pipeline  [subagents — stories parallel, steps sequential]
  ├─► Story A ──► Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
  ├─► Story B ──► Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
  └─► Story C ──► Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
  │
Phase 3: Auto-Merge Batch PRs  [subagents — sequential]
           └─ One subagent per story (lowest → highest story number)
           └─ Cleanup subagent for branch safety + git pull
  │
Phase 4: Batch Completion & Continuation
           └─ Print batch summary  [coordinator]
           └─ Epic completion check  [subagent]
           └─ Optional retrospective  [subagent]
           └─ Gate & Continue (WAIT_TIMER timer) → Phase 0 → Phase 1

Phase 0：依存関係グラフの作成または更新

サブエージェントを起動する前に、TaskCreate を使用して初期タスクリスト全体を作成し、ユーザーがパイプライン全体をひと目で確認できるようにします。Phase 0 を in_progress に設定し、その他はすべて [ ] のままにします。作成時に Phase 3 のルールを適用します。

[in_progress] Phase 0: Dependency graph
[ ] Phase 1: Story selection
[ ] Phase 2: Step 1 — Create story
[ ] Phase 2: Step 2 — ATDD
[ ] Phase 2: Step 3 — Develop
[ ] Phase 2: Step 4 — Test review
[ ] Phase 2: Step 5 — Code review
[ ] Phase 2: Step 6 — PR + CI
[ ] Phase 2: Step 7 — PR review
[ ] Phase 3: Auto-merge                                      ← if AUTO_PR_MERGE=true
[completed] Phase 3: Auto-merge — skipped (AUTO_PR_MERGE=false)  ← if AUTO_PR_MERGE=false
[ ] Phase 4: Batch summary + continuation

model: MODEL_STANDARD、description: "Phase 0: dependency graph" を指定してAgent ツールを呼び出し、以下のプロンプトを渡します。コーディネーターはレポートを待ちます。

Read `references/subagents/phase0-prompt.md` and follow its instructions exactly.

コーディネーターはレポートを使用して Phase 1 を進めます。コーディネーター側でファイルを読み取ることはありません。

📣 Phase 0 の後に通知します。

📊 Phase 0 complete
Ready: {N} stories — {comma-separated story numbers}
Blocked: {N} stories (if any)

Phase 0 の完了後、タスクリストを正しい実行順に再構築します。タスクは作成順に表示されるため、Phase 2 のストーリータスクが Phase 3 と Phase 4 より前に表示されるよう、削除してから追加します。

Phase 0: Dependency graph を completed に設定します
Phase 1: Story selection を completed に設定します（すでに完了しています）
9 個の汎用起動タスクをすべて削除します。7 個の Phase 2: Step N タスク、Phase 3: Auto-merge、Phase 4: Batch summary + continuation が対象です
TaskCreate を使用して、実行順に追加します。

[ ] Phase 1: Epic-Start Test Design            ← add once if new epic, before all story tasks
[ ] Phase 2 | Story {N}: Step 1 — Create story ← one set per selected story, all stories first
[ ] Phase 2 | Story {N}: Step 2 — ATDD
[ ] Phase 2 | Story {N}: Step 3 — Develop
[ ] Phase 2 | Story {N}: Step 4 — Test review
[ ] Phase 2 | Story {N}: Step 5 — Code review
[ ] Phase 2 | Story {N}: Step 6 — PR + CI
[ ] Phase 2 | Story {N}: Step 7 — PR review
                                               ← repeat for each story in the batch
[ ] Phase 3: Auto-merge                        ← if AUTO_PR_MERGE=true
[completed] Phase 3: Auto-merge — skipped (AUTO_PR_MERGE=false)  ← if AUTO_PR_MERGE=false
[ ] Phase 4: Batch summary + continuation

サブエージェントの起動時に各ストーリーステップのタスクを in_progress に更新し、結果の報告を受けたら completed（または failed）に更新します。Phase 3 と Phase 4 のタスクも、実行に合わせて同様に更新します。

フェーズ 1：ストーリーの確認

純粋なコーディネーターのロジックです。ファイルの読み込みやツールの呼び出しは行いません。

フェーズ 0 の ready_stories レポートから、最大 MAX_PARALLEL_STORIES 件のストーリーを選択します。
- エピックの順序は厳守してください： 未完了のエピックのうち最も番号が小さいものからのみストーリーを選択します。エピック N-1（またはそれ以前）のストーリーが未マージの状態で、エピック N のストーリーを選択してはいけません。フェーズ 0 のレポートで確認してください。
準備完了のストーリーがない場合 → フェーズ 0 の警告をもとに、ブロックされているストーリーをユーザーに報告し、**フェーズ 4、ステップ 3（ゲートと続行）**に進みます。
エピックの切り替わりを検出： 選択したストーリーのエピックと CURRENT_EPIC（初期状態では未設定のコーディネーター変数）を比較します。
- CURRENT_EPIC が未設定の場合、または選択したストーリーが別のエピックに属する場合 → CURRENT_EPIC を更新し、フェーズ 2 の開始前に、ブロッキングサブエージェントとしてエピック開始時のテスト設計（以下）を実行します。
- それ以外の場合 → フェーズ 2 に直接進みます。

エピックの順序が重要な理由： 後のエピックのストーリーは、前のエピックのコードとプロダクトの基盤を土台にしています。エピック 2 に未処理の PR がある状態でエピック 3 に着手すると、マージコンフリクトが発生したり、変更される可能性のあるコードを前提に開発したりするリスクがあります。

エピック開始時のテスト設計（`MODEL_STANDARD`）

新しいエピックの開始時に、フェーズ 2 の前に起動します（ブロッキング処理です。ストーリーのパイプラインを開始する前に完了を待ちます）。

You are the epic test design agent for {current_epic_name}.
Working directory: {repo_root}. Auto-approve all tool calls (yolo mode).

1. Run /bmad-testarch-test-design for {current_epic_name}.
2. Commit any new test plan files.

Report: success or failure with error details.

フェーズ 2：パイプラインの実行

すべてのストーリーのステップ 1 のサブエージェントを、1 回のメッセージで（並列に）起動します。各ストーリーのステップは厳密に順番どおりに実行します。ステップ N が成功したと報告されるまで、ステップ N+1 を起動してはいけません。

ストーリーのステータスに応じてステップをスキップします（フェーズ 0 のレポートを参照）。

ステータス	開始ステップ	スキップするステップ
`backlog`	ステップ 1	なし
`ready-for-dev`	ステップ 2	ステップ 1
`atdd-done`	ステップ 3	ステップ 1～2
`in-progress`	ステップ 3	ステップ 1～2
`review`	ステップ 4	ステップ 1～3
`done`	—	すべて

各ステップの完了後 — 必須ゲート（ストーリーを並列実行している場合も省略不可）： ステップの結果を通知（以下の形式）してから、続行前チェック（references/coordinator/gate-pre-continuation.md）を実行します。すべてのチェックに合格した後にのみ、次のサブエージェントを起動します。

📣 ステップごとに通知： 各ステップの完了時に、次のように通知します。

成功：✅ Story {number}: Step {N} — {step name}
失敗：❌ Story {number}: Step {N} — {step name} failed — {brief error}

ステップ名：ステップ 1 — 作成、ステップ 2 — ATDD、ステップ 3 — 開発、ステップ 4 — テストレビュー、ステップ 5 — コードレビュー、ステップ 6 — PR + CI、ステップ 7 — PR レビュー。

失敗時： 該当するストーリーのパイプラインを停止します。ステップ、ストーリー、エラーを報告します。他のストーリーは続行します。
例外： レート制限または使用量上限による失敗の場合 → 続行前チェック（リセットまで自動的に一時停止します）を実行してから再試行します。

ハングしたサブエージェント： MONITOR_SUPPORT=true で、アクティビティログフックがインストールされている場合（セットアップのステップ 4）、ステップ 2、3、4、5 の起動時にウォッチドッグパターンを使用して、応答のないエージェントを検出します。