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/luanpdd/kit-mcp/auditar-refactorgit clone --depth 1 https://github.com/luanpdd/kit-mcpWrote 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/luanpdd/kit-mcp/auditar-refactor)<a href="https://agentmods.dev/commands/luanpdd/kit-mcp/auditar-refactor"><img src="https://agentmods.dev/badge/commands/luanpdd/kit-mcp/auditar-refactor.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.00055 | $0.02537 |
| Opus 5 | $0.00028 | $0.01269 |
| Sonnet 5 | $0.00011 | $0.00507 |
| Haiku 4.5 | $0.00006 | $0.00254 |
Grade A, and why
auditar-refactor 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.
How it starts
The opening of the file, as written. The whole thing — 220 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cria/Atualiza:
.planning/REFACTOR-SAFETY.md— relatório com evidências, veredito, caminhos recomendados, audit trail
Após: o user tem decisão objetiva (não gut-feeling) sobre se refactor pode prosseguir. Se BLOCK, oferece 4 caminhos concretos. Se GO-OVERRIDE, registra ticket + reason para débito técnico.
Exemplos:
/auditar-refactor src/orders/handler.ts # default refactor
/auditar-refactor src/orders/handler.ts --change-kind sprout # libera (sprout)
/auditar-refactor src/orders/handler.ts --change-kind safe-extract # libera (mecânico)
/auditar-refactor src/orders/handler.ts \
--change-kind override --ticket REQ-2026-Q2-1234 \
--reason "hot fix de SEV1, char será adicionado em REQ-2026-Q2-1235" # bypass com audit trail
/auditar-refactor src/orders/handler.ts --mode consultive # warning em vez de block
Fluxo típico:
/discutir-fasedetecta refactor intent → automaticamente invoca este comando- Veredito BLOCK → user escolhe um dos 4 caminhos (caracterizar, sprout, safe-extract, override)
- Aplicar caminho + re-rodar este comando até veredito GO
- Refactor executado com confiança
Quando invocar manualmente:
- Antes de planejar fase de refactor
- Antes de PR de refactor de arquivo grande
- Periodicamente em milestones para identificar gaps de coverage
- Como parte de
/auditar-marcoquandoworkflow.audit_milestone_legacy_refactor=true
1. Parsear argumentos
TARGET_FILE=$(echo "$ARGUMENTS" | awk '{print $1}')
CHANGE_KIND=$(echo "$ARGUMENTS" | grep -oE -- '--change-kind [^ ]+' | awk '{print $2}')
MODE=$(echo "$ARGUMENTS" | grep -oE -- '--mode [^ ]+' | awk '{print $2}')
TICKET=$(echo "$ARGUMENTS" | grep -oE -- '--ticket [^ ]+' | awk '{print $2}')
REASON=$(echo "$ARGUMENTS" | grep -oE -- '--reason "[^"]+"' | sed 's/--reason "\(.*\)"/\1/')
OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')
[ -z "$CHANGE_KIND" ] && CHANGE_KIND="refactor"
[ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/REFACTOR-SAFETY.md"
if [ -z "$TARGET_FILE" ]; then
echo "ERROR: target_file é obrigatório."
echo "Uso: /auditar-refactor <target_file> [opções]"
exit 1
fi
if [ ! -f "$TARGET_FILE" ]; then
echo "ERROR: arquivo não encontrado: $TARGET_FILE"
exit 1
fi
# PT-BR: validar override → exige ticket + reason
if [ "$CHANGE_KIND" = "override" ]; then
if [ -z "$TICKET" ] || [ -z "$REASON" ]; then
echo "ERROR: --change-kind=override requer --ticket REQ-N E --reason \"<texto>\"."
echo "Sem audit trail, override é proibido."
exit 1
fi
fi
mkdir -p "$(dirname "$OUTPUT_PATH")"
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 · 220 lines · 55 tokens per session scan A aaaeb100d21c
auditar-refactor is a command published in the GitHub repository luanpdd/kit-mcp (1 stars, last pushed 6d ago), licensed MIT. It adds 55 tokens to every session and 2,537 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-09-03.
Other commands, from other repositories
prompt-evolve
Closed prompt-evolution loop: turn a lesson into a candidate agent prompt, gate it on held-out evals, promote only if it beats the baseline. SIA Meta→Target→Feedback ported to greatcto.
bugfix
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD.
bugfix
TDD-driven bugfix workflow: tester writes failing test (RED) → developer fixes (GREEN) → developer refactors (REFACTOR) → reviewer validates. Accepts issue number, description, or both. Auto-creates PR unless --no-pr flag is passed.
refactor-sprint
Parallel refactor sprint — fires refactor-cleaner + code-simplifier + type-design-analyzer + tdd-guide simultaneously. Full cleanup in one pass.
gentle-sdd-apply
Implement SDD tasks — writes code following specs and design.
session-loop
Automated task consumption loop — parallel TDD implementation, testing, and review per session (session manager procedure).