eneo-agent-harness
Claude Code marketplace for the Eneo workflow.
TL;DR
- install
eneo-core and eneo-standards
- start work with
/eneo-core:eneo-new "<change>"
- commit through
/eneo-core:eneo-commit "<message>"
- run
/eneo-core:eneo-doctor when the environment feels wrong
- let
eneo-standards enforce TDD, audit, tenancy, and quality gates
What this gives developers
- one shared command flow for small and large changes
- deterministic diagnostics instead of ad hoc shell digging
- fast-lane work that stays light
- stronger checks only when the risk justifies them
The four active plugins
| Plugin | Purpose |
|---|
eneo-core | Main /eneo-* workflow, subagents, and implementation skills |
eneo-standards | Hooks, validators, helper binaries, and status line |
eneo-findings | Findings workflow and learning extraction |
eneo-review | On-demand /eneo-peer-review plus trigger-gated external review agents |
Install
/plugin marketplace add CCimen/eneoplugin
/plugin install eneo-core@eneoplugin
/plugin install eneo-standards@eneoplugin
/plugin install eneo-findings@eneoplugin
/plugin install eneo-review@eneoplugin # optional
/reload-plugins
Then run:
/eneo-core:eneo-doctor
Day-to-day flow
- Fast:
/eneo-new → edit → /eneo-verify → /eneo-commit → /eneo-ship
- Standard:
/eneo-new → /eneo-start → /eneo-verify → /eneo-commit → /eneo-ship
- Deep:
/eneo-new → /eneo-discuss → /eneo-plan → /eneo-start → /eneo-verify → /eneo-commit → /eneo-ship → /eneo-recap
Command discovery note: /help mostly shows built-ins. For plugin commands, type / and filter by eneo, or inspect the plugin in /plugin.
When you want an outside opinion: /eneo-peer-review
/eneo-peer-review is on-demand peer review — invoke it whenever you want a skeptical second pair of eyes on the current diff or task. It is not a hook and never auto-runs.
/eneo-peer-review # review the current diff
/eneo-peer-review "Is this the right ownership boundary?" # plain-language question
/eneo-peer-review plan "Should I implement this slice?"
/eneo-peer-review ready # gates: exits non-zero unless cleared
/eneo-peer-review deep "Challenge tests, API shape, slop." # stronger advisory review
/eneo-peer-review show # last review, reviewer output only
The runner uses Codex if installed, falls back to a fresh-context Claude session, and skips loudly with install hints when neither is available. Iterations are stored under .claude/peer-reviews/<slug>/, and iteration N+1 resumes the reviewer's prior critique by captured session id (never --last). green and ready are aliases that gate the exit code; deep is advisory only — asking for a deeper review never punishes you. See plugins/eneo-review/ for full options and tuning env vars.
What /eneo-commit does
/eneo-commit is the commit-time review step between technical verification and PR creation.
It keeps the workflow split clean:
/eneo-verify proves the change works/eneo-commit reviews the staged commit/eneo-ship opens the PR with the required metadata and evidence
Under the hood, /eneo-commit combines:
- deterministic staged-file and commit-message checks
- a conditional
security-reviewer pass only on risky diffs
- normal
git commit, so the repo's own hooks still remain the source of truth
This improves AI-assisted workflows in particular because it separates deterministic enforcement from advisory review instead of mixing both concerns into a single late-stage step.
Under the hood
The harness is intentionally split:
eneo-core owns workflow and subagentseneo-standards owns runtime enforcementeneo-findings owns backlog capture outside the current taskeneo-review stays quiet until /eneo-verify decides a change is risky enough to justify extra review, or until you run /eneo-peer-review for an on-demand architecture/code review
Why this does not adopt beads / br
The harness already has:
- live flow state in
.claude/state/current-task.json
- authored artifacts in
.claude/phases/ and .claude/recaps/
- GitHub issues / findings for shared backlog work
Adding beads/br to the core flow would introduce another state system to reconcile. If the team later wants it, it should be an optional companion workflow, not a required harness dependency.
Read next
License
MIT
affaan-m
nyldn
wshaddix
xu-xiang