harness-engineering — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited harness-engineering (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Patterns for making codebases legible to coding agents and scaling engineering throughput through agent delegation. Full source transcripts are in references/.
The goal is a codebase where agents autonomously produce acceptable code without human intervention.
Score a repository across these seven metrics (each 0-3, max 21):
Can an agent clone the repo and get a working environment with zero external knowledge? Look for: setup scripts, dependency declarations, env templates, seed data.
Is it obvious how to run common operations? Look for: make, just, or script-based commands for build, test, lint, deploy. Agents need discoverable entry points, not tribal knowledge.
Can the agent check whether its changes work? Fast test suites, type checking, snapshot tests. If the agent cannot tell whether its own work is correct, you are back to reviewing everything by hand.
Linting is the highest-leverage, lowest-effort improvement. Agents can check their work cheaply and catch violations before humans see them. Formatters eliminate style noise from diffs. Vibe-code new lint rules to ban specific anti-patterns you observe.
Is there a navigation aid? AGENTS.md, directory-level READMEs, or structured doc trees that help the agent understand what lives where.
Are docs organized close to the code they describe? Progressive disclosure: short pointers in AGENTS.md, detailed docs in subdirectories. The agent should not need to page in a 500-line doc to find the one paragraph it needs.
Is there a record of why things are the way they are? ADRs, .notes/ directories, or commit messages that explain intent. Without these, agents (and new humans) repeat past mistakes.
Keep it lean. The agent should decide what to do, not be over-instructed.
What to include:
file," "use the blessed crypto library, not arbitrary npm packages")
What to omit:
from forming its own judgment)
Hierarchy for larger codebases:
landing changes)
Well-named files and folders matter more than documentation. When the agent searches the codebase, discoverability through naming is the first signal.
"AI slop" is code you don't like. If you can articulate what you don't like, you can encode it as a constraint that prevents it from entering the codebase.
Vibe-code ESLint (or equivalent) rules to statically disallow specific anti-patterns. Example from OpenAI's team: agents kept creating duplicate bounded-concurrency helpers across the codebase, but only the canonical one in async-utils was instrumented with OpenTelemetry. Solution: a lint rule that bans defining that function signature anywhere except the canonical package.
Pattern:
These lint rules stack: each team member adds rules for anti-patterns they catch, and everyone's agents benefit.
Create bespoke code reviewer agents that enforce non-functional requirements. Types that work well:
on network calls
interfaces
checks that changes don't break user journeys
These reviewer agents leave comments on PRs that the authoring agent is forced to address.
For large codebases, context is too large for a single AGENTS.md. Structure it as progressive disclosure:
docs/
├── security.md # 250 lines on security best practices
├── reliability.md # retries, timeouts, circuit breakers
├── frontend-arch.md # component patterns, hook conventions
└── api-conventions.md # endpoint patterns, error formatsAGENTS.md contains short pointers: "For security practices, read docs/security.md." The agent pages in the specific doc it needs for the current task, not all docs for every task.
Skills work the same way: short description in frontmatter triggers loading, full instructions only when invoked. Invest in high-quality descriptions so the agent knows when to invoke each skill.
Each engineer who joins a team brings different expertise. When they encode that expertise into the codebase (lint rules, docs, reviewer agents, skills), every other engineer's agents improve.
Example: a backend-focused engineer couldn't get high-quality React output. When a front-end architect joined and encoded their patterns (one hook per file, small composable components, snapshot testing), everyone's agents started producing better front-end code.
This flywheel compounds: early investment in building blocks (lint rules, test infrastructure, doc standards) yields 3-10x throughput per engineer once the system matures.
Commit messages capture what changed but not why decisions were made during a session. .notes/ is a directory where the agent writes decision rationale as it works, independent of commits. This creates a history you can consult when revisiting code months later: "why was it implemented this way?"
Pair this with specs that live in the repo, not in Slack threads or external tools. When the context behind a decision is in the codebase, agents (and new team members) can find it.
Use git worktrees to run multiple agent sessions on the same repo without stepping on each other's changes. Each worktree is an isolated checkout on its own branch.
Keep previous iterations of completed tasks in an archive folder within the repo. When the agent starts a similar task, it can read previous trajectories to learn what worked and what didn't -- episodic memory without special infrastructure.
Write tests first (or have the agent write them from a product spec), then have the agent implement code to pass them. This gives the agent a clear self-verification loop for long-running sessions without human intervention.
The end state of harness engineering is an orchestrator that manages the full lifecycle:
This removes humans from writing code entirely and moves them to prioritizing work, reviewing work, and refining constraints. The key enabler is having enough guardrails (lint rules, tests, reviewer agents) that the automated loop reliably produces acceptable code.
Schedule recurring agent tasks:
These are lightweight cron-like tasks that keep the codebase healthy without human attention.
Fewer powerful tools > many specialized ones, so agents figure out how without being overly constrained. Example: the Codex team gives the agent a terminal tool (not individual read/write/search tools) and lets it choose standard Unix commands. The exception is security: sandboxing constrains what the agent can do (folder read/write permissions, network access), but within those constraints, the agent has full freedom.
For existing repos without agent infrastructure:
for patterns you don't want.
key conventions. Keep it under 50 lines initially.
local documentation for each domain's best practices.
bullet points about what "good code" looks like for your project. Security, reliability, component architecture. Get a few files in the codebase with the seeds of these standards.
rejection as a lint rule, test, or doc?" If yes, do it. The system improves with every rejection.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.