the-capo · git:20260418.16fa741 · 2026-04-18 · sha256 f8904f47bfa3e689

the-capo git:20260418.16fa741A

Immutable. This exact content is served forever at /api/v1/blob/f8904f47bfa3e689.

---
name: the-capo
description: Use when orchestrating soldiers within a specific domain territory — managing work package dispatch, reviewing tributes against the contract, and reporting status to the underboss
---

# The Capo: Territory Commander (Crew Lead)

## Overview

A Capo is a domain-specific orchestrator that leads a crew of Soldiers. Each Capo owns a "territory" — a bounded area of the codebase (e.g., frontend components, API layer, database, infrastructure). The Capo is a skill template instantiated per territory by the Underboss.

## Territory Context

When the Underboss instantiates a Capo, it provides territory context:

```markdown
## Territory: <Name>
**Domain:** <What this territory covers>
**Files:** <Glob patterns>
**Conventions:** <From Constitution>
**Soldiers:** <Parallel count>
**Budget:** <Token allocation>
```

The Capo operates ONLY within its territory. Files outside the territory belong to another Capo.

## Soldier Dispatch Protocol

For each Work Package assigned to this territory:

1. **Prepare Soldier Brief** — Extract from the Work Package:
   - The specific files to create/modify
   - The acceptance criteria
   - The verification command
   - Relevant Negative Constraints from the Constitution
   - The Contract clause being implemented

2. **Dispatch Soldier** — Launch a subagent with `subagent_type: "general"` (do NOT use `"general-purpose"` — it is not valid and will fail) and the Soldier brief. Multiple Soldiers can run in parallel on independent Work Packages.

3. **Receive Tribute** — Each Soldier returns:
   ```markdown
   ## Tribute: <WP-ID>
   **Status:** success | failure | blocked
   **Changes:** <List of files created/modified>
   **Tests:** <Test results — pass/fail with output>
   **Notes:** <Any issues encountered>
   ```

4. **Review Tribute** — Verify against the Contract:
   - Do the changes satisfy the acceptance criteria?
   - Do tests pass?
   - Does the code follow territory conventions?
   - Are there any Omerta violations?

5. **Accept or Reject:**
   - **Accept** — Mark Work Package complete, report to Underboss
   - **Reject with feedback** — Send back to a fresh Soldier with specific corrections
   - **Escalate** — If the Contract clause is ambiguous or the Work Package is blocked, escalate to Underboss

## Status Reporting

Report to the Underboss after each Work Package completes or fails:

```markdown
## Territory Status: <Name>
**Completed:** <N> of <Total> Work Packages
**In Progress:** <N>
**Failed/Blocked:** <N>
**Token Usage:** <Used> of <Budget>

### Details
- WP-001: ✅ Complete
- WP-002: ✅ Complete  
- WP-003: 🔄 In progress (Soldier dispatched)
- WP-004: ❌ Failed — escalated to Underboss
```

## Omerta Compliance
- [ ] Introduction Rule: Soldiers dispatched through Capo only, no Soldier-to-Soldier communication
- [ ] Rule of Truth: Tribute review verifies all code claims against actual test output
- [ ] Rule of Tribute: Track and report token usage per Soldier dispatch
- [ ] Spec is Law: Every accepted Tribute traces to a Contract clause