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 skills add dewtech-technologies/dare-method --skill dare-reviewgit clone --depth 1 https://github.com/dewtech-technologies/dare-methodWrote 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/skills/dewtech-technologies/dare-method/dare-review)<a href="https://agentmods.dev/skills/dewtech-technologies/dare-method/dare-review"><img src="https://agentmods.dev/badge/skills/dewtech-technologies/dare-method/dare-review/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/skills/dewtech-technologies/dare-method/dare-review"><img src="https://agentmods.dev/badge/skills/dewtech-technologies/dare-method/dare-review.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.00092 | $0.01073 |
| Opus 5.5 | $0.00037 | $0.00429 |
| Sonnet 5.5 | $0.00018 | $0.00215 |
| Haiku 4.5 | $0.00009 | $0.00107 |
Grade A, and why
dare-review 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.
How it starts
The opening of the file, as written. The whole thing — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DARE Review Skill
Equivalente no terminal:
dare review <task-id> --ai
Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada realmente entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
Quando usar esta skill
- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
- Quando
dare review <id>estático passa mas precisa validação semântica - Quando o dev pede revisão manual: "revise a task-034"
Camada estática vs semântica
O CLI dare review <id> já faz a camada estática: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada semântica: critério-a-critério da spec contra a implementação real.
Como executar
Passo 1: Rodar a camada estática
dare review <task-id> --format json > .dare/review-static-<task-id>.json
Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
Passo 2: Carregar contexto
DARE/EXECUTION/<task-id>.md— spec da task- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
DARE/BLUEPRINT.md— contratos de API / modelos
Passo 3: Auditoria critério-a-critério
Para cada item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
3.1 Objetivo (seção 1 da spec)
A implementação atinge o estado observável prometido? Encontre evidência concreta.
3.2 Arquivos (seção 3)
- Todos existem com conteúdo descrito?
- Arquivos extras suspeitos?
3.3 Implementação (seção 4)
- Cada passo numerado foi executado?
- Assinaturas exatas correspondem?
- Validações têm regras concretas (não "valida email" — a regex específica)?
3.4 Testes (seção 4 — subitem testes)
- Cada teste listado existe?
- Tem assertions reais (não
assertTrue(true))? - Edge cases enumerados cobertos?
3.5 Segurança (seção 5)
- Input validation conforme spec?
- Não há secrets/tokens hardcoded?
- SQL/Command injection mitigado?
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 · 115 lines · 92 tokens per session scan A 8870b6ab7fa0
dare-review is a skill published in the GitHub repository dewtech-technologies/dare-method (5 stars, last pushed 3mo ago), licensed MIT. It adds 92 tokens to every session and 1,073 once invoked, about $0.0004 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 skills, from other repositories
codex-cross-review
Use when the user wants Codex to review Claude's work, cross-validate PRs, or run high-volume PR review with dual-model verification using the codex-plugin-cc plugin.
confidence-based-strictness
Use when the complexity or unfamiliarity of a task should increase guardrail enforcement. Scales verification depth based on how confident the system is in the correctness of the generated code.
code-complexity
Enforce cyclomatic complexity limits, function/file length limits, nesting depth, parameter counts, and duplication detection. Keeps code readable and maintainable.
requesting-code-review
Invoke the code-reviewer agent with git-based commit ranges to get structured feedback on code quality, architecture compliance, and correctness.
receiving-code-review
Process code review feedback with technical verification — not performative agreement. Fix real issues, push back on incorrect feedback with evidence.
code-review
Reviews code following team development standards. Use when reviewing code, checking PRs, or before merging.