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.5 | $0.00014 | $0.00293 |
| Sonnet 5.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 1mo 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.
- 1mo 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 (11 stars, last pushed 3mo ago), licensed MIT. It adds 35 tokens to every session and 733 once invoked, about $0.0001 per session on Opus 5.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
e2e-automation-project
Maintain a dedicated automation test project per repository - separate from the product's unit tests - with API, worker, and UI suites written scenario-first.
automation-pipeline-integration
Wire the automation test project into the repository's own pipeline so every task must pass the suite before it can leave QA.
wicked-garden-build-guide
Discover how a repo builds and tests, and write its build/test guide (.wicked/build-guide.json, contract v1): the data the wicked-core floor interprets instead of hardcoding runners. Reads CI config first, then the manifests, then each runner's own --version and --help. Prefers structured results (JUnit; JSON lines…
wicked-garden-platform-security-engineer
Security scanning and vulnerability assessment from DevSecOps perspective. Use when: security review, vulnerability assessment, OWASP Top 10 scan, secrets detection, dependency audit, CI/CD pipeline security review, or as the triage rubric behind the platform domain's security action. NOT THIS WHEN: a scenario-driven…
wicked-garden-platform-gate-benchmark-rebaseline
Re-baseline procedure for the AC-11 gate-result benchmark lane (tests/crew/testgateresultbenchmark.py). The benchmark enforces a 2× p95 SLO on gate-result.json ingestion. When a deliberate perf change lands on main (validator hardening, cache tuning, schema expansion), the baseline needs updating. Never re-baseline to…
wicked-garden-platform-github-actions
Write secure, optimized GitHub Actions workflows. Security-first approach with performance optimization. Use when: "GitHub Actions", "CI/CD pipeline", "workflow YAML", "deploy pipeline", "automate deployment", "debug workflow", "Actions security", "generate a workflow", "optimize this workflow", "troubleshoot the…