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 jimtin/production-ai --skill repo-testing-setupgit clone --depth 1 https://github.com/jimtin/production-aiWrote 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/jimtin/production-ai/repo-testing-setup)<a href="https://agentmods.dev/skills/jimtin/production-ai/repo-testing-setup"><img src="https://agentmods.dev/badge/skills/jimtin/production-ai/repo-testing-setup/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/jimtin/production-ai/repo-testing-setup"><img src="https://agentmods.dev/badge/skills/jimtin/production-ai/repo-testing-setup.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.00189 | $0.02606 |
| Opus 5 | $0.00095 | $0.01303 |
| Sonnet 5 | $0.00038 | $0.00521 |
| Haiku 4.5 | $0.00019 | $0.00261 |
Grade A, and why
repo-testing-setup 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 8d 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 — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Repo Testing Setup
Purpose
Use this skill to design and stand up how a repository proves itself: every test layer containerized, the security toolset wired, hooks enforcing the gates, providers stubbed, and one canonical verify command that means the same thing on every machine.
The default flow is design → confirm → execute. The skill produces a Repo Testing Design, waits for explicit confirmation, then executes the setup in layers — and is finished only when the new canonical gate runs green. The final verdict is one of adopted, adopted-with-exceptions (documented substitutions or deferred items), or blocked.
Pipeline Position
This is the third stage of the build pipeline: $clarify-before-build agrees what to build, $feature-design-preflight designs features against reality, and this skill designs the testing foundation those features will be proven against — before feature implementation begins.
- Consume the upstream artifacts when they exist: the Shared Understanding Contract supplies critical paths, roles, and acceptance criteria; feature readiness notes supply the providers to stub, the failure modes to test, and the E2E workflows to inventory.
- This skill covers testing, validation, and security setup only. Folder layout, package structure, and application scaffolding are not its business — how the repo is organized belongs to the repo; how it proves itself belongs here.
- It runs roughly once per repo. When a repo is already adopted, run the short path: re-audit against the standard and report deltas (
present / partial / missing / substituted / not-applicableper area) instead of redoing setup. - When a repo has a parent or repo-local agent contract that says a standalone PR/release gate owns full proof, choose the gate-owned enforcement model by default: developer hooks stay slim and deterministic, and the standalone gate re-proves the exact candidate SHA. Use hook-owned full pre-push only when the repo contract or user explicitly chooses it.
What ships with it
5 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.
- 8d ago First seen · 106 lines · 189 tokens per session scan A d7b0c0fa010e
repo-testing-setup is a skill published in the GitHub repository jimtin/production-ai (1 stars, last pushed 2mo ago), licensed MIT. It adds 189 tokens to every session and 2,606 once invoked, about $0.0009 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
test-sweep
Run all test suites (unit, integration, API, E2E) and aggregate results into a summary report. Use after completing execution slices or before the Review Gate.
test-software
Design, implement, and evaluate risk-based software tests across unit, integration, contract, end-to-end, and regression layers. Use when adding tests, reproducing bugs, improving coverage, diagnosing flaky tests, or defining a test strategy; do not use to change production behavior unless the user also requests…
codexkit-test-hardening
Strengthen test coverage around changed behavior, edge cases, and regressions without writing noisy or brittle tests.
testing-patterns
Vitest + Playwright testing patterns: unit tests, mocking, fixtures, E2E, coverage, and anti-patterns. Use when writing tests, setting up test infrastructure, or following TDD workflows.
pre-deploy-qa
A pre-deployment acceptance-testing process that runs unit, integration, and end-to-end tests, then checks the acceptance criteria in the user and technical specifications. Acceptance criteria are the conditions a change must meet before it is accepted.
axiom-testing
Use when writing ANY test, debugging flaky tests, making tests faster, or choosing Swift Testing vs XCTest. Covers unit tests, UI tests, async testing, test architecture.