MoAI Development Harness
A Claude Code harness that turns coding work into gated SPEC workflows with model routing and budget controls.
Per-dimension scores and reasoning
Evidence shows: CI workflow explicitly declares least-privilege (contents: read) and comments that no extra scope is needed; auto-merge workflow requires write permissions but only for merging PRs. User confirmation mechanisms exist: Token Circuit Breaker only suggests /clear, never auto-executes; learning ladder auto-update requires user approval; Harness v4 Builder has approval gate. Data flow transparency: status line shows context usage, cache hit rate, etc.; verification output redirected to disk files, evidence persisted. Sensitive data handling: MCP templates use ${VAR} env var references, avoiding literal secrets; security policy recommends env vars. Dependency security: go.mod lists many dependencies but no vulnerability scanning evidence; CI includes CodeQL workflow (file not provided). External effects: auto-merge workflow may auto-merge PRs but only after CI success; install scripts fetched from remote, not reviewed. Rollback: moai update supports auto-rollback, harness rollback can undo learning applications. Source attribution: README and LICENSE clearly attribute copyright to Modu AI, but publisher unverified. Deductions: dependency security lacks concrete vulnerability scanning evidence; install scripts not reviewed; auto-merge may reduce human review.
Evidence shows: README-described features are consistent with CLI commands, agent catalog, etc., internal consistency good. Dependency availability: go.mod lists many dependencies but no lock file or vendor directory provided, availability depends on upstream. Failure messages: CI test scripts have clear PASS/FAIL output, but product's own error messages not detailed in provided files. Deductions: dependency availability lacks lock file; failure messages insufficient at product level.
Evidence shows: README clearly targets Claude Code users, provides multiple usage scenarios (plan/run/sync, goal/loop, CG mode, etc.). Capability boundaries: docs mention supported platforms (macOS/Linux/Windows WSL) and unsupported (native cmd.exe), and list prerequisites. Trigger precision: /moai commands have clear subcommands and natural language routing, but detailed trigger conditions not provided. Environment fit: multi-platform support, but Windows native not supported, requires WSL. Deductions: trigger precision lacks detailed documentation; environment fit has platform limitations.
Evidence shows: Information architecture clear, README has TOC, docs site links, CLI reference. Install notes detailed, multiple installation methods. Naming stability: version v3.0.2, CHANGELOG link. Examples and FAQ: README includes quickstart and FAQ. Known limitations: docs mention retired subcommands and platform limitations. License: Apache-2.0 full text. Versioning changelog: CHANGELOG.md link. Maintenance responsibility: contribution guide and security policy. Deductions: CHANGELOG content not provided, version history incomplete; maintenance responsibility not specific maintainers.
Evidence shows: Output usability: status line provides real-time info, verification output redirected to files, evidence persisted. Marginal value: provides cost control, quality gates, self-improvement etc., clear added value over bare Claude Code. Cost-benefit: docs claim CG mode saves 60-70% cost, but no independent verification. Deductions: cost savings claims lack independent verification; output usability depends on terminal environment.
Evidence shows: README performance data (e.g., DeepSWE leaderboard) lacks source links, but docs site may provide. Cross-source corroboration: CI workflows and test scripts provide some verification, but no independent third-party verification. Fact-inference separation: README distinguishes facts (e.g., version numbers) from inferences (e.g., cost savings), but some claims (e.g., '16x cheaper') lack data sources. Deductions: performance data lacks sources; cross-source corroboration insufficient.
- Publisher identity unverified; install scripts fetched from remote, review them before execution.
- Dependency security lacks vulnerability scanning evidence; check dependencies for known vulnerabilities.
- Auto-merge workflow may reduce human review; monitor PR merge strategy.
- Performance claims (e.g., cost savings) lack independent verification; treat with caution.
What does this agent do, and when should you use it?
MoAI-ADK is a single-binary Go harness that wraps Claude Code on macOS, Linux, and Windows. Its central workflow is a SPEC lifecycle: /moai plan creates a specification, /moai run implements it with TDD or DDD, and /moai sync updates documentation and creates a PR. The tool ships TRUST 5 quality gates, an 11-agent catalog for planning, implementation, auditing, documentation, and E2E work, plus Git worktree isolation. It also exposes model-and-effort profiles, a Token Circuit Breaker, a statusline, and handoff records for managing long-running sessions. It fits teams already committed to Claude Code that want an opinionated operational layer around their repository workflow.
moai init detects a project's language, framework, and methodology, then generates Claude Code integration files. From a project directory, the user launches claude and runs /moai plan "Add JWT login", /moai run SPEC-AUTH-001, and /moai sync SPEC-AUTH-001 to author a SPEC, implement it, synchronize documentation, and create a PR. /moai goal and /moai loop drive declarative completion loops and scan LSP diagnostics, AST-grep, and linters in parallel; /moai gate, /moai review, and /moai clean run gates, reviews, and dead-code cleanup. moai cc, moai glm, and moai cg launch Claude-only, GLM-only, or Claude-leader/GLM-worker sessions, while moai worktree manages isolated SPEC worktrees.
- A Claude Code team adding an authentication feature and needing an evidence-oriented plan → run → sync workflow rather than an ad hoc coding session.
- A maintainer of a legacy repository with under 10% test coverage who needs DDD and characterization tests before incremental changes.
- An engineering team running several specifications in parallel and needing separate Git worktrees to prevent overlapping edits.
- A usage-metered team that wants to assign model and reasoning effort differently to planning, implementation, and audit work.
- A team with implementation-heavy tasks that wants Claude to own planning and audits while GLM workers perform bulk implementation.
What are this agent's strengths and limitations?
- Defines a concrete /moai plan → /moai run → /moai sync SPEC lifecycle with verification depth tied to task size.
- Applies TRUST 5 gates across testing, readability, consistency, security, and traceability; the documented testing bar is 85%+ coverage.
- Separates authoring and evaluation through named independent roles such as plan-auditor and sync-auditor.
- Provides model/effort profiles, a Token Circuit Breaker, and a Claude-plus-GLM execution mode for operational cost control.
- Ships as one Go binary with no extra runtime dependencies and documented support for macOS, Linux, and Windows.
- Its core workflow depends on Claude Code, so it is not documented as a standalone coding application, SDK, or provider-neutral agent.
- It requires Git plus a local shell and filesystem workflow; native Windows cmd.exe is explicitly unsupported, with WSL recommended.
- CG mode requires tmux, and GLM use requires a z.ai API key or subscription, adding environment and provider setup.
- The gates rely on a project's available test, lint, and language toolchain; the supplied evidence does not establish equivalent verification coverage for every language.
- Fully-autonomous mode requires sandbox proof and otherwise downgrades to automatic; deny/ask safety rules still apply.
How do you install or deploy this agent?
Install Git and Claude Code first. On macOS, Linux, or WSL:
curl -fsSL https://raw.githubusercontent.com/modu-ai/moai-adk/main/install.sh | bashOn Windows with PowerShell 7.x+:
irm https://raw.githubusercontent.com/modu-ai/moai-adk/main/install.ps1 | iexTo build from source, use Go 1.26+:
git clone https://github.com/modu-ai/moai-adk.git
cd moai-adk && make buildThen initialize a project with moai init my-project. gh is recommended for PR automation; tmux is required for CG mode.
How do you use this agent?
Inside an initialized project, launch Claude Code:
claude
Then run:
/moai plan "Add JWT login"
/moai run SPEC-AUTH-001
/moai sync SPEC-AUTH-001These commands create a SPEC, implement it with TDD or DDD, then synchronize documentation and create a PR. For the GLM backend, save a z.ai API key and enter hybrid mode:
moai glm sk-your-glm-api-key
moai cgUse moai cc for a Claude-only session.
How does this agent compare with similar options?
The documented execution choices are moai cc for Claude-only work, moai glm for GLM-only work, and moai cg for a Claude leader with GLM workers. The README positions Claude-only mode for complex, highest-quality work, GLM-only mode for cost optimization, and CG mode for keeping strategy, planning, and audits with Claude while delegating bulk implementation to GLM.