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/hautc-it/cil/testingnpx skills add hautc-it/cil --skill testinggit clone --depth 1 https://github.com/hautc-it/cilWhat 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.00055 | $0.00721 |
| Opus 5 | $0.00028 | $0.00360 |
| Sonnet 5 | $0.00011 | $0.00144 |
| Haiku 4.5 | $0.00006 | $0.00072 |
Grade A, and why
testing 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 yesterday.
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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: Testing
Validate behavior, not implementation.
Project Context
Existing project
- Read
CLAUDE.md— project rules take priority (mock policy, test scope, forbidden patterns). - Identify the test runner — check the project manifest or config files to find what's already installed. Use it — never add a second test framework.
- Read existing tests — find 2–3 test files in the same module. Match their structure: file naming, test block nesting, assertion style, import paths, setup/teardown patterns.
- Check mock policy — does the project use real dependencies in tests, or mocks/stubs? Never introduce a strategy that contradicts what's already in use.
- Search memory —
memory_search("testing [component] conventions")— retrieve prior decisions about test scope or mock strategy. - Apply the protocol below within the project's conventions, not instead of them.
Greenfield project
No tests yet — you are establishing the conventions others will follow:
- Choose the test runner — use the standard one for the language/platform. Don't introduce a less-common alternative without a clear reason.
- Decide file layout upfront — co-located next to source files, or in a separate test directory. Pick one and document it. Changing later requires moving many files.
- Set the mock policy — prefer real dependencies where practical (catches integration bugs); mock only at expensive or unstable external boundaries. Document the policy in
CLAUDE.md. - Write the first test as the template — naming convention, assertion style, setup/teardown — this becomes the pattern every contributor follows.
- Store the decision:
memory_store("decision", "testing: runner=[x], layout=[x], mock policy=[x]", ["testing", "conventions"])
Protocol
- Boundary first — Test the outermost contract (API, function signature, CLI output).
- Happy path — Core case works with valid input.
- Edge cases — Empty input, null, zero, max values, type boundaries.
- Error cases — Invalid input fails with the right error and message.
- Regression — Every bug fix gets a test that would have caught it.
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.
- yesterday First seen · 69 lines · 55 tokens per session scan A 076d9cccf953
testing is a skill published in the GitHub repository hautc-it/cil (1 stars, last pushed 1mo ago), licensed MIT. It adds 55 tokens to every session and 721 once invoked, about $0.0003 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
workflow
Professional AI programming assistant with structured workflow (Research -> Ideate -> Plan -> Execute -> Optimize -> Review) for developers.
r3f-animation
React Three Fiber animation - useFrame, useAnimations, spring physics, keyframes. Use when animating objects, playing GLTF animations, creating procedural motion, or implementing physics-based movement.
r3f-best-practices
React Three Fiber (R3F) and Poimandres ecosystem best practices. Use when writing, reviewing, or optimizing R3F code. Triggers on tasks involving @react-three/fiber, @react-three/drei, zustand, @react-three/postprocessing, @react-three/rapier, or leva.
golden-rss
Use when testing the rss golden build.
agile-product-owner
../../../product-team/agile-product-owner/skills/agile-product-owner/SKILL.md.
golden-chat-topics
Use when testing the goldenchattopics golden build.