Minimal Engineering Harness
A reusable engineering workflow for Claude Code and Codex, installed into a repository rather than pasted into each conversation. Describe a feature, bug or refactor in plain language; the harness supplies instructions for scoping the work, inspecting existing code, implementing a small change, verifying the result and requesting a read-only review. Guard hooks and a shared code index support that process without replacing project-specific judgment.
Part 09 · 6×6 · seats on the baseplate · omegaXiv seats on it
Requirements, architecture, delivery, debugging and review — from one natural-language prompt.
InternalInternal tooling with documented installation and checks, used in omegaXiv. The repository is private. Claude Code and Codex CLI are the supported clients; other agents reading the same files are not a supported compatibility claim.
Node.js · Make · Git submodules · Claude Code · Codex CLI
A coding agent needs more than a task description. It needs to know what already exists, which changes are out of bounds, how to prove the result works and when another reviewer should challenge it. The harness packages those recurring engineering practices so they do not have to be reconstructed for every repository.
It is installed as a Git submodule and materialized into the host project. Shared instructions, client configuration, hooks and skills live alongside the project’s own rules; the installer merges managed sections rather than replacing the surrounding repository.
From request to handoff
Define the observable result
Start with the goal, audience, scope, constraints and concrete acceptance scenarios. Resolve factual questions from the repository and tools; reserve questions for decisions that materially change what gets built.
Locate the change before making it
Use the shared code index to find structure, callers and likely impact, then inspect the relevant source. Reuse existing interfaces and conventions before adding another abstraction or dependency.
Deliver one working slice
Make a small change that produces observable behavior. For a failure, reproduce and diagnose the cause; for a feature, exercise the path a user will actually use. A passing isolated check does not stand in for a working integration.
Review and state the evidence
A read-only reviewer challenges non-trivial work before handoff. Report what was actually exercised, at which evidence level, and what remains unverified instead of treating a plausible diff as completion.
The engineering rules
Match proof to claim
Unit, fake, static, or upstream-smoke evidence is not integration, end-to-end, or live proof. Name the tier and any limitation.
A gate that has never been red is not yet evidence
Prove each gate loads and exercises its target: break what it guards, watch it fail, restore. A green check that could never go red proves nothing.
Ship-state is not code-state
“Done” means a user can do the thing. A green build on a feature nobody can reach is a green build.
Resolve root causes
Never suppress, work around, or defer an error to keep moving.
Derive before you ask
The repository, git history, package registries, vendor docs and installed CLIs answer most factual questions. Ask only what changes what gets built.
What it installs
Always-on instructions
Ground rules both supported clients read on every session, with no command to remember.
Deterministic guard hooks
Pre-tool hooks block covered destructive Git operations and unmanaged Python or pip commands. These are deterministic checks at supported client boundaries, not a sandbox around every possible action.
- git-guard
- py-guard
A read-only reviewer
A subagent invoked automatically before non-trivial handoffs, which ends in either APPROVE or REQUEST_CHANGES.
A persistent code index
One local index shared across clients and sessions, so a new session queries structure instead of re-exploring the repository.
An idempotent installer
Marker-block merging, backups, and drift detection. Hard conflicts abort with a printed plan rather than half-applying.
Adoption and boundaries
The documented existing-project path is harness-install, followed by accepting workspace trust in the client. Later, harness-update pulls and re-materializes shared files; the imported check detects drift. A dry-run can show the install plan before it writes anything, and project-owned prose and configuration keys are preserved.
The default core is deliberately thin. An opt-in checks profile adds environment, architecture, security and change-impact checks; a platform profile adds service scaffolding. Projects still choose and wire their own application gates. The harness is neither a hosted coding service nor a guarantee that an agent’s output is correct.
Everything activates on its own. Describe the task in plain language.
Links & access
The source repository is private. This profile describes the internal workflow; it is not a public release or an independently verified evaluation.
- Page
- 05 of 09
- Part
- 09
- Grade
- internal