Harness Engineer
v4.0.0A persistent autonomous engineering harness runtime that transforms any repository into a self-improving software system. Use this skill whenever the user wa...
⭐ 3· 211·1 current·1 all-time
byLouis Szeto@louis-szeto
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
The name/description (a persistent harness that runs multi-agent development loops) matches the content of SKILL.md and the included documents. The files and templates are all about orchestrating agents, tool routing, testing, and human gates; there are no unexpected requests for cloud credentials, unrelated binaries, or surprising capabilities. The requirement that the host provide an MCP tool router, sandboxed tests, git-scoped credentials, and human gates is proportional to the harness' scope.
Instruction Scope
All runtime instructions operate over repository files and harness docs (CONFIG.yaml, runtime/*, agents/*, MEMORY.md, etc.). The skill explicitly forbids writing protected harness files and mandates blocked reads for sensitive paths. It repeatedly defers sensitive-read/write enforcement to the platform (tool router / sandbox). A minor note: CONFIG.yaml documents higher-priority overrides in ~/.harness and .harness/settings.local.json (and HARNESS_* env vars exist as overrides) — these imply a potential read/merge of user-level config if operator/platform allows it, so verify platform policies around home-directory config access before running.
Install Mechanism
Instruction-only skill with no install spec and no code to execute. This is the lowest-risk install model: nothing is fetched or written by the skill itself. All runtime activity relies on the host's tools and router.
Credentials
The skill declares no required environment variables, no primary credential, and no required config paths. CONFIG.yaml does mention optional overrides via HARNESS_* env vars and user/project-level settings files, but these are optional and documented. There are no disproportionate or unexplained credential requests.
Persistence & Privilege
always:false (not force-included) and the skill documents explicit human approval gates and protected-path write-blocking. However, the skill is designed to be used autonomously (disable-model-invocation:false is standard), so its effectiveness and safety depend on platform-enforced tool routing, sandboxing, and human gates. If the host platform does not implement the required enforcement, autonomous use increases risk.
Assessment
This skill is internally coherent and does what it claims: a multi-agent harness that works by reading repo files and running disciplined cycles. Before installing or enabling autonomous runs you should: 1) Verify your host enforces the MCP tool router semantics described (blocked reads/writes, redaction rules, tool logging). 2) Ensure tests run in a sandbox that cannot access host env vars or harness files. 3) Scope any git tokens so the agent cannot push to main and cannot access other repos. 4) Start with loop_mode: single-pass on a throwaway branch and inspect all generated artifacts (RESEARCH-, PLAN-, PRs, MEMORY.md, docs/generated/) before any merges. 5) Confirm that platform blocks reads of sensitive paths and home-level config if you do not want the harness to see them (the skill references ~/.harness overrides as optional). 6) Do not enable continuous/autonomous mode until you have run at least two clean single-pass cycles and validated tool-router logs and human-gate behavior. The skill is coherent, but its safety is conditional on correct platform enforcement—if your environment cannot provide the router/sandbox/human-gates described, treat the harness as high-risk and run only manual/single-pass with human review.Like a lobster shell, security has layers — review code before you run it.
latestvk975nv76e0wn12k726ehv79x9h843014
License
MIT-0
Free to use, modify, and redistribute. No attribution required.