By aws300
A domain-agnostic agent-team scaffold built around the Planner → Generator → Evaluator loop. Reusable role agents and a reference end-to-end workflow, with plugin-level hooks, MCP/LSP registration, monitors, output style, and user config. Local-first; the same agents deploy headless to Claude Managed Agents via scripts/cma.
Start here — clarify what you want delivered, then route into the Planner → Generator → Evaluator loop
Show the current state of the Planner → Generator → Evaluator loop — active stage, last verdict, blockers
Deliver one feature end to end — plan, challenge the plan, build, challenge the build, package for sign-off
The Planner decomposes a short request into a concrete spec with testable acceptance criteria. Use at the START of any workflow to turn a 1-4 sentence ask into a sprint contract. Does NOT implement — it scopes, decomposes, and defines 'done'. Replace the domain language below for your vertical.
The Generator implements the deliverable against the sprint contract. Use AFTER the plan is approved. It builds, then hands off to the Evaluator — it does NOT self-evaluate and does NOT advance the workflow on a FAIL. Replace the domain language below for your vertical.
The Design Evaluator is the adversarial challenger for the PLAN. Use BEFORE generation begins — it stress-tests the Planner's spec for internal consistency, clarity, testability, risk, and scope fit. Issues APPROVE/REVISE; generation does not start on a REVISE. Replace the domain dimensions below for your vertical.
The Evaluator is the adversarial Challenger — its job is to FIND FAILURES, not confirm success. Use AFTER the Generator finishes a chunk/sprint. Issues a scored PASS/FAIL verdict; FAIL loops back to the Generator. The single most important role for output quality. Replace the domain criteria below for your vertical.
The Coordinator owns the Planner-Generator-Evaluator loop end to end — it calibrates the evaluators to stay skeptical, resolves verdict disputes, and ensures FAIL/REVISE verdicts loop back (never get ignored). Use as the escalation point and loop owner. The opus-tier overseer of the team.
Turn a short request into a sprint contract with binary, testable acceptance criteria. Use when a Planner needs to decompose an ambiguous ask into an implementable spec. Triggers on "write a spec", "plan this feature", "define acceptance criteria", "sprint contract".
Adversarially evaluate an output (a plan or a build) to find failures, not confirm success. Use when issuing a PASS/FAIL or APPROVE/REVISE verdict with scored dimensions. Triggers on "evaluate", "review for failures", "challenge this", "issue a verdict", "find what's broken".
Report the current state of the Planner → Generator → Evaluator loop — which stage is active, the last verdict, open issues, and what's blocking. Read-only. Triggers on "loop status", "where are we", "what's blocking", "show progress".
Executes bash commands
Hook triggers when Bash tool is used
Modifies files
Hook triggers on file write and edit operations
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.
Executables (bin/) — files in this plugin's bin/directory are added to the Bash tool's PATH while the plugin is enabled.
This plugin requires configuration values that are prompted when the plugin is enabled. Sensitive values are stored in your system keychain.
default_modelModel the Sonnet-tier roles (planner, generator, evaluators) run on. The coordinator always runs on opus. Maps to CMA_MODEL for headless deploys.
${user_config.default_model}evaluator_strictnessHow skeptical the evaluators are: 'standard' (default thresholds), 'strict' (raise every blocking threshold and require evidence for each criterion), or 'panel' (spawn multiple independent evaluators and require agreement on high-stakes work).
${user_config.evaluator_strictness}Uses power tools
Uses power tools
Uses Bash, Write, or Edit tools
Uses Bash, Write, or Edit tools
A domain-agnostic scaffold for building an AI agent team as a Claude Code / Cowork plugin, built around one validated skeleton: the Planner → Generator → Evaluator loop (Anthropic Engineering, Harness Design for Long-Running Apps + Building a Multi-Agent Research System).
Local-first — use it directly in Claude Code or Cowork with no build step — and the same agent assets deploy headless to Claude Managed Agents (CMA) via one small Python compiler. One source, two surfaces. Copy this repo, fill in your vertical, ship.
5 role agents · 1 reference workflow · 3 reference skills · 3 thin commands · 4 hooks · 2 rules
LLMs grade their own work leniently. The single biggest lever for quality in a long-running agent team is to separate the agent that produces from the agent that judges, and to tune the judge to be skeptical. That separation is this scaffold's skeleton:
Planner ──spec──▶ Design Evaluator ──APPROVE──▶ Generator ──build──▶ Evaluator ──PASS──▶ Resolver ──▶ ./out/
▲ │ REVISE │ FAIL
└────────────────────┘ ▼
Generator (fix & resubmit)
| Role | What it does | Verdict |
|---|---|---|
| Planner | Decomposes the request into a sprint contract with binary, testable criteria | sprint contract |
| Design Evaluator | Adversarially challenges the plan before any build | APPROVE / REVISE |
| Generator | Implements against the approved contract (never self-certifies) | the deliverable |
| Evaluator | Adversarially challenges the build; the most important role | PASS / FAIL |
| Coordinator | Owns the loop: calibrates evaluators, resolves disputes (Opus) | — |
The Evaluators carry an explicit anti-leniency mandate — file the borderline
issue, don't rationalize it away; when in doubt, FAIL. See docs/coordination-rules.md.
agent-team-scaffold/
├── agents/ ★ the orchestration logic — md is the single source of truth
│ ├── workflows/ │ end-to-end orchestrators (one per deliverable type)
│ │ └── deliver-feature.md │ the reference Planner→Generator→Evaluator loop (copy & rename)
│ └── specialists/ │ reusable role agents, grouped by loop role
│ ├── planning/planner.md
│ ├── generation/generator.md
│ ├── evaluation/ │ evaluator.md (build) · design-evaluator.md (plan)
│ └── coordination/coordinator.md
├── skills/ ★ single source of truth for methods (md), by category
│ ├── authoring/spec-authoring/
│ ├── review/adversarial-review/
│ └── utility/loop-status/
├── commands/ ★ a FEW upper-level entry points (most work is internal to agents)
│ ├── start.md │ requirements intake → routes into the loop
│ ├── status.md │ read-only loop status
│ └── workflows/deliver-feature.md local surface of the reference workflow
├── scripts/cma/ the CMA layer — declare (yaml/md) → compile (build/check) → fulfil (deploy)
│ ├── cma.yaml │ the ONLY config: agent · memory_stores · knowledge · projects · workflows
│ ├── build.py │ DERIVE: projects × workflows → agent + session payloads (no API)
│ ├── check.py │ VALIDATE: refs / scopes / workflows (no API; run in CI)
│ ├── deploy.py │ FULFIL: POST /v1/agents · memory_stores · files · sessions (stdlib; dry-run by default)
│ └── schemas/sprint-contract.json output_schema for the planner (reader) leaf
├── partner-built/ extension point for third-party sub-plugins (empty placeholder)
│
│ ── installable-plugin surface (auto-discovered at plugin root) ──
├── .claude-plugin/
│ ├── plugin.json ★ the plugin manifest — identity + explicit agent list + userConfig
│ └── marketplace.json │ market index (install entry for Cowork / Claude Code)
├── hooks/hooks.json event-level hooks (SessionStart · SubagentStart/Stop · Pre/PostToolUse)
│ └── *.sh │ session-start · log-agent · validate-manifest · validate-push
├── .mcp.json global MCP registration (a filesystem server; per-agent authorized)
├── .lsp.json LSP server registration (pyright example)
├── monitors/monitors.json background monitor — watch-out.sh announces ./out/ sign-off packages
├── output-styles/loop-verdict.md verdict-first, evidence-cited communication style
├── bin/cma-check · cma-deploy executables added to PATH on enable (validate manifest · deploy to Managed Agents)
npx claudepluginhub aws300/agent-team-scaffold --plugin agent-teamHarness-native ECC operator layer - 67 agents, 278 skills, 94 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses
Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.
Consult multiple AI coding agents (Gemini, OpenAI, Grok, Perplexity, plus codex, antigravity, and grok CLIs when installed) to get diverse perspectives on coding problems
The Claude Code knowledge system — 380+ skills, 182+ agents, 100+ commands, 40 hooks, 32 rules, and workflows.
A growing collection of Claude-compatible academic workflow bundles. Covers scientific figures, manuscript writing and polishing, reviewer assessment, citation retrieval, data availability, paper reading, literature search, response letters, paper-to-PPTX conversion, and evidence-grounded Chinese invention patent drafting. Rules are organized as reusable skill folders with explicit workflows and quality checks.
Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques