harness-engineering-playbook
Skill8 starsChanged 5 months agoMITView on GitHub
Implement OpenAI Harness Engineering practices in any repository. Use when setting up or refactoring agent-first workflows, writing or upgrading AGENTS.md and PLANS.md, creating deterministic smoke/test/lint/typecheck harness commands, defining strict architecture boundaries and data-shape contracts, wiring observability from day 1, and adding entropy-control checks plus CI automation for reliable autonomous runs.
2 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- broomva/skillsedited, first seen Jun 13, 2026
- broomva/harness-engineeringedited, first seen Mar 18, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- broomva/harness-engineering★ 2516% same
- broomva/skills★ 497% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 14 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this skill to operationalize the practices from OpenAI's Harness Engineering guide in a repo that agents can run against repeatedly and …
- Very specific: line 12
Use references/openai-harness-practices.md for the full practice-to-artifact mapping.
- Very specific: line 13
Use references/rollout-checklist.md for phased adoption in active repos.
- Very specific: line 14
Use references/wizard-cli.md for Typer wizard command flows.
- Very specific: line 15
Use assets/templates/ when creating or updating harness files.
- Distinctive: line 28
Run harness audit checks and repair gaps.
- Very specific: line 37
Use a short baseline note inside PLANS.md so decisions remain durable.
- Very specific: line 80
Ensure hard, high-value tasks are one command away (make smoke, make check, make ci).
- Distinctive: line 81
Keep setup and cleanup scripted.
- Distinctive: line 86
Keep AGENTS.md short, concrete, and command-first.
- Distinctive: line 87
Document non-obvious constraints and guardrails.
- Distinctive: line 88
Keep docs close to code and update with behavior changes.
- Distinctive: line 94
Prefer one abstraction per module and one clear ownership path.
- Distinctive: line 104
Treat context as a first-class system dependency.
- Very specific: line 105
Use PLANS.md for multi-step/multi-hour tasks.
- Distinctive: line 124
Run static checks before long tests to shorten failure loops.
- Distinctive: line 128
Add periodic audits for docs drift, flaky checks, and dead scripts.
- Distinctive: line 129
Keep templates synchronized with real workflows.
- Distinctive: line 130
Remove stale abstractions quickly to keep agent context clean.
- Very specific: line 142
Treat any MISSING or FAIL result as blocking before calling harness setup complete.
- Very specific: line 149
Keep AGENTS.md, PLANS.md, and architecture docs aligned with current behavior.
- Distinctive: line 154
Do not overwrite user-authored files without explicit approval.
- Distinctive: line 155
Keep command names stable.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Harness Engineering Playbook
Use this skill to operationalize the practices from OpenAI's Harness Engineering guide in a repo that agents can run against repeatedly and safely.
What To Load
- Use
references/openai-harness-practices.mdfor the full practice-to-artifact mapping. - Use
references/rollout-checklist.mdfor phased adoption in active repos. - Use
references/wizard-cli.mdfor Typer wizard command flows. - Use
assets/templates/when creating or updating harness files.
Inputs
- Target repository path.
- Existing command surface (
make,npm,cargo,pytest, etc.). - Existing CI workflows and branch protections.
Workflow
- Baseline the repo and detect existing workflows.
- Bootstrap harness artifacts and templates.
- Apply all nine Harness Engineering practices.
- Run harness audit checks and repair gaps.
- Iterate after real agent runs.
Step 1: Baseline The Repo
- Identify language/toolchain and canonical entrypoints.
- Inventory existing checks, scripts, and CI jobs.
- Record current pain points for agent runs: setup drift, unclear docs, flaky tests, missing trace IDs, slow loops.
Use a short baseline note inside PLANS.md so decisions remain durable.
Step 2: Bootstrap Harness Artifacts
Preferred entrypoint:
python3 scripts/harness_wizard.py init <repo-path> --profile controlProfiles:
baseline: only core harness artifacts.control: baseline + control-system primitives.full: control + entropy controls (nightly audit + entropy checks).
Direct shell fallback:
Run:
./scripts/bootstrap_harness.sh <repo-path>This script installs safe defaults from assets/templates/:
AGENTS.mdPLANS.mddocs/ARCHITECTURE.mddocs/OBSERVABILITY.mdMakefile.harness(+-include Makefile.harnessinMakefile)scripts/audit_harness.shscripts/harness/{smoke,test,lint,typecheck}.sh.github/workflows/harness.yml
By default, existing files are not overwritten. Pass --force to replace template-managed files.
Step 3: Apply The Nine Practices
Implement each practice directly in repo artifacts.
1. Make Easy To Do Hard Thing
- Ensure hard, high-value tasks are one command away (
make smoke,make check,make ci). - Keep setup and cleanup scripted.
- Make smoke checks cheap enough for frequent use.
2. Communicate Actionable Constraints With Compact Docs
- Keep
AGENTS.mdshort, concrete, and command-first. - Document non-obvious constraints and guardrails.
- Keep docs close to code and update with behavior changes.
3. Structure Codebase With Strict Boundaries And Flow
- Define module boundaries in
docs/ARCHITECTURE.md. - Parse and validate data at boundaries; use typed contracts for internal flow.
- Prefer one abstraction per module and one clear ownership path.
4. Build Observability In From Day 1
- Emit structured logs/events with correlation IDs.
- Capture key transitions in long-running workflows.
- Define minimum observable fields in
docs/OBSERVABILITY.md.
5. Optimize For Agent Flow, Not Human Flow
- Treat context as a first-class system dependency.
- Use
PLANS.mdfor multi-step/multi-hour tasks. - Front-load durable context (scope, constraints, checkpoints) so restarts stay cheap.
6. Bring Your Own Harness
- Standardize repo-local wrappers (
Makefile.harness,scripts/harness/). - Wrap local infra actions in deterministic scripts.
- Make agent behavior reproducible across machines and runs.
7. Prototype In Natural Language First
- Draft logic and tests in prose before coding.
- Review edge cases in prose and lock acceptance criteria.
- Translate approved prose into code and tests.
8. Invest In Static Analysis And Linting
- Pin formatter/linter/typechecker versions where practical.
- Enforce checks in both local workflow and CI.
- Run static checks before long tests to shorten failure loops.
9. Manage Entropy
- Add periodic audits for docs drift, flaky checks, and dead scripts.
- Keep templates synchronized with real workflows.
- Remove stale abstractions quickly to keep agent context clean.
For a detailed artifact matrix, load references/openai-harness-practices.md.
Step 4: Validate
Run:
python3 scripts/harness_wizard.py audit <repo-path>Treat any MISSING or FAIL result as blocking before calling harness setup complete.
Step 5: Iterate On Real Runs
- Observe one full agent run from clean checkout to merged change.
- Patch harness gaps immediately.
- Re-run audit.
- Keep
AGENTS.md,PLANS.md, and architecture docs aligned with current behavior.
Adaptation Rules
- Preserve existing project conventions and replace templates incrementally.
- Do not overwrite user-authored files without explicit approval.
- Keep command names stable; change internals behind wrappers.
- Favor deterministic, scriptable workflows over ad-hoc interactive steps.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

