bad（坏） Skills下载安装命令和教程

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手，先确认命令和权限，再让它执行。

请帮我安装这个 Agent Skill：bad（坏）
来源仓库：https://github.com/stephenleo/bmad-autonomous-development
仓库路径：skills/bad
安装命令：
npx skills add https://github.com/stephenleo/bmad-autonomous-development --skill bad
安装前请先检查当前环境是否支持对应 CLI，并向我确认将要执行的命令、安装目录、联网范围和文件读写权限；确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill；本站只展示命令，不托管安装包，也不自动执行。

skills.shnpx skills

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

简介

bad 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

它是 BMad Autonomous Development 框架的一部分，负责检查项目配置并完成模块注册流程。
激活时会读取 _bmad/config.yaml 文件，若缺失则加载 assets/module-setup.md 完成初始化。
安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。
可通过来源仓库和原始 README 继续核验配置结构和子代理调用机制。

SKILL.md

BAD — BMad Autonomous Development

On Activation

Check if {project-root}/_bmad/config.yaml contains a bad section. If not — or if the user passed setup or configure as an argument — load ./assets/module-setup.md and complete registration before proceeding.

The setup/configure argument always triggers ./assets/module-setup.md, even if the module is already registered (for reconfiguration).

After setup completes (or if config already exists), load the bad config and continue to Startup below.

You are a coordinator. You delegate every step to subagents via the Agent tool. You never read files, run git/gh commands, or write to disk yourself.

Coordinator-only responsibilities:

Pick stories from subagent-reported data
Call the Agent tool to spawn subagents (in parallel where allowed — multiple Agent tool calls in one message)
Manage timers (CronCreate / CronDelete)
Run Pre-Continuation Checks (requires session stdin JSON — coordinator only)
Handle user input, print summaries, and send channel notifications

Everything else — file reads, git operations, gh commands, disk writes — happens inside Agent tool subagents with fresh context windows.

Startup: Capture Channel Context

Before doing anything else, determine how to send notifications:

Check for a connected channel — look at the current conversation context:

- If you see a <channel source="telegram" chat_id="..."...> tag, save NOTIFY_CHAT_ID and NOTIFY_SOURCE="telegram". - If another channel type is connected, save its equivalent identifier. - If no channel is connected, set NOTIFY_SOURCE="terminal".

Send the BAD started notification using the Notify Pattern: 🤖 BAD started — building dependency graph...

Then proceed to Phase 0.

Configuration

Load base values from the bad section of _bmad/config.yaml at startup. Then parse any KEY=VALUE overrides from arguments passed to /bad — args win over config. For any variable not in config or args, use the default below.

Variable	Config Key	Default	Description
`MAX_PARALLEL_STORIES`	`max_parallel_stories`	`3`	Max stories to run in a single batch
`WORKTREE_BASE_PATH`	`worktree_base_path`	`.worktrees`	Root directory for git worktrees
`MODEL_STANDARD`	`model_standard`	`sonnet`	Model for all subagents except Step 5 (code review): Phase 0, Phase 1 Epic-Start, Steps 1–4 and 6–7, Phase 3 (merge + cleanup), Phase 4 (assessment + retrospective)
`MODEL_QUALITY`	`model_quality`	`opus`	Model for Step 5 (code review)
`RETRO_TIMER_SECONDS`	`retro_timer_seconds`	`600`	Auto-retrospective countdown after epic completion (10 min)
`WAIT_TIMER_SECONDS`	`wait_timer_seconds`	`3600`	Post-batch wait before re-checking PR status (1 hr)
`CONTEXT_COMPACTION_THRESHOLD`	`context_compaction_threshold`	`80`	Context window % at which to compact/summarise context
`STALE_TIMEOUT_MINUTES`	`stale_timeout_minutes`	`60`	Minutes of subagent inactivity before watchdog alerts (0 = disabled)
`TIMER_SUPPORT`	`timer_support`	`true`	When `true`, use native platform timers; when `false`, use prompt-based continuation
`MONITOR_SUPPORT`	`monitor_support`	`true`	When `true`, use the Monitor tool for CI and PR-merge polling; when `false`, fall back to manual polling loops (required for Bedrock/Vertex/Foundry)
`API_FIVE_HOUR_THRESHOLD`	`api_five_hour_threshold`	`80`	(Claude Code) 5-hour rate limit % that triggers a pause
`API_SEVEN_DAY_THRESHOLD`	`api_seven_day_threshold`	`95`	(Claude Code) 7-day rate limit % that triggers a pause
`API_USAGE_THRESHOLD`	`api_usage_threshold`	`80`	(Other harnesses) Generic API usage % that triggers a pause
`RUN_CI_LOCALLY`	`run_ci_locally`	`false`	When `true`, skip GitHub Actions and always run the local CI fallback
`AUTO_PR_MERGE`	`auto_pr_merge`	`false`	When `true`, auto-merge batch PRs sequentially (lowest → highest) before Phase 4

After resolving all values, print the active configuration so the user can confirm before Phase 0 begins:

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

Pipeline

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: Build or Update the Dependency Graph

Before spawning the subagent, create the full initial task list using TaskCreate so the user can see the complete pipeline at a glance. Mark Phase 0 in_progress; all others start as []. Apply the Phase 3 rule at creation time:

[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

Call the Agent tool with model: MODEL_STANDARD, description: "Phase 0: dependency graph", and this prompt. The coordinator waits for the report.

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

The coordinator uses the report to drive Phase 1. No coordinator-side file reads.

📣 Notify after Phase 0:

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

After Phase 0 completes, rebuild the task list in correct execution order — tasks display in creation order, so delete and re-add to ensure Phase 2 story tasks appear before Phase 3 and Phase 4:

Mark Phase 0: Dependency graph → completed
Mark Phase 1: Story selection → completed (already done)
Delete all nine generic startup tasks: the seven Phase 2: Step N tasks, Phase 3: Auto-merge, and Phase 4: Batch summary + continuation
Re-add in execution order using 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

Update each story step task to in_progress when its subagent is spawned, and completed (or failed) when it reports back. Update Phase 3 and Phase 4 tasks similarly as they execute.

Phase 1: Discover Stories

Pure coordinator logic — no file reads, no tool calls.

From Phase 0's ready_stories report, select at most MAX_PARALLEL_STORIES stories.

- Epic ordering is strictly enforced: only pick stories from the lowest incomplete epic. Never pick a story from epic N if any story in epic N-1 (or earlier) is not yet merged — check this against the Phase 0 report.

If no stories are ready → report to the user which stories are blocked (from Phase 0 warnings), then jump to Phase 4, Step 3 (Gate & Continue).
Epic transition detection: Compare the selected stories' epic to CURRENT_EPIC (a coordinator variable, initially unset).

- If CURRENT_EPIC is unset or the selected stories belong to a different epic → update CURRENT_EPIC and run Epic-Start Test Design (below) as a blocking subagent before Phase 2 begins. - Otherwise → proceed directly to Phase 2.

Why epic ordering matters: Stories in later epics build on earlier epics' code and product foundation. Starting epic 3 while epic 2 has open PRs risks merge conflicts and building on code that may still change.

Epic-Start Test Design (`MODEL_STANDARD`)

Spawn before Phase 2 when starting a new epic (blocking — wait for completion before story pipelines begin):

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.

Phase 2: Run the Pipeline

Launch all stories' Step 1 subagents in a single message (parallel). Each story's steps are strictly sequential — do not spawn step N+1 until step N reports success.

Skip steps based on story status (from Phase 0 report):

Status	Start from	Skip
`backlog`	Step 1	nothing
`ready-for-dev`	Step 2	Step 1
`atdd-done`	Step 3	Steps 1–2
`in-progress`	Step 3	Steps 1–2
`review`	Step 4	Steps 1–3
`done`	—	all

After each step — mandatory gate (never skip, even with parallel stories): 📣 Notify the step result (formats below), then run Pre-Continuation Checks (references/coordinator/gate-pre-continuation.md). Only after all checks pass → spawn the next subagent.

📣 Notify per step as each step completes:

Success: ✅ Story {number}: Step {N} — {step name}
Failure: ❌ Story {number}: Step {N} — {step name} failed — {brief error}

Step names: Step 1 — Create, Step 2 — ATDD, Step 3 — Develop, Step 4 — Test review, Step 5 — Code review, Step 6 — PR + CI, Step 7 — PR review.

On failure: stop that story's pipeline. Report step, story, and error. Other stories continue. Exception: rate/usage limit failures → run Pre-Continuation Checks (which auto-pauses until reset) then retry.

Hung subagents: when MONITOR_SUPPORT=true and the activity log hook is installed (Step 4 of setup), use the Watchdog Pattern when spawning Steps 2, 3, 4, and 5 to detect stale agents.