dev-blueprint-execute

version	1.0.0
name	dev-blueprint-execute
description	Execute a blueprint by creating a taskforce — a group of agents working in parallel on blueprint steps. Creates the workspace, assigns tasks, monitors progress, reviews completed work, and merges results. Use when the user wants to execute an existing blueprint with multiple agents. Requires a blueprint file from dev-blueprint.
disable-model-invocation	true
user-invocable	true
argument-hint	[blueprint-path]

Blueprint Execute — Taskforce Orchestrator

Execute a blueprint by coordinating multiple agents working in parallel.

When to Use

• Executing a blueprint that has multiple parallel groups
• Running multiple agents on independent tasks simultaneously
• Any multi-step plan where parallel execution saves time

Do not use for single-step blueprints or tasks that must be strictly sequential.

How It Works

Phase 1: Setup

1. Read the blueprint file
2. Parse steps, dependencies, and parallel groups
3. Create taskforce workspace at context/taskforce/active/{name}/
4. Create tasks/*.md from blueprint steps
5. Create agent folders with GOAL.md, INBOX.md, OUTBOX.md, WORKLOG.md
6. Present plan to human for approval

Phase 2: Spawn First Parallel Group

For each task in the first parallel group:

1. Create a git worktree for the agent
2. Copy skills into the worktree
3. Populate GOAL.md from the blueprint step
4. Spawn the agent

Phase 3: Monitor (via /loop)

Start a monitoring loop:

/loop 2m Check taskforce status:
1. Read lead/INBOX.md for PENDING messages
2. Check all agent WORKLOGs for Blocked or Complete
3. Report only if something changed

On each cycle:

• PENDING message — answer if possible, escalate to human if not, write response to sender's INBOX.md
• Agent blocked — check if we can unblock (answer question, update GOAL)
• Agent complete — review REVIEW.md + git diff, run dev-verify on merged state, merge or send feedback
• Group complete — spawn next parallel group

Phase 4: Teardown

1. Final cross-cutting verification on main
2. Collect all WORKLOGs into a summary
3. Move workspace from active/ to archive/
4. Clean up worktrees and branches
5. Report to human

Taskforce Workspace Structure

context/taskforce/active/{name}/
├── blueprint.md                  # The blueprint being executed
├── team.md                       # Agent registry and roles
├── STATUS.md                     # Quick overview
├── tasks/
│   ├── 001-{step}.md             # Blueprint step as task spec
│   └── 002-{step}.md
└── agents/
    ├── lead/
    │   ├── INBOX.md
    │   └── OUTBOX.md
    └── {agent-name}/
        ├── GOAL.md               # Task assignment
        ├── WORKLOG.md            # Progress log
        ├── INBOX.md              # Messages received
        └── OUTBOX.md             # Messages sent

Agent Communication

Agents communicate via INBOX.md and OUTBOX.md files using a structured markdown format. See templates/taskforce/ for the file templates.

Rules

• GOAL.md is the source of truth for each agent
• INBOX messages are inputs to consider, not commands to blindly follow
• Only the lead changes an agent's goal (by updating GOAL.md + sending "re-read GOAL.md")
• Agents check their INBOX periodically and evaluate messages against their GOAL
• Contradicting messages are escalated to the lead, not acted on

Verification Chain

Three stages replacing CI:

1. Agent self-check — agent runs dev-verify before marking complete
2. Lead review — lead reads REVIEW.md + diff, approves or sends feedback
3. Post-merge verify — git merge --no-commit, run dev-verify on merged state, commit only if green

Failure Recovery

If an agent crashes, WORKLOG.md is the recovery point. A new agent can be spawned with the same GOAL.md + existing WORKLOG.md and continue from where the previous one stopped.

Examples

/dev-blueprint-execute plans/auth-system.md
/dev-blueprint-execute plans/migration-ef-core.md