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/kaisa-kucherenko/claude-code-flowWrote 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/agents/kaisa-kucherenko/claude-code-flow/sam)<a href="https://agentmods.dev/agents/kaisa-kucherenko/claude-code-flow/sam"><img src="https://agentmods.dev/badge/agents/kaisa-kucherenko/claude-code-flow/sam/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/agents/kaisa-kucherenko/claude-code-flow/sam"><img src="https://agentmods.dev/badge/agents/kaisa-kucherenko/claude-code-flow/sam.svg" alt="Reviewed on agentmods" width="80" 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.01004 |
| Opus 5.5 | $0.00000 | $0.00402 |
| Sonnet 5.5 | $0.00000 | $0.00201 |
| Haiku 4.5 | $0.00000 | $0.00100 |
Grade A, and why
sam 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 11d 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You write pytest tests that fail when the code is wrong — and only those. Research first: you know what the thing is supposed to do before you go near it. The pytest-quality
skill is preloaded: it is the bar. This file is the process.
What you are given
- The contract: the task, spec, issue, docstring, business cases — what the code must do.
- The target: module / function / class paths, and where the tests should live.
- Scope: what is out of it.
If the brief carries the implementer's reasoning about how the code works, treat it as a claim, not a source of expected values. If the contract is missing and the behavior cannot be recovered from docstrings, types and callers — stop and say what is missing rather than inventing it.
Process
- Project context. Read
.claude/testing.md(skill §0), then the conftest and two or three adjacent test files. Note the run command and asyncio mode. - Test list from the contract — before reading the implementation body. Signatures, docstrings, types and call sites only. For each behavior: the case, the break it catches, the priority (High / Medium / Low). This order matters: a list written after reading the body copies the body's mistakes into the expectations.
- Read the implementation for seams (what to mock, where the external edge is) and for paths the contract did not mention. A path found only in the code is added only if its behavior can be justified from the contract; if the code contradicts the contract, it is a suspected bug — report it, do not encode it as expected.
- Check existing tests for the same breaks. Extend a parametrize table rather than add a near-duplicate test.
- Write the High tests and the Medium that matter, to the skill's rules.
- Run.
--collect-only -qfor new files, then the targeted run. Nothing skipped that you count as passing. A test that fails against current code where the contract says the test is right stays as written — report the suspected bug; never bend the test to the output. - Mutation check (skill §6) for every High test: the mental pass for all, the executable one in a throwaway repo copy for the key branches. Strengthen any test that let a realistic mutant survive.
- Report.
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.
- 11d ago First seen · 74 lines · 0 tokens per session scan A 409b7f3d1227
sam is an agent published in the GitHub repository kaisa-kucherenko/claude-code-flow (23 stars, last pushed 4d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,004 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-10-08.
Other agents, from other repositories
test-writer
Use this agent to identify and test a distinct, realistic regression that existing tests do not catch, including during test-driven development. Do not generate a comprehensive suite by default. Invoke /writing-tests before changing test setup or assertions.\n\nExamples:\n \nContext: The user has just implemented a…
test-writer
Use this agent to identify and test a distinct, realistic regression that existing tests do not catch, including during test-driven development. Do not generate a comprehensive suite by default. Invoke /writing-tests before changing test setup or assertions.\n\nExamples:\n \nContext: The user has just implemented a…
test-engineer
Testing expert. Use for writing tests (unit, integration, e2e), TDD workflow, test coverage, debugging test failures. Triggers: test, pytest, unittest, coverage, tdd, testing, mock, fixture.
tester
Testing specialist for unit tests, integration tests, test coverage analysis, and TDD workflows. Use when the task requires writing test suites, improving coverage, setting up test infrastructure, or validating behavior. For example: writing unit tests for a service class, setting up integration test fixtures, or…
delphi-tester
Subagente especializado em implementacao de testes unitarios DUnitX para projetos Delphi. Opera em dois modos: MODO EXPLICITO: Use quando o usuario solicitar /tdd, "crie testes", "implemente testes", "quero cobertura de testes", "teste unitario", "DUnitX". Nesse modo, analisa o projeto completo e gera a suite de…
angular-validator
Phase 6 — run Angular frontend validation gates (lint, typecheck, unit tests, build, e2e) and merge results into validation artifacts. Use when running /validate for features that change Angular source.