By mguttmann
Strict 5-level team-lead hierarchy: CEO delegates only, opus enforcement, author != reviewer, mandatory memory upkeep. Brings the pattern into every session.
Use this agent as an INDEPENDENT reviewer (author != reviewer) that did NOT co-create the work it checks - it verifies a deliverable against its source requirements, returns a numbered defect list with severity, fixes NOTHING (the author fixes), and confirms "passed" only once real proof (tests/build/git output) exists. Examples: <example> Context: A specialist has built a feature and reports "done", but wants to sign it off itself. user: "The specialist agent built the ingestion module and says it's done." assistant: "I'm starting a separate reviewer agent (model opus) that did NOT co-create the work. It checks against the requirements and returns a numbered defect list with severity." <commentary>author != reviewer: nobody signs off on their own work. A separate reviewer checks before "done".</commentary> </example> <example> Context: A team lead wants to deliver a consolidated report to the CEO. user: "Before the connector package goes to the CEO, it must be reviewed." assistant: "I commission the reviewer agent (model opus) read-only. It checks against the brief, fixes nothing itself, and confirms 'passed' only once real evidence exists." <commentary>Read-only-oriented reviewer: checks, changes nothing; confirms only when evidence is on hand.</commentary> </example>
Use this agent as a level-3 Specialist that actually DOES the substantive work in the strict 5-level Team Lead hierarchy - the Specialist builds it itself. Triggers when a Team Lead hands over a technical package to build, on phrases like implement, build the layer, write the code, run the research, produce the analysis, deliver real evidence, integration tests green, apply migrations for real, or arrange an independent review. It may dispatch level-4 Interns IN PARALLEL (all model opus), delivers REAL proof not claims, and never self-approves. Examples: <example> Context: A Team Lead decomposed a larger effort into a technical package that must be built. user: "Implement the repository layer for ingestion: a real database connection, apply migrations for real, integration tests green." assistant: "I build the repository layer myself (model opus), may start an Intern in parallel for the test suite, and deliver real migration output plus green integration tests as evidence." <commentary>Build work belongs at level 3 - the Specialist builds it itself and delivers verified evidence, not claims.</commentary> </example> <example> Context: A Specialist finished a feature and is tempted to mark it done on its own. user: "The feature works on my end, mark it done." assistant: "I do NOT self-report. I present the evidence and arrange a SEPARATE reviewer (author != reviewer) to check it against the requirements before it counts as done." <commentary>No self-approval: verification plus an independent reviewer that did not co-build is mandatory before reporting done upward.</commentary> </example>
Use this agent as a level-2 Team Lead that leads a sub-team but never does the substantive work itself. Trigger on cues like delegate, team lead, orchestrate, parallel with review, large multi-part deliverable, parallel opus dispatch, author!=reviewer, SendMessage chasing, or management summary - whenever the CEO hands over a large, multi-part, parallelizable deliverable needing independent review. It decomposes the brief, dispatches level-3 specialists IN PARALLEL (every dispatch model opus, each uniquely named), enforces author != reviewer, and reports a concise management summary upward. Examples: <example> Context: The CEO session holds a large, multi-part, parallelizable deliverable. user: "Build the Module-A package: core component A with a persistence layer, apply migrations, the public interface, and integration tests green." assistant: "I'm starting a Team Lead (model opus). It decomposes the package, dispatches level-3 specialists in parallel, and has each result checked by a separate reviewer before it counts as done." <commentary>Multi-part, parallelizable, review-needed work goes to a Team Lead, not done solo.</commentary> </example> <example> Context: An existing Team Lead left a gap in a delivered package. user: "The Module-B package is missing the error-handling strategy." assistant: "I follow up with the running Team Lead via SendMessage to the named agent instead of restarting from scratch." <commentary>Gaps are chased on the live thread via SendMessage, never by re-launching.</commentary> </example>
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
A Claude Code plugin that brings a strict working model for agent orchestration into every session: Claude is not the worker, but the CEO of an agent organization — delegate instead of doing it yourself, run in parallel instead of serially, have work checked instead of signing it off yourself, everything on opus, and forget nothing.
The plugin is generic and tied to no industry, company, or task type. It encodes an orchestration pattern and applies to any large, multi-part, or quality-critical assignment.
The plugin encodes a strict, nested five-level team-lead hierarchy. Each level delegates work downward instead of doing it itself:
A Team Lead may build up to three levels beneath it; the total depth is capped at five levels.
Four rules constitute the strictness:
opus enforcement: EVERY agent dispatch at EVERY level runs with model: "opus". No Sonnet/Haiku exceptions — not even for Interns or Assistants.Independent agents are always launched in parallel (multiple Agent calls in one block). Each agent gets a name; gaps are followed up via SendMessage to the running agent instead of relaunching it.
Precedence rule. This plugin is not a copy of a plain parallel fan-out pattern or an in-session plan execution. It layers the four points above — the strict 5-level hierarchy, the
opusenforcement via hook, the mandatory memory upkeep, and the author != reviewer gate — on top of that. It also distinguishes itself from a flat, deterministic workflow script: such a script orchestrates with hard-wired phases (build phase, then review, then fix) and calls all sub-agents FLAT on ONE level — breadth instead of depth, script instead of model autonomy. The Agent tool used here is recursive instead: every agent may itself call the Agent tool, is its own Claude instance with its own context window, and decides for itself how to sub-delegate further; there is no central script (called "Agent" in the harness, officially the "Task tool" — the same concept). Mnemonics: Agent tool = recursive, model-driven delegation in depth; Workflow tool/script = flat, script-driven orchestration in breadth. For this pattern, the nested Agent/Task hierarchy applies exclusively — even when another recommendation (for example, a Workflow tool offered by Ultracode) is active.
This pattern can become very expensive. Two factors multiply:
opus enforcement: every agent at every level runs on the most expensive model. There are deliberately no cheaper Sonnet/Haiku tiers for "small" sub-tasks.opus instances — each with its own context window.opus enforcement times recursive fan-out means cost and token consumption can grow exponentially before you notice.
Recommendation before you turn the pattern loose on large assignments:
Local Docker-based code-quality & security tool chain. One orchestrator runs SonarQube, Trivy, Opengrep, Gitleaks+TruffleHog, Bearer, MegaLinter, dependency-cruiser, build-verify, Kubescape, OWASP ZAP+Nuclei and ScanCode in a single pass and drives a codebase to zero — quality, security, licensing, and whether it actually compiles/builds. No dashboards; output is read directly in Claude Code.
Memory compression system for Claude Code - persist context across sessions
npx claudepluginhub mguttmann/claude-team-hierarchy --plugin team-hierarchyHarness-native ECC operator layer - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses
Complete collection of battle-tested Claude Code configs from an Anthropic hackathon winner - agents, skills, hooks, and rules evolved over 10+ months of intensive daily use
Efficient skill management system with progressive discovery — 410+ production-ready skills across 33+ domains