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/knowns-dev/knowns/kn-testnpx skills add knowns-dev/knowns --skill kn-testgit clone --depth 1 https://github.com/knowns-dev/knownsWhat 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 | $0.00024 | $0.02434 |
| Opus 5 | $0.00012 | $0.01217 |
| Sonnet 5 | $0.00005 | $0.00487 |
| Haiku 4.5 | $0.00002 | $0.00243 |
Grade A, and why
kn-test 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 3d 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 — 176 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing Tests From Criteria
Announce: "Using kn-test for [task or spec]."
Core principle: A CRITERION IS PROVEN BY A TEST, NOT BY A CLOSED TASK.
Acceptance criteria get checked as bookkeeping — ticked by hand, or synced onto a spec from tasks already closed. Either way that records intent, not evidence. This skill closes the distance between the two: it turns each criterion and scenario into a test that would fail if the behaviour were absent, and reports plainly which criteria still have nothing proving them.
Inputs
- A task, with or without a linked spec
- The spec's
## Scenariosand## Acceptance Criteriawhen one is linked - The implementation being tested, already written
Preflight
- Read the linked spec's Scenarios and Acceptance Criteria in full before writing anything.
- Search for tests that already cover the behaviour. A criterion already proven needs mapping, not a second test.
- Read two or three neighbouring test files in the area you are about to touch. Match what they do rather than what you would do elsewhere.
What This Skill Owns
Deriving cases, writing them, and reporting what remains uncovered.
It does not own the rest of the testing story, and should not duplicate it:
| Concern | Owner |
|---|---|
| Running the suite as part of finishing a task | kn-implement |
| Diagnosing and fixing a failing test | kn-debug |
| Flagging absent tests while reviewing a diff | kn-review |
| Spec-to-task coverage | kn-verify |
You will run tests here to confirm the ones you just wrote actually pass and actually fail for the right reason. That is not the same as owning suite execution.
Step 1: Derive Cases
From a Scenario. Given/When/Then already has the shape of a test: Given is setup, When is the call, Then is the assertion. Translate it directly rather than paraphrasing it into something vaguer.
Given a done task linked to a spec with unchecked ACs
When spec-AC sync runs
Then the matching spec ACs are checked
becomes a test that seeds that task, invokes the sync, and asserts the spec ACs changed. internal/server/routes/tasks_spec_ac_archive_test.go:TestSyncSpecACsCountsArchivedTasks is that shape against the real endpoint.
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.
- 3d ago First seen · 176 lines · 24 tokens per session scan A b113ecd9c2d1
kn-test is a skill published in the GitHub repository knowns-dev/knowns (241 stars, last pushed 7d ago), licensed MIT. It adds 24 tokens to every session and 2,434 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
tdd
Implement a planned Codument work step with a feedback-first, red-green-refactor loop where practical.
lfe-tdd
Red-green-refactor quality pass on code the Builder just wrote. Use in the Builder sub-pipeline after lfe-builder completes implementation.
triage-issue
Invoked helper skill for deep bug diagnosis, usually delegated from /qa when a reported issue needs root-cause analysis and a TDD fix plan before implementation. Use when the cause is unclear, the bug is a regression, or the user explicitly wants diagnosis. Not for lightweight QA intake (use /qa) or already-clear…
tdd
Invoked helper skill for strict red-green-refactor implementation, usually delegated from /execute or bug-fix work shaped by /triage-issue. Use when backend behavior or behavior-heavy frontend logic should be built test-first through public interfaces. Not for shaping, decomposition, vague implementation tasks, or…
vitest-standard
Comprehensive unit testing expertise covering Vitest, test-driven development (TDD), mocking strategies, and production-grade best practices. Activates ONLY for unit testing scope (unit tests, integration tests, Vitest, TDD, Red-Green-Refactor, mocking, stubbing, spying, test coverage, and test architecture in…
tdd
Test-driven development — RED-GREEN-REFACTOR cycle. Auto-triggered during implementation. Write the test first, watch it fail, write minimal code to pass. Also available as /tdd.