agentleFS
MicrosoftKnown publishermicrosoft/experiment-catalog/.agents/skills/harness-engineering-playbook/SKILL.md

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

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
  1. Distinctive:

    Use this skill to operationalize the practices from OpenAI's Harness Engineering guide in a repo that agents can run against repeatedly and …

    line 8
  2. Very specific:

    Use references/openai-harness-practices.md for the full practice-to-artifact mapping.

    line 12
  3. Very specific:

    Use references/rollout-checklist.md for phased adoption in active repos.

    line 13
  4. Very specific:

    Use references/wizard-cli.md for Typer wizard command flows.

    line 14
  5. Very specific:

    Use assets/templates/ when creating or updating harness files.

    line 15
  6. Distinctive:

    Run harness audit checks and repair gaps.

    line 28
  7. Very specific:

    Use a short baseline note inside PLANS.md so decisions remain durable.

    line 37
  8. Very specific:

    Ensure hard, high-value tasks are one command away (make smoke, make check, make ci).

    line 80
  9. Distinctive:

    Keep setup and cleanup scripted.

    line 81
  10. Distinctive:

    Keep AGENTS.md short, concrete, and command-first.

    line 86
  11. Distinctive:

    Document non-obvious constraints and guardrails.

    line 87
  12. Distinctive:

    Keep docs close to code and update with behavior changes.

    line 88
  13. Distinctive:

    Prefer one abstraction per module and one clear ownership path.

    line 94
  14. Distinctive:

    Treat context as a first-class system dependency.

    line 104
  15. Very specific:

    Use PLANS.md for multi-step/multi-hour tasks.

    line 105
  16. Distinctive:

    Run static checks before long tests to shorten failure loops.

    line 124
  17. Distinctive:

    Add periodic audits for docs drift, flaky checks, and dead scripts.

    line 128
  18. Distinctive:

    Keep templates synchronized with real workflows.

    line 129
  19. Distinctive:

    Remove stale abstractions quickly to keep agent context clean.

    line 130
  20. Very specific:

    Treat any MISSING or FAIL result as blocking before calling harness setup complete.

    line 142
  21. Very specific:

    Keep AGENTS.md, PLANS.md, and architecture docs aligned with current behavior.

    line 149
  22. Distinctive:

    Do not overwrite user-authored files without explicit approval.

    line 154
  23. Distinctive:

    Keep command names stable.

    line 155

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md for the full practice-to-artifact mapping.
  • Use references/rollout-checklist.md for phased adoption in active repos.
  • Use references/wizard-cli.md for 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

  1. Baseline the repo and detect existing workflows.
  2. Bootstrap harness artifacts and templates.
  3. Apply all nine Harness Engineering practices.
  4. Run harness audit checks and repair gaps.
  5. 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 control

Profiles:

  • 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.md
  • PLANS.md
  • docs/ARCHITECTURE.md
  • docs/OBSERVABILITY.md
  • Makefile.harness (+ -include Makefile.harness in Makefile)
  • scripts/audit_harness.sh
  • scripts/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.md short, 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.md for 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.