mcpField
T
the-capo

the-capo

github.com/kucherenkoAgent workflows8542 installsUpdated 1d ago
Repository

About the-capo

The Capo is a skill template for coordinating Workers within a defined codebase territory. It is intended for Underboss-led development crews and emphasizes contract-based review, status reporting, and budget tracking.

Key features

  1. 01Territory-scoped work coordination
  2. 02Worker brief preparation and dispatch
  3. 03Parallel work on independent packages
  4. 04Contract-based report review
  5. 05Status and token-use reporting

Use cases

  1. 01Assigning code changes to territory-specific Workers
  2. 02Reviewing Worker changes against acceptance criteria
  3. 03Escalating blocked or ambiguous work packages

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/kucherenko/gangsta --skill the-capo

After installing, type/the-capoin Claude Code to confirm it loaded.

Details

From the project README

The Capo: Territory Commander (Crew Lead)

Overview

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

Territory Context

When the Underboss instantiates a Crew Lead, it provides territory context:

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

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

Worker Dispatch Protocol

For each Work Package assigned to this territory:

  1. Prepare Worker 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 Worker — Launch a subagent with subagent_type: "soldier" (do NOT use "general" or "general-purpose" — these are not valid in a Gangsta Agents installation) and the Worker brief. Multiple Workers can run in parallel on independent Work Packages.

  3. Receive Report — Each Worker returns:

    ## Report: <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 Report — 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 Worker 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:

## 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 (Worker dispatched)
- WP-004: ❌ Failed — escalated to Underboss

Omerta Compliance

  • Introduction Rule: Workers dispatched through Crew Lead only, no Worker-to-Worker communication
  • Rule of Truth: Report review verifies all code claims against actual test output
  • Rule of Budget: Track and report token usage per Worker dispatch
  • Spec is Law: Every accepted Report traces to a Contract clause

Comments

Markdown supported