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 commands/mktoronto/python-clean-architecture/scaffold-testsgit clone --depth 1 https://github.com/MKToronto/python-clean-architectureWhat 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.00015 | $0.00713 |
| Opus 5 | $0.00008 | $0.00357 |
| Sonnet 5 | $0.00003 | $0.00143 |
| Haiku 4.5 | $0.00002 | $0.00071 |
Grade A, and why
scaffold-tests 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 2d 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.
What it actually says
Generate tests for the code at $ARGUMENTS (or the current working directory if no path given) using the DataInterfaceStub pattern — no database needed.
Process
-
Read the code — Find and read ALL Python files in the target path recursively. Identify:
- Operations files (business logic functions that accept
DataInterfaceor similar Protocol) - Pydantic models (Create, Read, Update models)
- Any existing test files (to avoid duplication and match existing test conventions)
- Operations files (business logic functions that accept
-
Create DataInterfaceStub — If not already present, generate a
tests/conftest.pywith:from typing import Any DataObject = dict[str, Any] class DataInterfaceStub: def __init__(self): self.data: dict[str, DataObject] = {} def read_by_id(self, id: str) -> DataObject: if id not in self.data: raise KeyError(f"Not found: {id}") return self.data[id] def read_all(self) -> list[DataObject]: return list(self.data.values()) def create(self, data: DataObject) -> DataObject: self.data[data["id"]] = data return data def update(self, id: str, data: DataObject) -> DataObject: if id not in self.data: raise KeyError(f"Not found: {id}") self.data[id].update(data) return self.data[id] def delete(self, id: str) -> None: if id not in self.data: raise KeyError(f"Not found: {id}") del self.data[id] -
Generate test files — For each operations module, create
tests/test_{entity}.pywith:- Happy path tests — create, read, list, update, delete all succeed
- Not-found tests — read/update/delete with invalid ID raises
KeyError - Business logic tests — any computed values (prices, totals, derived fields) verified with known inputs
- Edge cases — empty lists, partial updates (exclude_none), duplicate creation
-
Test structure — Each test file follows:
import pytest from conftest import DataInterfaceStub from operations.{entity} import create_{entity}, read_{entity}, ... @pytest.fixture def stub(): return DataInterfaceStub() def test_create_{entity}(stub): ... def test_read_{entity}_not_found(stub): with pytest.raises(KeyError): ... -
Ask before writing — Use AskUserQuestion to confirm: "Generate these test files?" Show the list of files that will be created.
-
Write the test files — Create all test files in the
tests/directory.
For testing patterns and advanced techniques, consult:
${CLAUDE_PLUGIN_ROOT}/skills/clean-architecture/references/testable-api.md${CLAUDE_PLUGIN_ROOT}/skills/clean-architecture/references/testing-advanced.md${CLAUDE_PLUGIN_ROOT}/skills/clean-architecture/examples/fastapi-hotel-api/(working reference)
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.
- 2d ago First seen · 78 lines · 15 tokens per session scan A fe59e19d7b70
scaffold-tests is a command published in the GitHub repository MKToronto/python-clean-architecture (8 stars, last pushed 2mo ago), licensed MIT. It adds 15 tokens to every session and 713 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-31.
Other commands, from other repositories
verify
Grade work that already exists and decide whether it can merge. Runs the project's current unit, integration, and E2E suites plus security scanning and type checking, scores every dimension 0-10, and returns a merge verdict with a VERIFIED-vs-CLAIMED evidence manifest. Writes no test files and edits no source. Use…
cover
Generate tests that do not exist yet. Analyzes coverage gaps, then writes and runs new test files across three tiers (unit, integration via testcontainers, Playwright E2E), one test-generator agent per tier, healing failures for up to 3 iterations. Use when code has no tests or when raising coverage after…
go-stack.bundb.setup
Instructions to setup the go-stack BunDB integration for database access, migration management, and the bundled DB CLI command.
go-stack.project-update
Compare the current project against the latest go-stack scaffold template and propose or apply updates (tasks, linters, dependencies, skills, provider patterns, security tooling) while preserving project-specific business logic and module identity.
go-stack.inertia.setup
Instructions to setup the go-stack Inertia.js integration for fullstack Go applications, including boot provider wiring and frontend workflow.
local-code-review-tests
Review uncommitted changes, build projects, and run unit tests.