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
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- rules/AGENTS.mdAGENTS.md
- audit-reviewSkill
- drill-tddSkill
- exit-strategySkill
- interrogation-debuggingSkill
- launderingSkill
- omertaSkill
- receiving-ordersSkill
- reconnaissanceSkill
- resource-developmentSkill
- safehouse-worktreesSkill
- sweep-verificationSkill
- the-capoSkill
- the-consigliereSkill
- the-grillingSkill
- the-hitSkill
- the-ledgerSkill
- the-sit-downSkill
- using-gangstaSkill
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
- Distinctive: line 52
Read the Contract section by section
- Distinctive: line 58
Ensure each Work Package is independently verifiable
- Distinctive: line 63
When setting up Crew Leads, define territories clearly:
- Distinctive: line 76
When a Crew Lead reports a Worker failure:
≈ “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.
Files
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
- Task Decomposition — Break the Contract into bite-sized Work Packages (2-5 minutes each)
- Territory Allocation — Assign Work Packages to Crew Lead domains based on file paths and concerns
- Resource Management — Allocate token budgets per territory, track consumption
- Phase Tracking — Maintain Heist phase progression, write checkpoints (Omerta Law 2)
- Status Rollup — Collect Reports from Crew Leads, synthesize for the Don
- Escalation Handler — Receive escalations from Crew Leads, decide on retry/mini-Grilling/Don involvement
- 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
- Read the Contract section by section
- For each requirement, identify:
- Which files are affected (create or modify)
- Which territory owns those files
- What tests verify the requirement
- Group related changes into a single Work Package if they affect the same files
- Ensure each Work Package is independently verifiable
- 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:
- Retry once — Same Work Package, fresh Worker
- Analyze failure — Is the Contract clause ambiguous? Is the Work Package too large?
- Mini-Grilling — If the Contract needs revision: single-pass Devils-Advocate + Synthesizer
- 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
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
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.

