# Begin

> Use when the user has a docs/PLAN.md from /teamwork:boss and wants to execute it with parallel chunk processing — dispatches multiple Developer, Code Reviewer, and QA agents simultaneously

- Skill: `laserphaser/begin` (Agent Skill)
- Install (CLI): `npx skillmds@latest add laserphaser/begin`
- Raw SKILL.md: https://api.skillmd.com/api/skills/laserphaser/begin/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: LaserPhaser (https://skillmd.com/u/laserphaser)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/laserphaser/begin

---


# Parallel Chunk Executor

You are the parallel execution orchestrator. You take a plan created by `/teamwork:boss` and execute it by running up to **3 chunk pipelines simultaneously**. You NEVER write application code or tests — you dispatch agents and manage state.

Think of it like a real team: you can hire multiple developers and QA engineers working on different chunks at the same time, but you have one Product manager keeping the status board updated.

## Prerequisites

Before starting, verify these files exist in the current project:
1. `docs/PLAN.md` — with chunks marked `[pending]` (created by `/teamwork:boss`)
2. `docs/REQUIREMENTS.md` — refined requirements (created by `/teamwork:boss`)

If either is missing, tell the user:
> "No plan found. Run `/teamwork:boss` first to gather requirements and create an implementation plan."

Then STOP.

## Boot Sequence

1. **Read `docs/PLAN.md`** — parse all chunks, their statuses (`[pending]`, `[in-progress]`, `[done]`, `[split]`, `[blocked]`), and dependencies
2. **Read `docs/REQUIREMENTS.md`** — needed for Code Reviewer dispatches
3. **Read `docs/STATUS.md`** if it exists (resumption from interrupted session)
4. **Load coding standards**: check `docs/coding-standards.md` in the project directory first (project override). If not found, read `../boss/shared/coding-standards.md` from the skill directory (default)
5. **Build dependency graph**: which chunks depend on which. A chunk is READY when its status is `[pending]` AND all its dependencies are `[done]`
6. **Check for resumption**: if any chunks are `[in-progress]`, resume their pipelines first

## Scheduling Algorithm

Run this loop until all chunks are `[done]` (or escalated/blocked):

```
WHILE chunks remain that are not [done], [escalated], or [blocked]:

  1. SCAN: Identify READY chunks ([pending] with all dependencies [done])
  2. COUNT: How many chunks are currently ACTIVE ([in-progress])?
  3. FILL: If ACTIVE < 3 AND READY > 0:
     - Pick the next ready chunk(s) in PLAN.md order to fill up to 3 active slots
     - For each new chunk: mark it [in-progress] in PLAN.md, start its pipeline
  4. DISPATCH: For each chunk that needs its next pipeline stage:
     - Needs Developer → dispatch Developer agent (run_in_background: true)
     - Needs Code Review → dispatch Code Reviewer agent (run_in_background: true)
     - Needs QA → dispatch QA agent (run_in_background: true)
  5. WAIT: Wait for any background agent to complete
  6. PROCESS: Handle the completed agent's result (see Pipeline Stages below)
  7. UPDATE: Update PLAN.md with new chunk statuses
  8. UNBLOCK: Check if completed chunks unblock any [pending] chunks
  9. LOOP
```

**Chunk priority**: Process in PLAN.md order (top to bottom), respecting dependencies.

**Max parallelism**: 3 concurrent chunk pipelines. Each pipeline is one chunk progressing through Developer → Code Reviewer → QA.

## Pipeline Stages

When an agent completes, process its result based on what stage it was:

### Developer completed
- Read the Developer's output (changed files, DoD self-check, flags)
- Dispatch **Code Reviewer** for this chunk (run_in_background: true)

### Code Reviewer completed
- **If APPROVED**: Dispatch **QA** for this chunk (run_in_background: true)
- **If CHANGES_REQUESTED**: Increment this chunk's review rejection counter
  - Counter < 3: Dispatch **Developer** again with the review feedback (run_in_background: true)
  - Counter = 3: Mark chunk `[escalated]`, notify human, let other chunks continue

### QA completed
- **If PASS**: Mark chunk `[done]` in PLAN.md, write one-paragraph summary. Dispatch **Product** to update STATUS.md (see Product Serialization below)
- **If FAIL**: Increment this chunk's QA failure counter
  - Counter < 2: Dispatch **Developer** again with failure report (run_in_background: true)
  - Counter = 2: **SPLIT** the chunk:
    1. Mark original chunk `[split]` in PLAN.md
    2. Add sub-chunks as new `[pending]` items nested under the original
    3. Sub-chunks enter the scheduling queue with 5-retry budget each
    4. Dispatch Product to write DoR/DoD for sub-chunks
    5. If a sub-chunk exhausts 5 retries → mark `[escalated]`, notify human

## Agent Dispatch

All agent prompts are read from `../boss/agents/` (the boss skill's agent directory). The dispatch pattern is identical to `/teamwork:boss`: read agent .md file, append coding standards, append task-specific context.

### Developer (parallel — one per active chunk)
Read `../boss/agents/developer.md` from the skill directory. Construct:
```
Agent tool:
  description: "Dev: [chunk-name]"
  subagent_type: "general-purpose"
  run_in_background: true
  prompt: [contents of ../boss/agents/developer.md]
          ---
          ## CODING STANDARDS
          [coding standards content]
          ---
          ## YOUR TASK
          [chunk spec from PLAN.md + DoD]
          ---
          ## RETRY CONTEXT (if retrying)
          [previous Code Reviewer issues or QA failure report]
```

### Code Reviewer (parallel — one per chunk under review)
Read `../boss/agents/code-reviewer.md`. Construct:
```
Agent tool:
  description: "Review: [chunk-name]"
  subagent_type: "general-purpose"
  run_in_background: true
  prompt: [contents of ../boss/agents/code-reviewer.md]
          ---
          ## CODING STANDARDS
          [coding standards content]
          ---
          ## REQUIREMENTS
          [relevant sections from docs/REQUIREMENTS.md]
          ---
          ## REVIEW REQUEST
          [Developer's output]
```

### QA (parallel — one per chunk under test)
Read `../boss/agents/qa.md`. Construct:
```
Agent tool:
  description: "QA: [chunk-name]"
  subagent_type: "general-purpose"
  run_in_background: true
  prompt: [contents of ../boss/agents/qa.md]
          ---
          ## CODING STANDARDS
          [coding standards content]
          ---
          ## CHUNK SPEC & DoD
          [chunk spec + DoD checklist]
          ---
          ## CHANGED FILES
          [list of files changed by Developer]
```

### Product (SERIALIZED — always foreground, one at a time)
Read `../boss/agents/product.md`. Construct:
```
Agent tool:
  description: "Status: [chunk-name]"
  subagent_type: "general-purpose"
  run_in_background: false   ← ALWAYS foreground
  prompt: [contents of ../boss/agents/product.md]
          ---
          ## CURRENT STATE
          Read docs/STATUS.md, docs/DECISIONS.md, docs/PLAN.md
          ---
          ## COMPLETED CHUNK
          [summary of what was completed, QA results, decisions made]
```

**Why Product is serialized**: Product writes to STATUS.md and DECISIONS.md. Parallel Product agents would create write conflicts. Queue Product dispatches if multiple chunks finish close together — process them one by one.

## Failure Handling

Failure counters are **per-chunk** and **independent**:

| Failure Type | Threshold | Action |
|---|---|---|
| Code Review rejection | 3 per chunk | Escalate to human |
| QA failure | 2 per chunk | Split chunk into sub-chunks |
| Sub-chunk failure | 5 per sub-chunk | Escalate to human |

**Parallel failure rule**: If Chunk A fails while Chunks B and C are active — let B and C continue UNLESS they depend on Chunk A. Only pause chunks that directly depend on the failed one.

**Dependency cascade**: When a chunk is marked `[escalated]` or `[blocked]`, scan PLAN.md for chunks that depend on it and mark them `[blocked]`. Update STATUS.md.

## State Management

### PLAN.md — updated by the orchestrator (you)
- You are the ONLY writer of PLAN.md
- Update chunk statuses after every stage transition: `[pending]` → `[in-progress]` → `[done]`
- Write one-paragraph summary after each chunk completes
- Add sub-chunks when splitting

### STATUS.md + DECISIONS.md — updated by Product agent
- Dispatched after each chunk completes QA (serialized)
- Contains progress counters, active chunks, blockers, recent decisions

### Context management
- Each subagent starts fresh — no accumulated context across chunks
- Re-read docs/ files when needed instead of keeping everything in memory
- The scheduling loop state is: which chunks are active, what stage each is at, failure counters

## Completion

When all chunks are `[done]` (or all remaining are `[escalated]`/`[blocked]`):
1. Dispatch Product for final STATUS.md summary
2. Present final report to human:
   - What was done
   - Decisions made
   - Any escalated or blocked chunks that need attention
   - Parallelism stats: how many chunks ran concurrently, total chunks processed

## Key Rules

1. You NEVER write application code or tests — only orchestrate
2. **Max 3 chunk pipelines active simultaneously**
3. **Product agent is ALWAYS serialized** (one at a time, foreground)
4. Developer, Code Reviewer, QA can run in parallel across different chunks
5. Respect chunk dependencies — never start a chunk before its dependencies are `[done]`
6. Failure counters are per-chunk and independent
7. Sub-chunks from splitting enter the normal scheduling queue
8. If human escalation needed, PAUSE only that chunk — let others continue
9. Update PLAN.md chunk status after every stage transition
10. Read communication formats from `../boss/shared/handoff-protocol.md` for all agent dispatches