Do Parallel Work

Architecture

Orchestrator (you)
    │
    ├── Scan queue for pending REQs
    │
    ├── Analyze dependencies
    │   ├── REQ-001: no deps → batch 1
    │   ├── REQ-002: no deps → batch 1
    │   └── REQ-003: depends_on: [REQ-001] → batch 2
    │
    ├── Spawn sub-agents for batch 1 (parallel)
    │   ├── sessions_spawn → REQ-001
    │   └── sessions_spawn → REQ-002
    │
    ├── Monitor completions (poll sessions_list)
    │
    ├── As agents complete:
    │   ├── Archive completed REQs
    │   └── Check if blocked REQs are now unblocked
    │
    └── Spawn next batch, repeat until done

Inbox Folder (External Input)

You can drop files into an inbox folder while the orchestrator is working:

/path/to/inbox/           ← Drop .md files here anytime
└── new-feature.md        ← Plain text, any format

The work action checks the inbox before each batch:

1. Read new files from inbox
2. Process them through the "do" action (create UR + REQs)
3. Move/delete the inbox file
4. Include new REQs in dependency analysis

This allows async task addition without interrupting in-flight work.

Routing Decision

Step 1: Parse the Input

Examine what follows "do parallel work":

Action Verbs (→ Work)

run, go, start, begin, work, process, execute, build, continue, resume

Verify Verbs (→ Verify)

verify, check, evaluate, review requests, audit

Cleanup Verbs (→ Cleanup)

cleanup, clean up, tidy, consolidate, organize archive

Status Verbs (→ Status)

status, progress, show, list, queue

Content Signals (→ Do)

• Descriptive text beyond a single verb
• Feature requests, bug reports, ideas
• "add", "create", "I need", "we should"

Request File Schema

Same as do-work, with additional fields for parallel execution:

---