Borrowing it
Nothing to install: this file belongs to nikzlabs/shipit. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/nikzlabs/shipit/main/.agents/skills/testing-and-quality/SKILL.mdgit clone --depth 1 https://github.com/nikzlabs/shipitWrote 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/nikzlabs/shipit/testing-and-quality)<a href="https://agentmods.dev/skills/nikzlabs/shipit/testing-and-quality"><img src="https://agentmods.dev/badge/skills/nikzlabs/shipit/testing-and-quality/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/nikzlabs/shipit/testing-and-quality"><img src="https://agentmods.dev/badge/skills/nikzlabs/shipit/testing-and-quality.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium MCP Rug Pull · line 23 npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.Fix: Pin the version: npx @scope/[email protected]
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.00086 | $0.01799 |
| Opus 5.5 | $0.00034 | $0.00720 |
| Sonnet 5.5 | $0.00017 | $0.00360 |
| Haiku 4.5 | $0.00009 | $0.00180 |
Grade A, and why
testing-and-quality 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Conventions & Quality Checklist
Progressive Testing
During development, use npm run test:dev instead of npm test. This runs:
- Affected tests — tests co-located with files you've changed (uncommitted, staged, and untracked)
- Smoke tests — a small set of critical-path tests that always run
The full suite (npm test) runs in CI on every PR. Only run it locally if you suspect wide-reaching breakage.
| Command | When to use |
|---|---|
npm run test:dev |
Default for development — fast, targeted |
npm run test:dev -- --list |
Dry run — see which files would run |
npm run test:smoke |
Smoke tests only |
npm test |
Full suite — CI runs this, rarely needed locally |
npx vitest run path/to/file.test.ts |
Run a single specific test file |
Smoke tests are defined in scripts/test-dev.ts (the SMOKE_TESTS array). Keep the list small (~4-6 files).
Test Configuration
Tests use Vitest with three project configs in vitest.config.ts:
- Server tests (
src/server/**/*.test.ts) — Node environment - Tooling tests (
scripts/**/*.test.ts) — Node environment - Client tests (
src/client/**/*.test.{ts,tsx}) — jsdom environment with React Testing Library
Server Tests
- Use temp directories (
fs.mkdtempSync) cleaned up inafterEachwithfs.rmSync(tmpDir, { recursive: true, force: true }). - A server test starts with no credential configured.
server-test-setup.tsstrips every cataloguestorageEnvname and everySHIPIT_CREDENTIAL_*variable — eagerly, and again before every test. That covers both sources: the ambient environment (a session container exports the user's real keys into the test process, a CI runner has none — the divergence is invisible in CI, which is whytest-env-hermeticity.test.tspins it against an injected sentinel), and the suite's own writes (storing a credential through the API assigns its mode's variable in-process, so it would otherwise leak into the next test in the file). A test that wants a credential sets it per test or withvi.stubEnv— not inbeforeAll, which the strip runs after. - A
shipit.yamlfixture that does not parse fails the test that wrote it.server-test-setup.tsinstalls a write hook (shared/shipit-config-test-guard.ts) that validates any file namedshipit.yamlwith the product's own parser. The reason is that every opportunistic reader —classifyEmptyDepDirs,staleDepDirs,computeDepsHash,warnOnSkippedInstallOutput— deliberately catches aShipitConfigErrorand returns a conservative empty result, so a malformed fixture makes the check under test evaluate nothing while the assertion still passes. Three dep-dir tests were green that way (planning#480). The classic trap: YAML parses a baretrueas a BOOLEAN, so an install command must be quoted —- "true", never- true. A test that writes an invalid config on purpose wraps the write inexpectInvalidShipitConfig(() => ...), which is also the readable marker that the invalidity is the point. - Testability is built in. Store-backed managers take a
DatabaseManager—SessionManager(dbManager),UsageManager(dbManager),RepoStore(dbManager)— so a test passes an isolated database rather than a temp file path. Filesystem-backed ones still take a directory:GitManager(workspaceDir?). (The oldersessionsFile?/usageFile?/ThreadManager/DeploymentStoresignatures are gone — persistence moved to SQLite.)
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 Changed · +1 lines b96a826be945
- 1mo ago First seen · 126 lines · 86 tokens per session scan A 176f03506b52
testing-and-quality is a skill published in the GitHub repository nikzlabs/shipit (9 stars, last pushed today), licensed Apache-2.0. It adds 86 tokens to every session and 1,799 once invoked, about $0.0003 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
ralph
Self-referential loop until task completion with configurable verification reviewer.
tdd
Test-first at pre-agreed seams — one test, one implementation, tracer-bullet red/green; independent expected values; substitutions only at the seam's boundary class; launch Phase 4 reference.
moai-ref-testing-pyramid
Test pyramid strategy, coverage targets, test patterns, and quality metrics reference. Agent-extending skill that amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns. NOT for: production code implementation, architecture design, DevOps, security audits.
tdd
Build this test-first, one behavior at a time: $ARGUMENTS.
moai-workflow-loop
Ralph Engine - Automated feedback loop with LSP diagnostics and AST-grep integration for continuous code quality improvement. Use when implementing error-driven development, automated fixing, or continuous quality validation workflows.
moai-workflow-testing
Use when writing tests, measuring coverage, or running characterization, performance, or PR-review QA. Comprehensive specialist combining DDD testing, characterization tests, performance profiling, and TRUST 5 quality-assurance validation.