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/doncheli/don-cheli-sddWrote 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/doncheli/don-cheli-sdd/revisar)<a href="https://agentmods.dev/commands/doncheli/don-cheli-sdd/revisar"><img src="https://agentmods.dev/badge/commands/doncheli/don-cheli-sdd/revisar.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.00082 | $0.02057 |
| Opus 5 | $0.00041 | $0.01028 |
| Sonnet 5 | $0.00016 | $0.00411 |
| Haiku 4.5 | $0.00008 | $0.00206 |
Grade A, and why
revisar 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 5d 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 — 236 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/dc:revisar
Objetivo
Generar un peer review estricto asumiendo el rol de Arquitecto de Software / Lead Developer. Evalúa no solo sintaxis y tests, sino rendimiento, cumplimiento de arquitectura, seguridad y eficiencia algorítmica.
Uso
/dc:revisar
/dc:revisar @specs/features/<dominio>/<Feature>.tasks.md
/dc:revisar --rigor alto # Review de arquitecto senior
/dc:revisar --rigor estandar # Review estándar (default)
/dc:revisar --foco rendimiento # Enfocarse en performance
/dc:revisar --foco seguridad # Enfocarse en seguridad
Dimensiones del Review
1. Corrección Funcional
Verificar:
- [ ] Todos los escenarios Gherkin P1 implementados
- [ ] Escenarios P2 implementados
- [ ] Edge cases cubiertos con tests
- [ ] Sin stubs detectados (habilidad detección-stubs)
- [ ] Criterios de éxito de la spec cumplidos
- [ ] Conformidad con PRD (si existe .dc/prd/):
- Features Must Have implementadas
- Riesgos del PRD mitigados
- KPIs del PRD son medibles en el código
2. Tests y Cobertura
Verificar:
- [ ] Tests unitarios pasan
- [ ] Tests de integración pasan
- [ ] Tests BDD desde Gherkin pasan
- [ ] Cobertura ≥ 85% sobre código nuevo
- [ ] Validación Nyquist: 100% P1, 80% P2
- [ ] Tests verifican comportamiento, no implementación
- [ ] Sin tests frágiles (no dependen de orden, tiempo, estado global)
3. Rendimiento
Detectar:
❌ Consultas N+1 a base de datos
❌ Loops innecesarios sobre datasets grandes (O(n²) evitable)
❌ Falta de paginación en queries que pueden crecer
❌ Objetos grandes en memoria sin liberar
❌ Imports pesados que podrían ser lazy
❌ Re-renders innecesarios (React) o watchers excesivos (Vue)
❌ Falta de índices en queries frecuentes
❌ Serialización/deserialización redundante
4. Arquitectura y Diseño
Verificar:
- [ ] Cumple con constitución (todos los artículos)
- [ ] Principios SOLID respetados (habilidad refactorizacion-solid)
- [ ] Contrato UI respetado (si aplica, habilidad contrato-ui)
- [ ] Sin acoplamiento excesivo entre módulos
- [ ] Dependencias inyectadas (no hardcoded)
- [ ] Separación de concerns (controller thin, service con lógica)
- [ ] Sin código duplicado significativo (>10 líneas)
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.
- 5d ago First seen · 236 lines · 82 tokens per session scan A 1ddd99eb298e
revisar is a command published in the GitHub repository doncheli/don-cheli-sdd (57 stars, last pushed 28d ago), licensed Apache-2.0. It adds 82 tokens to every session and 2,057 once invoked, about $0.0004 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
audit
Review past Claude Code sessions for PBR workflow compliance and UX quality.
review
Run a code review on changed files (or a path you pass).
differential-audit
Audit EARS↔code coherence via a bidirectional differential. With no arguments, opens a scoping conversation that interprets what the user wants audited, maps it to arrows, and captures an explicit EARS selection. With one or more EARS IDs, audits those specs directly using configured defaults. Requires docs/arrows/…
analyze
A command that examines a codebase’s Git history and file structure to find coding patterns and team habits, then records them as reusable documentation.
amby.converge
Check the codebase against spec, plan, and tasks after implementing; append gap tasks, never edit code.
review
You are a helpful coding expert. You MUST provide a detailed, clear, organized and relevant review of the current codebase. If a user direction is provided, you MUST focus the scope of your review to that.