Grooms backlogs into parallelizable sprint plans: analyzes beads state, breaks down epics, prioritizes, wires dependencies, adds quality gates, drafts worker prompts.
From conductornpx claudepluginhub ggprompts/my-plugins --plugin conductorThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Transform rough notes into a well-organized, parallelizable backlog with worker-ready prompts.
Add these to your to-dos:
/planner:breakdown skill (Sonnet) for decomposition/prompt-writer:write for each backlog issue (Haiku)Using MCP (preferred):
mcp__beads__stats() # Overview
mcp__beads__ready() # What's unblocked
mcp__beads__blocked() # What's stuck
mcp__beads__list(status="open") # All open work
CLI fallback:
bd stats
bd ready --json
bd blocked --json
bd list --status open --json
Use the /planner:breakdown skill for strategic decomposition of epics.
The skill runs with Sonnet and will:
Using MCP:
# Create epic
mcp__beads__create(
title="Auth System",
issue_type="epic",
priority=1
)
# Add subtasks
mcp__beads__create(title="Design auth flow", issue_type="task")
mcp__beads__create(title="Implement login", issue_type="task")
mcp__beads__create(title="Add tests", issue_type="task")
# Wire dependencies
mcp__beads__dep(issue_id="IMPL-ID", depends_on_id="DESIGN-ID")
mcp__beads__dep(issue_id="TESTS-ID", depends_on_id="IMPL-ID")
For each issue, consider:
Using MCP:
# Set priority (0=critical, 1=high, 2=medium, 3=low, 4=backlog)
mcp__beads__update(issue_id="ID", priority=1)
# Add dependencies (blocker blocks blocked)
mcp__beads__dep(issue_id="BLOCKED-ID", depends_on_id="BLOCKER-ID")
CLI fallback:
bd update ID --priority 1 --json
bd dep add BLOCKED-ID BLOCKER-ID --json
bd label add ID frontend,auth --json
Based on issue characteristics, assign appropriate quality checkpoints. The /conductor:gate-runner (or the one-shot finalize-issue.sh) runs these checkpoints before merging.
| Gate | Purpose | Checkpoint Skill |
|---|---|---|
codex-review | Code review via Codex | /conductor:reviewing-code |
test-runner | Run project tests | /conductor:running-tests |
visual-qa | Visual/UI verification | /conductor:visual-qa |
docs-check | Changelog/docs hygiene | /conductor:docs-check |
Analyze each issue and suggest gates based on:
| Indicator | Suggested Gates |
|---|---|
| Issue Type | |
| Bug fix | codex-review |
| New feature | codex-review, test-runner |
| Refactor | codex-review, test-runner |
| Chore/config | (none or codex-review) |
| Docs only | (none) |
| Epic close | codex-review |
| Files Touched | |
*.test.ts, *.spec.ts | test-runner |
README.md, docs/, *.md | docs-check |
| Labels | |
needs-tests, testing | test-runner |
needs-review, security | codex-review |
needs-docs | docs-check |
IMPORTANT: visual-qa should NOT be assigned as a gate label on work issues.
Visual QA requires:
Instead, the conductor runs visual QA after merging:
# After merge, conductor can run visual-qa directly
/conductor:visual-qa
If an issue truly needs visual verification, add a note in the issue description for the conductor to check post-merge, but don't add gate:visual-qa as a label.
After determining which gates apply, add labels to the work issue:
Using CLI:
# Add one gate
bd label add ISSUE-ID gate:codex-review
# Add multiple gates
bd label add ISSUE-ID gate:codex-review,gate:test-runner,gate:visual-qa,gate:docs-check
Using MCP:
mcp__beads__update(issue_id="ISSUE-ID", labels=["gate:codex-review", "gate:test-runner"])
Docs-check bypass label (explicit, searchable):
bd label add ISSUE-ID no-changelog
When outputting the sprint plan, show suggested gates:
## Issue Analysis
| Issue | Type | Files | Suggested Gates |
|-------|------|-------|-----------------|
| bd-xxx | bug | Terminal.tsx | codex-review, visual-qa |
| bd-yyy | feature | api.js, api.test.js | codex-review, test-runner |
| bd-zzz | docs | README.md | (none) |
**Create these gates?** [y/N]
Always allow the user to:
Would you like to:
1. Create all suggested gates
2. Select gates per issue
3. Skip gate assignment
Use /prompt-writer:write for each backlog issue to craft worker-ready prompts.
The prompt-writer skill runs with Haiku and will:
For batch processing, use /prompt-writer:write-all to process all backlog issues in parallel.
Before presenting the plan, verify prompts are written:
ready = mcp__beads__ready()
missing_prompts = []
for issue in ready:
full = mcp__beads__show(issue_id=issue['id'])
notes = full[0].get('notes', '') if full else ''
if '## prepared.prompt' not in notes and 'prepared.prompt:' not in notes:
missing_prompts.append(issue['id'])
if missing_prompts:
print(f"⚠ {len(missing_prompts)} issues need prompts: {missing_prompts}")
print("Run /prompt-writer:write-all first")
# DO NOT proceed to spawn offer
Only after all prompts are ready, present the organized backlog:
## Wave 1 (Ready Now - All Prompts Written ✓)
| Issue | Priority | Type | Description |
|-------|----------|------|-------------|
| bd-xxx | P1 | bug | Fix login redirect |
| bd-yyy | P2 | feature | Add dark mode toggle |
## Wave 2 (After Wave 1)
| Issue | Blocked By | Description |
|-------|------------|-------------|
| bd-zzz | bd-xxx | Refactor auth flow |
Ready to spawn workers on Wave 1?
| Situation | Action |
|---|---|
| Blocks 3+ issues | Priority 0-1 |
| Quick win (<1hr) | Priority 1-2 |
| User-facing bug | Priority 0-1 |
| Nice-to-have | Priority 3-4 |
| Large feature | Break into epic + subtasks |
If there are few/no ready issues, offer to brainstorm:
"Your backlog is light. Want to brainstorm what needs to be done?"
Then help the user think through:
See the brainstorm skill references for dependency patterns and epic structures.
Start by running mcp__beads__stats() and mcp__beads__ready() to understand the current state.
Do NOT ask "Ready to spawn?" until ALL of these are true:
prepared.prompt in notes ← Most commonly missed!If prompts are missing, run /prompt-writer:write-all first.