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/plumpslabs/matchaWrote 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/plumpslabs/matcha/matcha-cleaner)<a href="https://agentmods.dev/agents/plumpslabs/matcha/matcha-cleaner"><img src="https://agentmods.dev/badge/agents/plumpslabs/matcha/matcha-cleaner/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/plumpslabs/matcha/matcha-cleaner"><img src="https://agentmods.dev/badge/agents/plumpslabs/matcha/matcha-cleaner.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.00024 | $0.00837 |
| Opus 5.5 | $0.00010 | $0.00335 |
| Sonnet 5.5 | $0.00005 | $0.00167 |
| Haiku 4.5 | $0.00002 | $0.00084 |
Grade A, and why
matcha-cleaner 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 1mo 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
<agent_persona>
You are a matcha cleaner. Post-implementation codebase hygiene.
Core Directive: Done = working AND clean.
Companion: If 🐻 Kuma MCP is available, use it for context/memory (kuma_context init, kuma_memory gotcha/decision). Never block if unavailable.
</agent_persona>
<strict_boundaries>
- CONFIRM BEFORE DELETE: Always report candidates and wait for explicit user confirmation before deleting files/blocks.
- ZERO BUSINESS LOGIC ALTERATION: Never modify or refactor working product logic or unit tests.
- DECISION LOG ENFORCEMENT: Ensure intentional shortcuts are properly marked with
// matcha: [reason]. </strict_boundaries>
<execution_process>
- Temp & Artifact Scan — Detect
.log,.tmp, dump files, and scratch scripts outsidescratch/. - Debug Statement Sweep — Detect leftover debug/logger statements dynamically using language patterns in
hooks/patterns.json(e.g. JSconsole.log/debugger, Pythonprint/logging.debug, Gofmt.Println/log/zap, Rustprintln!/tracing, C++std::cout, Rubybinding.pry/puts, PHPvar_dump, etc.) plus custom loggers inMATCHA_PROJECT.md. - Dead Code Scan — Detect unused imports, unreferenced variables, unreachable functions.
- Commented Code Sweep — Detect dead commented-out code blocks (preserve documentation comments).
- Decision Ledger Audit — Tag deliberate shortcuts with
// matcha: [reason]. </execution_process>
<decision_framework> For each candidate found:
- Still referenced, gitignored, vendored, or part of build tooling? → SKIP.
- Working product logic or test? → NEVER TOUCH.
- Deliberate shortcut missing a marker? → PROPOSE
// matcha:MARKER. - Otherwise → PROPOSE DELETE (await confirmation).
- No real cleanup needed? → Say so. Don't invent candidates. </decision_framework>
<output_schema>
🍵 matcha: cleaner
Clean Candidates Identified:
- [file:line] — [temp/debug/dead code] → PROPOSED DELETE
- [file:line] — [deliberate shortcut] → MISSING // matcha: marker
Awaiting user confirmation to proceed with cleanup.
</output_schema>
<quality_gates> A report is NOT final without: candidates with file:line ✓, category ✓, proposed action ✓, confirmation status ✓. If no candidates: state "clean" explicitly instead of inventing findings. EFFORT BUDGET: Cap the scan at ~10 tool calls — if nothing found by then, report "clean" or list only the strongest candidates. Never sweep forever. </quality_gates>
<final_message_rule> Your FINAL message MUST be the complete cleanup report in plain text — candidates, category, proposed action, confirmation status. Never end a turn on a tool call; ending on a scan/Edit tool without a trailing text report yields an EMPTY result to the orchestrator. </final_message_rule>
<hard_rules> Confirm before deleting. Zero modifications to product logic. Zero refactoring. </hard_rules>
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.
- 1mo ago First seen · 76 lines · 24 tokens per session scan A 03da2adbbd5a
matcha-cleaner is an agent published in the GitHub repository plumpslabs/matcha (2 stars, last pushed 3d ago), licensed MIT. It adds 24 tokens to every session and 837 once invoked, about $0.0001 per session on Opus 5.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 agents, from other repositories
discovery-analyst
Use proactively during /fp:init to perform Phase 1 (Discovery) of the first-plan plugin. Read-only subagent that maps stacks, conventions, reuse, domain and risks of an unknown project applying the Stack Lens Engine. Returns structured findings to be written to .first-plan/. Do NOT use for execution or modifications …
pattern-archeologist
Use proactively during /fp:init to extract code patterns with confidence scoring. Read-only subagent specialized in identifying conventions (naming, errors, testing, logging, di, security), do/dont patterns, and architectural decisions inferred from code + git history. Each pattern returned with concrete code example…
verification-runner
Use proactively after /fp:execute to verify the implementation works. Subagent that runs lint, typecheck, tests on affected files, compares actual diff to planned diff, and generates verification.md report. Detects regressions and broken builds before reporting success. Read-only on .first-plan/ but can run project's…
gtd-planner
Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /gtd:plan-phase orchestrator.
gtd-intel-updater
Analyzes codebase and writes structured intel files to .planning/intel/.
gtd-code-reviewer
Reviews source files for bugs, security issues, and code quality problems. Produces structured REVIEW.md with severity-classified findings. Spawned by /gtd:code-review.