By agentx-team
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 Bash, Write, or Edit tools
Uses power tools
Uses Bash, Write, or Edit tools
A curated directory of high-quality plugins for Claude Code.
⚠️ Important: Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended or that they won't change. See each plugin's homepage for more information.
/plugins - Internal plugins developed and maintained by AgentX/external_plugins - Third-party plugins from partners and the communityPlugins can be installed directly from this marketplace via Claude Code's plugin system.
First, add this repository as a plugin marketplace:
claude plugin marketplace add agentx-team/claude-plugins
Then install a plugin from it:
claude plugin install {plugin-name}@agentx-plugins
If you already have the agentx-plugins marketplace added, refresh its manifest first, then install:
claude plugin marketplace update agentx-plugins
The name after
@is the marketplace name defined in.claude-plugin/marketplace.json(agentx-plugins), not the GitHubowner/repopath.
Alternatively, browse for the plugin in /plugin > Discover
Third-party partners can submit plugins for inclusion in the marketplace. External plugins must meet quality and security standards for approval. To submit a new plugin, use the plugin directory submission form.
Each plugin follows a standard structure:
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Plugin metadata (required)
├── .mcp.json # MCP server configuration (optional)
├── commands/ # Slash commands (optional)
├── agents/ # Agent definitions (optional)
├── skills/ # Skill definitions (optional)
└── README.md # Documentation
The name field in a marketplace entry is an immutable slug. Once a plugin has been published, its name must not change — users have it installed under that slug, and renaming it breaks their install with a plugin-not-found error.
displayName instead.renames map in .claude-plugin/marketplace.json so existing installs auto-migrate:"renames": {
"old-name": "new-name"
}
The Claude Code plugin loader reads this map and transparently rewrites the old slug to the new one on the user's next sync.
When a plugin's source repository ships skills (SKILL.md files) without a .claude-plugin/plugin.json manifest, the marketplace entry can declare the skills directly using strict: false and an explicit skills array.
{
"name": "example-bundle",
"description": "Brief description of the bundled skills.",
"author": { "name": "Author Name" },
"category": "development",
"source": {
"source": "git-subdir",
"url": "https://github.com/example-org/sdk.git",
"path": "packages/agent-skills",
"ref": "main",
"sha": "<commit sha>"
},
"strict": false,
"skills": [
"./skill-a",
"./skill-b",
"./skill-c"
],
"homepage": "https://github.com/example-org/sdk"
}
Each path in skills is relative to source.path and points at a directory containing a SKILL.md. Paths can reach deeper than a single level — for example, ["./libA/skill-1", "./libB/skill-2"] exposes a curated subset across multiple library subdirectories. Each skill is registered as <plugin-name>:<skill-name> in Claude Code.
For the underlying schema, see Strict mode in the marketplace documentation.
Please see each linked plugin for the relevant LICENSE file.
For more information on developing Claude Code plugins, see the official documentation.
npx claudepluginhub agentx-team/claude-plugins --plugin agent-teamBind a Claude Code session to an IM chat room; push long-task results to the room on completion.
Start-from-scratch session utilities: /scratch:fresh rescans ~/.claude (skills, plugins, agents, commands, MCP) so a new session in the current directory knows everything available; /scratch:takeover finds another directory's Claude session, absorbs its history into the current context, moves its files here, and continues the work.
Push Claude Code notifications (turn results, human-in-the-loop alerts) to a shared IM chat room. Outbound-only, zero LLM tokens, no Node.js.
A cloud-native software delivery agent team. Seven roles across a Build → Ship → Accept → Promote lifecycle (planner, engineer, reviewer, operator, black-box e2e-tester, marketer, coordinator) and four workflows, building one monorepo derived from github.com/aws300/scaffold. Local-first; the same agents deploy headless to Claude Managed Agents via scripts/cma.
Harness-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