Chachamaru Claude Code Harness — Summary

Claude Code Harness by Chachamaru is the most architecturally complete single-author harness in this batch: a Go-native binary (bin/harness), a TOML-driven config generator (harness.toml), a Claude Code plugin, Codex CLI and OpenCode compatibility paths, 34+ named skills, 4 named subagents, and a runtime hook system with PreToolUse/PermissionRequest/Setup lifecycle events. The central thesis is "Plan→Work→Review→Release as a disciplined delivery loop" — the 5-verb surface (harness-plan, harness-work, harness-review, harness-sync, harness-release) is an enforced workflow gate, not a collection of optional helpers. The Go-native bin/harness binary supplies permission enforcement, inbox checking, and migration reporting outside the Claude Code runtime, making it the only harness in this batch that ships language-native compiled tooling. Worktree-per-agent isolation is declared in the agent definitions (worker.md declares isolation: worktree). TDD is enforced by skill-level --tdd-bypass flag with mandatory audit trail, placing it in the "persona-instruction" enforcement camp but with an escape-valve mechanism. Differs from seeds: closest to superpowers (skills-only behavioral framework) but adds a CLI binary, TOML config layer, named subagents, and multi-tool compatibility that superpowers lacks; closer to kiro in the sense of a holistic delivery harness, but distributed as a Claude Code plugin rather than a closed IDE.

Chachamaru Claude Code Harness — Overview

Origin

GitHub: https://github.com/Chachamaru127/claude-code-harness
Version analyzed: v4.12.3 (from harness.toml)
Language: Shell (primary), Go (binary), with Japanese-first documentation.
Stars: 1,611 as of 2026-05-26.

Philosophy

From the README:

"Claude Code is powerful, but raw agent work drifts: plans live in chat, tests become optional, review happens too late, and release evidence gets rebuilt by memory. Harness turns that into one repeatable operating path."

The stated goal is to shift the user's job from "hand-write the plan" to "approve or correct the generated contract before execution continues." Harness occupies the meta-layer: it frames every agent session as a contract lifecycle (spec.md → Plans.md → implementation → verification → release evidence).

Manifesto-Style Quotes

From README:

"After install, the default changes from 'ask the agent to code' to: 1. write the spec and plan, 2. implement only the approved slice, 3. verify the result, 4. review independently, 5. package evidence for PR or release."

From harness-plan SKILL.md:

"harness-plan は、spec.md product contract and Plans.md task contract の co-required planning output を作る planning surface である."

From agent worker.md:

"推測で要件を足さない。未確認事項は 'missing-input' として明示する." (Do not add requirements by inference. Flag unchecked items as 'missing-input'.)

From harness-work SKILL.md:

"明示的なモードフラグは常にオートモードを上書きする" (Explicit mode flags always override auto-mode selection.)

Key Design Decisions

1. TOML as source of truth: harness.toml is the project config; bin/harness sync regenerates all plugin files from it.
2. Go binary for guardrails: compiled harness binary handles hook dispatch, permission enforcement, and migration reporting without requiring Node.js.
3. 5-verb discipline: the only valid entry points are plan/work/review/sync/release — no catch-all "chat with agent" path.
4. not_observed != absent: missing local proof means "not proven here", not "impossible". A documented epistemic stance.

Chachamaru Claude Code Harness — Architecture

Distribution

• Primary: Claude Code plugin marketplace (/plugin marketplace add Chachamaru127/claude-code-harness)
• Codex CLI: scripts/setup-codex.sh --user
• OpenCode: scripts/setup-opencode.sh
• Cursor / GitHub Copilot CLI: candidate paths (no install evidence yet)

Install Complexity

Multi-step: marketplace add + plugin install + /harness-setup initialization.

Directory Tree

claude-code-harness/
├── .claude-code-harness.config.yaml  # runtime config
├── .claude-plugin/                   # Claude Code plugin manifest
├── .claude/                          # memory/, output-styles/, rules/
├── .codex-plugin/                    # Codex plugin support
├── .cursor/                          # Cursor profile
├── agents/                           # 4 subagent definitions
│   ├── advisor.md
│   ├── reviewer.md
│   ├── scaffolder.md
│   └── worker.md
├── bin/                              # Go binaries
│   ├── harness                       # Universal launcher
│   ├── harness-darwin-amd64
│   ├── harness-darwin-arm64
│   ├── harness-linux-amd64
│   └── harness-windows-amd64.exe
├── codex/                            # Codex-specific files
├── go/                               # Go source
├── hooks/
│   └── hooks.json                    # PreToolUse/PermissionRequest/Setup hooks
├── opencode/                         # OpenCode-specific files
├── output-styles/                    # Output format templates
├── scripts/                          # Setup and migration scripts
├── skills/                           # 34+ skill directories
├── templates/                        # Project templates
├── tests/                            # Test suite
├── workflows/                        # Workflow definitions
├── harness.toml                      # Master config (v4.12.3)
└── spec.md                           # Self-describing spec

Required Runtime

• Claude Code v2.1+ (supported path)
• Go runtime (bundled binary, no install needed)
• No Node.js required

Target AI Tools

Chachamaru Claude Code Harness — Components

Skills (34+)

Agents (4 subagents)

Hooks

File: hooks/hooks.json

Scripts

Config Files

• harness.toml — master configuration, generates plugin files on harness sync
• .claude-code-harness.config.yaml — runtime override config
• claude-code-harness.config.example.json — example config
• claude-code-harness.config.schema.json — JSON schema for config validation

Templates

Located in templates/ — project templates for common patterns.

Chachamaru Claude Code Harness — Uniqueness

differs_from_seeds

Closest to superpowers (skills-as-behavioral-framework, Claude Code plugin) but differs in three significant ways: (1) a compiled Go binary that runs outside the LLM loop as an enforcement engine — superpowers has no binary; (2) named subagent definitions with worktree isolation per worker — superpowers has no named agents; (3) a TOML-driven config system (harness.toml) that generates all plugin files, making the harness itself a meta-level generator. Also resembles kiro in the sense of treating spec.md + Plans.md as a binding contract, but kiro is a closed IDE while Chachamaru distributes as a Claude Code plugin with optional Codex/OpenCode paths. Unlike BMAD-METHOD, the subagents here are not personas but functional roles with strict input/output contracts.

Positioning

This is the most technically complete Claude Code harness in the batch. It occupies a unique position as the only framework in the batch that ships a compiled binary, which means it can enforce constraints at the OS level (process exit codes, file permission checks) rather than relying entirely on the LLM to follow instructions.

Observable Failure Modes

1. Token-intensive: The 5-verb workflow with quality checks at every stage will consume significant context budget. Large Plans.md files may exhaust context before reaching implementation.
2. Japanese-first documentation: Most skill files are bilingual (JP+EN) but detailed reasoning is in Japanese — non-Japanese users may miss nuances.
3. Codex/OpenCode parity gap: "internal-compatible" is weaker than "supported" — the README explicitly warns not to inherit support claims from other projects.
4. TOML indirection: harness.toml as config requires harness sync to apply changes — users who edit plugin files directly will see their changes overwritten.
5. Go binary trust: The compiled binary is distributed as a pre-built artifact; users cannot audit its behavior without reading the Go source.