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 agentmods add skills/epicsagas/epic-harness/verifynpx skills add epicsagas/epic-harness --skill verifygit clone --depth 1 https://github.com/epicsagas/epic-harnessWrote 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/epicsagas/epic-harness/verify)<a href="https://agentmods.dev/skills/epicsagas/epic-harness/verify"><img src="https://agentmods.dev/badge/skills/epicsagas/epic-harness/verify.svg" alt="Measured on agentmods" 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.00023 | $0.00692 |
| Opus 5 | $0.00012 | $0.00346 |
| Sonnet 5 | $0.00005 | $0.00138 |
| Haiku 4.5 | $0.00002 | $0.00069 |
Grade A, and why
verify 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 6d 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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify — Pre-Completion Check
Iron Law
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE. "I tested it" without output is an unverified claim.
When to Trigger
- Before a
/gosubagent reports "done" - Before
/shipcreates a PR - Before telling the user "it's ready"
- After any significant code change
Process
1. Build
# Detect and run the project's build command
npm run build # or: go build ./... | cargo build | make
Must exit 0. If it fails, fix before proceeding.
2. Test
# Run the project's test suite
npm test # or: go test ./... | pytest | cargo test
Must exit 0. If tests fail, invoke debug skill.
3. Lint
# Run linter if configured
npm run lint # or: golangci-lint run | ruff check | cargo clippy
Warnings are OK. Errors must be fixed.
4. Type Check (if applicable)
npx tsc --noEmit # TypeScript
mypy . # Python
5. Final Sanity
- No
console.log/printdebug statements left - No
TODOorFIXMEintroduced without explanation - No hardcoded test values or credentials
- All new files are tracked by git
Anti-Rationalization
| Excuse | Rebuttal | What to do instead |
|---|---|---|
| "Tests pass locally" | Did you actually run them? Trust the output, not your memory. | Run npm test right now. Show the output. |
| "I only changed one file" | One file can break the entire build. Imports propagate. | Full build + test. Every time. No exceptions. |
| "Lint warnings aren't errors" | Warnings become errors. Fix them before they multiply. | Zero warnings policy. Fix now or suppress with justification. |
| "CI will catch it" | CI feedback is 5-10 min delayed. Catch it locally in seconds. | Run verify locally before pushing. CI is the safety net, not the test. |
Evidence Required
Before reporting "ready", show ALL of these:
- Build output: exit code 0 (show the command + result)
- Test output: all passing (show summary line)
- Lint output: zero errors (show summary or "clean")
- Type check output: no errors (show
tsc --noEmitor equivalent) - Final sanity: no console.log, no unexplained TODO, no hardcoded values
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.
- 6d ago First seen · 79 lines · 23 tokens per session scan A 2526c2790237
verify is a skill published in the GitHub repository epicsagas/epic-harness (18 stars, last pushed today), licensed Apache-2.0. It adds 23 tokens to every session and 692 once invoked, about $0.0001 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-30.
Other skills, from other repositories
autonomous-loops
Patterns and architectures for autonomous Claude Code loops — from simple sequential pipelines to RFC-driven multi-agent DAG systems.
deployment-patterns
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications. Use when setting up deployment infrastructure or planning releases.
ci-workflow-guide
Guide to SGLang CI workflow orchestration — stage ordering, fast-fail, gating, partitioning, execution modes, and debugging CI failures. Use when modifying CI workflows, adding stages, debugging CI pipeline issues, or understanding how tests are dispatched and gated across stages.
babysit-pr-to-pass-ci
Start and persistently pursue a goal to babysit an SGLang pull request until selected GitHub Actions workflows pass on the latest PR head. Use when asked to monitor, babysit, retry, or fix PR CI for lint.yml, pr-test.yml, pr-test-extra.yml, AMD, or other named workflows; classify failures as PR-related versus flaky or…
sglang-bisect-ci-regression
Investigate consistently failing SGLang CI tests by extracting the failure signature from scheduled or rerun workflows, bisecting the passing/failing commit window, checking runner or hardware specificity, and optionally reproducing on a remote GPU host.
baby-sit
Monitor a GitHub pull request until CI is green, diagnose failures, and rerun only evidence-backed flaky GitHub Actions jobs.