القائمة
Decompose reviewed plan docs into implementation beads (epics + tasks) with correct dependencies. Reads plan docs, identifies components, and creates properly sized bd tasks.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Schedule yourself to wake up every 5 minutes and shepherd an open PR — fix failing CI, address review-bot comments (push fixes for legit findings, resolve false positives, re-request review once addressed), reply to mechanical human comments with fixes, and flag architecture-level human comments back to the user. Exits the loop when the PR is green and review is clean. NEVER merges the PR.
Verify implemented plan docs against their actual code, add completion signoff metadata, and surface any gaps as new beads. Designed for scheduler/concierge agents coordinating multi-agent signoff after implementation is done.
Orchestrate the full planning lifecycle — from input assessment through architecture, plan writing, review cycles with convergence, and sign-off. Designed for concierge/scheduler agents coordinating multi-agent planning work.
Surgically trim verbosity and within-doc duplication from a plan doc without losing fidelity. Cuts review residue, restated rationale, illustrative code that prose+signature already covers, redundant adjacent sections, and prose-then-table restatements. Preserves all API/interface specs, acceptance criteria, URP/EO/AA commitments, decision rationale where alternatives matter, and review disposition tables. Run after plan-incorporate, before plan-work-completion-signoff.
Clean up a long-running work branch before landing into main — close beads, prune review docs, strip ceremonial comments, undo accidental cross-cutting refactors that weren't part of the task. Run after implementation completes, before opening the PR to main. Specific to the final land into the trunk, NOT for ordinary feature-to-feature merges along the way.
Independently review a plan doc and its test harness. Produces a review findings doc rated P0-P3. Run multiple times with different reviewers for independent perspectives.
| name | plan-to-beads |
| description | Decompose reviewed plan docs into implementation beads (epics + tasks) with correct dependencies. Reads plan docs, identifies components, and creates properly sized bd tasks. |
| user-invocable | true |
| allowed-tools | Bash Read Write Edit Grep Glob Task |
| argument-hint | [scope] [--dry-run] |
Read reviewed plan docs and decompose them into implementation beads (epics + tasks) with correct dependencies and sizing. Designed for concierge/scheduler agents preparing implementation work after the planning cycle is complete.
$0: Scope — one of:
batch3) — decomposes all plan docs in that batch02b-gateway) — decomposes one doc + its addendaall — decomposes the entire plan index$1 (optional): --dry-run — output proposed beads as markdown without creating themdocs/plans/ (or the project's established plans directory)docs/plans/00-implementation-guide.md) does not yet exist, flag this to the orchestrator — the guide should be generated (Phase 4.75 in plan-orchestrate) before bead creation proceeds.Read docs/plans/00-plan-index.md for:
For each plan doc in scope, read:
docs/plans/{id}.md)docs/plans/{id}.add*.md)docs/plans/{id}-test-harness.md)Check for existing beads:
bd list --labels project={project}
If any existing beads overlap with planned tasks, do NOT create duplicates. Instead, report the overlap to the orchestrating agent with both the existing bead ID and the proposed task description, so the orchestrator can decide whether to skip, update, or delete the existing bead.
Build a catalog for each doc:
Apply these decomposition rules to generate implementation tasks from the catalog:
| Plan Doc Section | Typical Decomposition | Rationale |
|---|---|---|
| Types + interfaces package | 1 task (foundation) | Small but everything depends on it |
| Core data structure (e.g., SwissTable, SkipList) | 1 task per structure | Each is self-contained with its own tests |
| Command/API surface | Group related commands into 1-3 tasks | Individual commands are too small alone |
| Protocol/wire layer (parser, writer, connection) | 1 task | Tightly coupled components |
| Engine service (ERC integration, lifecycle) | 1 task | Integrates everything above |
| Test harness framework (oracle, generators, harness setup) | 1 task | Foundation for harness suites |
| Harness test suites | Group into 2-4 tasks by theme | Each suite is moderate-sized |
| Addendum implementation | Usually 1 task per addendum | Addenda are self-contained features |
Within a plan doc's decomposition, identify which tasks are foundational:
These become the first tasks in the dependency chain for that doc.
The plan doc's acceptance criteria become explicit deliverables in implementation beads. The final bead in each vertical slice (typically the integration/wiring bead) must include "acceptance tests pass" as a completion criterion. This means the bead is not done until the acceptance scenarios run successfully against the end-user interface.
When there are N similar implementations (e.g., 6 aggregation operators, 8 engine adapters, 16 harness test suites):
This ensures the pattern is correct before parallelizing the repetitive work.
Build a dependency DAG from three sources:
From the plan index dependency graph. These are already defined — just translate to bead dependencies.
From Phase 2 decomposition. Foundation tasks must complete before dependent tasks.
Addenda may depend on features from the main doc or from other addenda.
After building the DAG:
When uncertain whether two tasks can truly be done in parallel (e.g., they touch adjacent code, similar patterns, or share test infrastructure), err on the side of creating a dependency. Sequential execution is slower but avoids inconsistency and duplication.
If --dry-run is specified, output a markdown document with the proposed beads instead of creating them:
# Proposed Beads: {scope}
## Epic: {epic-name}
### Task 1: {task-name}
- **Description**: {description}
- **Labels**: {labels}
- **Depends on**: {task names}
- **Parallelism group**: {group number}
### Task 2: ...
Send this to the orchestrating agent for approval before proceeding to actual bead creation.
Each primary plan doc gets one epic that contains:
{id}.add01, {id}.add02){id}-test-harness.md)This keeps related work together. Addendum tasks and test harness tasks are child tasks within the same epic as their parent plan doc, with dependencies between them as needed (e.g., harness framework task depends on core implementation tasks; addendum tasks may depend on specific parent doc tasks).
After all epics are created, the orchestrator creates cross-epic dependencies based on the plan index dependency graph (e.g., Gateway epic depends on Cache/KV engine epic).
Every epic MUST include a final "Verification & Signoff" bead:
/plan-work-completion-signoff to verify implemented code matches plan docs/e2e-wiring-review to verify all entry points are reachable end-to-endCreate the epic:
bd create "{component-name} Implementation" --type epic --labels project={project} --description "{scope: main doc + addenda + test harness}"
Create child tasks in dependency order (so parent IDs are available):
bd create "{task-name}" --labels project={project},batch={N},plan-doc={doc-id} --parent {epic-id} --description "{description}"
Add intra-epic dependencies (between tasks within the same epic):
bd dep add {downstream-task-id} {upstream-task-id} --type blocks
Report cross-epic dependencies to the orchestrator — the orchestrator creates these after all epics exist, since task IDs across epics are needed.
Each task description should include:
Implement {what} from {plan-doc-path}.
Sections: {list of plan doc section numbers/names to implement}
Key deliverables:
- {Specific type, interface, or component to implement}
- {Another deliverable}
- Unit tests for all of the above
- {Integration test if applicable}
References:
- Plan: docs/plans/{doc}.md §{sections}
- Test harness: docs/plans/{doc}-test-harness.md §{sections}
- Depends on: {what this builds on}
If docs/plans/00-implementation-guide.md exists, every bead description must include a reference to it as required reading:
Required reading: docs/plans/00-implementation-guide.md
When creating beads and the Implementation Guide exists, check its Interface Contracts and Common Pitfalls sections for anything relevant to the specific bead. If a bead touches a seam listed in the guide's Seam Reference Table, or involves a pattern flagged in Common Pitfalls, note it explicitly in the bead description (e.g., "See Implementation Guide §Common Pitfalls: page cache init must complete before WAL recovery").
If the Implementation Guide does not exist and the project has completed seam review, flag this to the orchestrator — the guide should be generated (Phase 4.75 in plan-orchestrate) before bead creation proceeds. If the project has not gone through seam review (e.g., older plans predating this workflow), proceed without the guide reference.
Descriptions should be detailed enough that an agent unfamiliar with the project can read the plan doc sections and implement the task, but should not duplicate the plan doc content — reference sections instead.
Output a summary to the orchestrating agent:
## Beads Created: {scope}
Epic: {epic-id} — {epic-name}
Tasks: {total-count}
- Ready (no blockers): {count}
- Blocked: {count}
Critical path: {task-names on longest dependency chain} ({length} tasks)
Max parallelism: {max tasks that can run concurrently}
### Existing Bead Overlaps
{List any existing beads that overlap with proposed tasks, if any}
### Dependency Summary
{ASCII or text representation of the DAG, or reference to a mermaid diagram}
### Ready to Start
{List of tasks with no blockers — these can be assigned immediately}