Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yfge/agent-harness-skills --skill validation-harness-designgit clone --depth 1 https://github.com/yfge/agent-harness-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yfge/agent-harness-skills/validation-harness-design)<a href="https://agentmods.dev/skills/yfge/agent-harness-skills/validation-harness-design"><img src="https://agentmods.dev/badge/skills/yfge/agent-harness-skills/validation-harness-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yfge/agent-harness-skills/validation-harness-design"><img src="https://agentmods.dev/badge/skills/yfge/agent-harness-skills/validation-harness-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00035 | $0.00733 |
| Opus 5 | $0.00017 | $0.00367 |
| Sonnet 5 | $0.00007 | $0.00147 |
| Haiku 4.5 | $0.00003 | $0.00073 |
Grade A, and why
validation-harness-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validation Harness Design
Overview
Define the smallest repeatable command surface that proves repository changes are safe enough for review.
This skill turns scattered checks into commands agents can run, CI can reuse, and failures can diagnose. For shared harness terms, see ../../references/harness-patterns.md; when validation commands are absent, use references/build-when-missing.md. For setup probes and CI-safe fallbacks, see references/environment-bootstrap.md.
When To Use
- The user wants
check_repo_harness.py,doctor.py, a test matrix, or CI gates. - Existing validation commands are scattered and agents do not know what to run for docs-only, interface, service, logic, or runtime changes.
- JSON, JUnit, or artifact output is needed.
Inputs Needed
- Project shape, main surfaces, existing test commands, and CI configuration.
- Change types and the minimum gate for each type.
- Whether runtime, packaged-environment, external-dependency, or manual checks are needed.
Execution Order
- First: Inventory existing commands and CI to confirm what already works.
- Then: Design a layered validation matrix and unified entrypoint.
- Finally: Output the command table, report formats, CI wiring, and fallback rules.
Step-by-Step Process
- Search
package.json, Makefile, scripts, CI workflows, test directories, and docs. - Split validation into repo/docs, contracts, unit/type/lint, runtime, and external-dependency layers.
- If there is no shared validation entrypoint, bootstrap the minimum command surface from
references/build-when-missing.md. - For each change type, choose the minimum command and escalation condition.
- Design a unified entrypoint:
check_repo_harnessordoctorhandles environment/structure, while focused commands test behavior. - Design report output: stdout for humans, JSON/JUnit for CI and artifacts.
- Require skip/fallback reasons; do not describe degraded validation as full validation.
Checks
- Runnable: commands work in a clean checkout or documented setup.
- Layered: docs-only work does not require heavy runtime checks, and runtime changes do not stop at static checks.
- Output: failures identify case, path, command, and artifact.
- CI: local commands and CI logic are consistent.
- Cost: minimum gates are fast, and heavy gates trigger only on higher-risk changes.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 89 lines · 35 tokens per session scan A 5c2c83c5dbbe
validation-harness-design is a skill published in the GitHub repository yfge/agent-harness-skills (10 stars, last pushed 1mo ago), licensed MIT. It adds 35 tokens to every session and 733 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
playwright-testing
E2E testing with Playwright - Page Objects, cross-browser, CI/CD.
qa
Run scalable, isolated live QA for nac development. The top-level local orchestrator must parse n (default 4), dispatch one setup worker with this skill, copy its n assignment contracts verbatim into exactly n parallel test workers with this skill, then dispatch one aggregate worker with this skill using all test…
agentplane-testkit-migration
Use when migrating Agentplane tests to @agentplane/testkit, replacing local test helpers, fixing testkit export/build failures, splitting large CLI/backend suites, or diagnosing missing testkit dist exports in package builds.
e2e-testing-expert
Expert guide for End-to-End (E2E) testing with Playwright, unit/integration testing with Vitest, and CI/CD automated testing pipeline setup / Panduan ahli pengujian End-to-End (E2E) dengan Playwright, pengujian unit/integrasi dengan Vitest, dan otomatisasi CI/CD.
verifying-final-artifacts
Verifies the delivered artifact a consumer actually receives (a figure, chart, PDF, SVG, screenshot, compiled build, or deployed response) by regenerating it fresh and directly observing the output, not the source that produces it, and ends in one honest verdict. Use when the deliverable is a produced artifact and…
stress-testing-agent-changes
Attacks your own agent change, tool grant, dependency, model, or release on purpose, across risk types such as prompt injection, gaining extra power, unsafe output, and tool misuse, and records what you tried, what happened, and the leftover risk. Use when a change widens an agent's power, data access, or network…