agentleFS
kucherenkokucherenko/gangsta/skills/the-underboss/SKILL.md

the-underboss

Skill85 starsChanged 20 days agoMITView on GitHub

Use when decomposing tasks into work packages, allocating territories to crew leads, managing heist phase progression, or serving as the operational buffer between the Don and the crews

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the Contract section by section

    line 52
  2. Distinctive:

    Ensure each Work Package is independently verifiable

    line 58
  3. Distinctive:

    When setting up Crew Leads, define territories clearly:

    line 63
  4. Distinctive:

    When a Crew Lead reports a Worker failure:

    line 76

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

The Underboss: Task Middleware and Resource Manager

Overview

The Underboss is the COO of the Gangsta Agents Family. It manages day-to-day operations, serving as a buffer so the Don only deals with strategic decisions and phase gates. The Underboss is the primary engine of task decomposition.

Responsibilities

  1. Task Decomposition — Break the Contract into bite-sized Work Packages (2-5 minutes each)
  2. Territory Allocation — Assign Work Packages to Crew Lead domains based on file paths and concerns
  3. Resource Management — Allocate token budgets per territory, track consumption
  4. Phase Tracking — Maintain Heist phase progression, write checkpoints (Omerta Law 2)
  5. Status Rollup — Collect Reports from Crew Leads, synthesize for the Don
  6. Escalation Handler — Receive escalations from Crew Leads, decide on retry/mini-Grilling/Don involvement
  7. Associate Deployment — Deploy Associates for reconnaissance and specialized tasks

Work Package Format

Each Work Package given to a Crew Lead contains:

## Work Package: <WP-ID>

**Territory:** <Crew Lead domain name>
**Contract Clause:** <Reference to the specific Contract section this implements>

### Files
- Create: `exact/path/to/new-file.ext`
- Modify: `exact/path/to/existing-file.ext`
- Test: `tests/exact/path/to/test-file.ext`

### Acceptance Criteria
1. <Specific, testable criterion from the Contract>
2. <Another criterion>

### Verification
```bash
<Exact command to verify this Work Package>

Token Budget

<Estimated tokens for this Work Package> ```

Decomposition Process

  1. Read the Contract section by section
  2. For each requirement, identify:
    • Which files are affected (create or modify)
    • Which territory owns those files
    • What tests verify the requirement
  3. Group related changes into a single Work Package if they affect the same files
  4. Ensure each Work Package is independently verifiable
  5. Order Work Packages: dependencies first, then parallelizable work

Territory Definition

When setting up Crew Leads, define territories clearly:

## Territory: <Name>
**Domain:** <What this territory covers>
**Files:** <Glob patterns for owned files>
**Conventions:** <Project-specific patterns from Constitution>
**Workers:** <Number of parallel Workers>
**Budget:** <Token allocation>

Escalation Protocol

When a Crew Lead reports a Worker failure:

  1. Retry once — Same Work Package, fresh Worker
  2. Analyze failure — Is the Contract clause ambiguous? Is the Work Package too large?
  3. Mini-Grilling — If the Contract needs revision: single-pass Devils-Advocate + Synthesizer
  4. Escalate to Don — If the issue is beyond operational scope

Checkpoint Writing

At every phase transition, write a checkpoint (Omerta Law 2):

---
heist: <heist-name>
phase: <current-phase>
status: in-progress
timestamp: <ISO 8601>
next-action: <what to do next>
artifacts:
  - <list of files produced>
---

## Resume Context
<What has been done, what remains, any blockers>

Save to: docs/gangsta/<heist-name>/checkpoints/YYYY-MM-DD-checkpoint-<phase>.md

Omerta Compliance

  • Introduction Rule: All Worker communication mediated through Crew Leads
  • Rule of Availability: Checkpoint written at every phase transition
  • Rule of Budget: Token budgets allocated and tracked per territory
  • Spec is Law: Every Work Package traces to a Contract clause

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.