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.
git clone --depth 1 https://github.com/ngocsangyem/MeowKitWrote 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/commands/ngocsangyem/meowkit/test)<a href="https://agentmods.dev/commands/ngocsangyem/meowkit/test"><img src="https://agentmods.dev/badge/commands/ngocsangyem/meowkit/test.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.00000 | $0.00760 |
| Opus 5 | $0.00000 | $0.00380 |
| Sonnet 5 | $0.00000 | $0.00152 |
| Haiku 4.5 | $0.00000 | $0.00076 |
Grade A, and why
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 4d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/test — Test Runner & TDD Enforcement (opt-in)
Usage
/test [optional: specific test file or pattern]
/test --coverage
/test --watch
/test --red-only # Force RED-phase semantics (writes failing tests, no implementation)
/test --tdd # Run with TDD enforcement explicitly enabled for this invocation
Behavior
Runs the test suite. TDD enforcement is opt-in: with --tdd (or when MEOWKIT_TDD=1 is set), the command enforces RED-phase semantics — failing tests must exist before implementation. Without --tdd, the command runs tests when invoked but does NOT block the developer.
For backward compatibility, --red-only still forces the RED-phase write-failing-tests behavior regardless of mode (used by /mk:cook Phase 2 in TDD mode).
Execution Steps
-
Determine scope. If a specific file or pattern is provided, target those tests. Otherwise, detect the current feature context and target related tests.
-
Check if tests exist for the current feature/change.
If NO tests exist:
- Write failing tests first (Phase 2 — RED).
- Tests must target the feature's expected behavior as defined in the approved plan.
- Each test must: run successfully, target a specific behavior, and produce a FAIL result.
- Compilation errors do NOT count as failing tests (per tdd-rules).
- Print: number of tests written and confirmation all are RED.
If tests exist:
- Run the test suite.
- Report results: total, passed, failed, skipped.
- If any fail: print failure details with file, line, expected vs actual.
-
TDD Rules Enforcement (only when
--tdd/MEOWKIT_TDD=1— seerules/tdd-rules.md):- No implementation code before a failing test exists.
- After implementation, ALL existing tests must pass (not just new ones).
- If tests fail after implementation: self-heal up to 3 attempts.
- After 3 failed attempts: stop and escalate to human with failing output, attempted fixes, and suspected root cause.
- Test coverage for new code should match or exceed the project's existing coverage percentage.
- During refactoring: re-run tests after every change.
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.
- 4d ago First seen · 62 lines · 0 tokens per session scan A 853d29ccaecb
test is a command published in the GitHub repository ngocsangyem/MeowKit (14 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 760 tokens. 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-09-03.
Other commands, from other repositories
tdd
A command for test-driven development, a method where you write a failing test first, then code to pass it, and finally improve the code.
kotlin-test
Enforce TDD workflow for Kotlin. Write Kotest tests first, then implement. Verify 80%+ coverage with Kover.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first.
ralph.template
This prompt was authored for Claude-style slash workflows. In Codex runtime, adapt tool calls as follows.
tdd
Run the test-driven development workflow: write failing tests first, then the minimal code to pass.
rust-test
Enforce TDD workflow for Rust. Write tests first, then implement. Verify 80%+ coverage with cargo-llvm-cov.