Workorder Processor

Skip work orders where:

• The capability_id already exists in the registry (check data/cerebellum_signatures.json)
• The parent work order has not been resolved yet

Present a summary table to the user before proceeding:

| # | Ticket | capability_id | Priority | Status |
|---|--------|---------------|----------|--------|
| 1 | DEV_xxx_yyy | some_capability | 8/10 | ready |
| 2 | DEV_xxx_zzz | other_capability | 5/10 | blocked (parent) |

Step 3: Process Each Work Order

For each actionable work order (in priority order):

1. Read the full .md ticket file.
2. Follow the $cerebellum-developer skill workflow (Steps 1-7).
3. Track the result: implemented / skipped (exists) / skipped (composable) / failed.

Step 4: Summarize Results

After processing all work orders, produce a summary:

## Batch Processing Results

- Total scanned: N
- Implemented: X
- Skipped (already exists): Y
- Skipped (composable from existing): Z
- Failed: W

### Details
| capability_id | Result | File | Notes |
|---------------|--------|------|-------|
| ... | implemented | agents/.../xxx.py | |
| ... | skipped | — | exists as analyze_style |

Write the summary to evidences/workorder_batch_{timestamp}.json.

Step 5: Verify All

Run the smoke test to confirm nothing is broken:

PYTHONPATH=. python scripts/runtime_smoke.py

For each newly implemented capability, also run:

PYTHONPATH=. python scripts/codex_verify_cerebellum.py --capability_id {id}

Notes

• Do not implement more than 5 cerebellums in a single batch without verifying. Run verification after every 5 implementations to catch regressions early.
• If a work order requires LLM calls and no API keys are configured, mark it as blocked (needs API config) and move on to the next.
• Decomposed work orders (those with a Parent field) should be implemented in dependency order: parent first, then children.