Agent Catalog
mx-workflow includes 12 specialized agents. The eight review-grade agents are the heart of the plugin — each interrogates your code from a different angle and pushes back on what doesn’t meet the bar. The four build agents are supporting cast: they generate code during /mx:build pipelines, which the review agents then interrogate.
All agents run as sub-agents via the Task tool, either automatically during commands like /mx:implement or on-demand through the /mx:agents command.
How agents work
Section titled “How agents work”Each agent is a focused expert with a single responsibility. When invoked, it receives the relevant code (typically your unstaged changes from git diff) and produces a structured report with findings, severity ratings, and actionable recommendations.
Review agents are advisory by default — they analyze and report rather than modify code (the exceptions: mx-code-simplifier, which applies refinements, and the build agents, which write code by design).
Review-grade agents
Section titled “Review-grade agents”The interrogation layer. These eight catch what a generator won’t tell you: silent failures, hallucinated APIs, weakened types, missing tests, and unjustified shortcuts.
mx-code-reviewer
Section titled “mx-code-reviewer”Purpose: Review code against CLAUDE.md project guidelines and detect bugs.
| Property | Value |
|---|---|
| Model | Opus |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | Unstaged changes from git diff |
What it checks:
- Adherence to project rules in CLAUDE.md (import patterns, naming conventions, error handling, etc.)
- Logic errors, null/undefined handling, race conditions
- Memory leaks and security vulnerabilities
- Code duplication and missing critical error handling
- Accessibility problems and inadequate test coverage
Confidence scoring: Every issue is rated 0-100. Only issues scoring 80 or above are reported, which keeps output focused on real problems rather than noise.
Invoked by:
/mx:implement— always runs during the agent review pass (Step 5)- Can be invoked directly via the Task tool at any time
mx-code-simplifier
Section titled “mx-code-simplifier”Purpose: Simplify code for clarity and maintainability while preserving all functionality.
| Property | Value |
|---|---|
| Model | Opus |
| Mode | Active (applies refinements to code) |
| Default scope | Recently modified code |
What it does:
- Reduces unnecessary complexity and nesting
- Eliminates redundant code and abstractions
- Improves variable and function naming
- Consolidates related logic
- Removes comments that describe obvious code
- Replaces nested ternary operators with clearer control flow
- Applies project-specific coding standards from CLAUDE.md
Important: This agent preserves exact functionality. It changes how code is written, never what it does. It also avoids over-simplification — it will not create clever one-liners that sacrifice readability.
Invoked by:
/mx:implement— runs as the final polish pass after other agents (Step 5)- Can be invoked directly via the Task tool at any time
mx-comment-analyzer
Section titled “mx-comment-analyzer”Purpose: Analyze code comments for accuracy, completeness, and long-term maintainability.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | Comments and docstrings in changed files |
What it checks:
- Factual accuracy — do comments match the actual code? Are parameter types, return values, and described behaviors correct?
- Completeness — are critical assumptions, side effects, and error conditions documented?
- Long-term value — do comments explain “why” rather than restating “what”? Will they remain accurate as the code evolves?
- Misleading elements — ambiguous language, outdated references, TODOs that have already been addressed
Output categories:
- Critical Issues — factually incorrect or highly misleading comments
- Improvement Opportunities — comments that could be enhanced
- Recommended Removals — comments that add no value or create confusion
- Positive Findings — well-written comments worth highlighting as examples
Invoked by:
/mx:implement— runs during the agent review pass if comments or docstrings were added or modified- Can be invoked directly via the Task tool at any time
mx-mr-test-analyzer
Section titled “mx-mr-test-analyzer”Purpose: Review test coverage quality and completeness for merge requests.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | Test files in the current MR or changeset |
What it checks:
- Behavioral coverage — are critical code paths, edge cases, and error conditions tested?
- Test quality — do tests verify behavior and contracts rather than implementation details?
- Regression resilience — would tests catch meaningful regressions from future changes?
- Missing negative cases — are validation logic and error scenarios covered?
- Concurrency coverage — are async and concurrent behaviors tested where relevant?
Criticality ratings: Each recommendation is rated 1-10:
| Rating | Meaning |
|---|---|
| 9-10 | Critical — could cause data loss, security issues, or system failures |
| 7-8 | Important — could cause user-facing errors |
| 5-6 | Useful — covers edge cases that could cause confusion |
| 3-4 | Nice-to-have — improves completeness |
| 1-2 | Optional — minor improvements |
Invoked by:
/mx:implement— runs during the agent review pass if test files were added or modified- Can be invoked directly via the Task tool at any time
mx-performance-auditor
Section titled “mx-performance-auditor”Purpose: Analyze code for performance bottlenecks, inefficient patterns, and scalability risks.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | Unstaged changes from git diff |
Analysis categories:
- Algorithmic complexity — O(n^2) loops, unnecessary iterations, inefficient data structures, sorting overhead
- Memory patterns — large allocations, memory leaks, unbounded caches, unnecessary object copying
- I/O bottlenecks — N+1 queries, missing pagination, synchronous blocking, sequential operations that could be parallel
- Frontend performance — unnecessary re-renders, large bundle imports, missing lazy loading, missing virtualization
- Database patterns — missing indexes, full table scans, unoptimized queries, transaction issues
Severity levels:
| Level | Meaning |
|---|---|
| CRITICAL | Production impact likely |
| WARNING | Will degrade at scale |
| INFO | Minor optimization opportunity |
Invoked by:
- Can be invoked directly via the Task tool when investigating performance concerns
- Useful to run after implementing features that handle large data volumes or run on hot paths
mx-silent-failure-hunter
Section titled “mx-silent-failure-hunter”Purpose: Find silent failures, inadequate error handling, and inappropriate fallback behavior.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | Error handling code in changed files |
What it hunts for:
- Empty catch blocks
- Catch blocks that log and continue without user feedback
- Broad exception catching that hides unrelated errors
- Returning null/default values on error without logging
- Optional chaining (
?.) silently skipping operations that might fail - Fallback chains that try multiple approaches without explanation
- Retry logic that exhausts attempts without informing the user
- Mock/fake implementations in production code
For each issue found, it reports:
- Location (file and line)
- Severity (CRITICAL, HIGH, or MEDIUM)
- What is wrong and why it is problematic
- Which unexpected errors could be hidden
- How it affects the user experience
- Specific code changes needed, with examples
Invoked by:
/mx:implement— always runs during the agent review pass (Step 5)- Can be invoked directly via the Task tool at any time
mx-type-design-analyzer
Section titled “mx-type-design-analyzer”Purpose: Analyze type design for encapsulation quality and invariant expression.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Advisory (reports findings, does not modify code) |
| Default scope | New or modified type definitions |
Analysis framework — four dimensions rated 1-10:
| Dimension | What it evaluates |
|---|---|
| Encapsulation | Are internals hidden? Can invariants be violated from outside? Is the interface minimal and complete? |
| Invariant Expression | How clearly are invariants communicated through structure? Are they enforced at compile time where possible? |
| Invariant Usefulness | Do invariants prevent real bugs? Are they aligned with business requirements? |
| Invariant Enforcement | Are invariants checked at construction? Are mutation points guarded? Can invalid instances be created? |
Common anti-patterns it flags:
- Anemic domain models with no behavior
- Types that expose mutable internals
- Invariants enforced only through documentation
- Types with too many responsibilities
- Missing validation at construction boundaries
Invoked by:
/mx:implement— runs during the agent review pass if new types or interfaces were added- Can be invoked directly via the Task tool when introducing or refactoring types
mx-quality-keeper
Section titled “mx-quality-keeper”Purpose: Adversarial quality gatekeeper — verifies completed work and rejects what doesn’t meet the bar, without writing production code.
| Property | Value |
|---|---|
| Model | Opus |
| Mode | Advisory (verifies and rejects; never writes production code) |
| Default scope | Unstaged changes from git diff, or specified scope |
What it does:
- Runs adversarial by design — its job is to find what’s broken, not confirm what works. When in doubt, it fails the check and explains why.
- Orchestrates existing mx quality commands (
/mx:validate,/mx:check-ignores,/mx:deps) rather than reimplementing them. - Operates in two contexts:
- Team build mode — a mandatory QA teammate in
/mx:build-with-agent-team; verifies every task before it can close, routes failures back to the owning agent, and escalates after repeated failures. - Standalone mode — invoked via
/mx:qato run a comprehensive quality audit on current work.
- Team build mode — a mandatory QA teammate in
Invoked by:
/mx:qa— standalone quality audit/mx:build-with-agent-team— mandatory QA gate for every task- Can be invoked directly via the Task tool at any time
Optional build agents
Section titled “Optional build agents”Supporting cast for the /mx:build and /mx:build-with-agent-team pipelines. These agents generate code — schema, features, tests, launch integrations — which the review-grade agents above then interrogate. Invoke them through the build commands rather than directly.
mx-schema-builder
Section titled “mx-schema-builder”Purpose: Build a database schema for a new project from a spec’s data model section.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Active (writes migrations, types, and policies) |
| Pipeline step | After scaffolding, before feature implementation |
Creates Supabase (PostgreSQL) tables, indexes, RLS policies, TypeScript types, and migration files from the data model section of a product spec.
mx-feature-builder
Section titled “mx-feature-builder”Purpose: Implement a single product feature end-to-end from its spec.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Active (writes feature code) |
| Pipeline step | Once per feature, after schema is in place |
Takes one feature’s spec (name, user action, expected result, implementation notes) plus project context (stack, data model, routes) and builds it end-to-end, following patterns established by prior features.
Where the project has an established convention it follows that. Where there’s no precedent, it falls back to the Project Structure and Code Style rules — lowest-common-ancestor file placement, no sibling-subtree imports, folder-qualified filenames, strings extracted to constants, guard clauses over nesting, no speculative abstraction. Any deviation is reported in its output with the rule, the reason, and the rejected alternative.
mx-test-builder
Section titled “mx-test-builder”Purpose: Write Playwright end-to-end tests and run them until they pass.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Active (writes and runs tests) |
| Pipeline step | After all features are implemented |
Sets up Playwright if needed, writes comprehensive E2E tests from the feature list and test scenarios in the spec, and iterates until every test passes.
mx-shipkit-builder
Section titled “mx-shipkit-builder”Purpose: Integrate the Ship Kit into a built product so it’s ready to launch.
| Property | Value |
|---|---|
| Model | Inherited from session |
| Mode | Active (integrates launch components) |
| Pipeline step | After features and tests pass, before quality review |
Wires in the five Ship Kit components — analytics (Umami), SEO, Stripe payments, a feedback widget, and a contact footer — for production deployment.
Quick reference
Section titled “Quick reference”Review-grade agents
Section titled “Review-grade agents”| Agent | Runs automatically in | On-demand |
|---|---|---|
| mx-code-reviewer | /mx:implement (always) | Yes |
| mx-silent-failure-hunter | /mx:implement (always) | Yes |
| mx-type-design-analyzer | /mx:implement (if types changed) | Yes |
| mx-comment-analyzer | /mx:implement (if comments changed) | Yes |
| mx-mr-test-analyzer | /mx:implement (if tests changed) | Yes |
| mx-performance-auditor | — | Yes |
| mx-code-simplifier | /mx:implement (always, final pass) | Yes |
| mx-quality-keeper | /mx:qa, /mx:build-with-agent-team (QA gate) | Yes |
Optional build agents
Section titled “Optional build agents”| Agent | Runs in | On-demand |
|---|---|---|
| mx-schema-builder | /mx:build pipeline (after scaffolding) | Via build commands |
| mx-feature-builder | /mx:build pipeline (per feature) | Via build commands |
| mx-test-builder | /mx:build pipeline (after features) | Via build commands |
| mx-shipkit-builder | /mx:build pipeline (before QA) | Via build commands |
To see agents available in your current session, run:
/mx:agentsTo invoke any agent directly, use the Task tool with the agent name and specify which files or scope to analyze.