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/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/commands/dewtech-technologies/dare-method/dare-feature-design)<a href="https://agentmods.dev/commands/dewtech-technologies/dare-method/dare-feature-design"><img src="https://agentmods.dev/badge/commands/dewtech-technologies/dare-method/dare-feature-design/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/commands/dewtech-technologies/dare-method/dare-feature-design"><img src="https://agentmods.dev/badge/commands/dewtech-technologies/dare-method/dare-feature-design.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.01351 |
| Opus 5.5 | $0.00000 | $0.00540 |
| Sonnet 5.5 | $0.00000 | $0.00270 |
| Haiku 4.5 | $0.00000 | $0.00135 |
Grade A, and why
dare-feature-design 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 — 148 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/dare-feature-design
Analisa um projeto existente e gera DARE/DESIGN-Feature-[Nome].md focado apenas em adicionar uma nova feature, respeitando a arquitetura legada.
Como usar
/dare-feature-design # interativo
/dare-feature-design "Adicionar 2FA via TOTP no login" # com descrição
Quando usar
- Projeto já existe e usuário pede para adicionar uma feature
- Projeto não nasceu com Método DARE, mas vai adotar para novas funcionalidades
- Feature é grande o suficiente para precisar de planejamento (não é fix de uma linha)
O que fazer
1. Análise de contexto (obrigatória)
Antes de propor qualquer coisa, leia o projeto:
- Stack —
composer.json/package.json/Cargo.toml/go.mod/requirements.txt - Arquitetura — MVC, Hexagonal, CQRS? Layered? Onde moram Controllers, Services, Repositories?
- Banco de dados — leia migrations existentes para entender esquema da feature
- Dependências chave — auth (Sanctum, JWT, Devise?), permissões (Spatie, Pundit?), forms, ORM
- Convenções — naming, estrutura de pastas, padrões de teste
2. Entender a feature
- Valor de negócio — qual problema do usuário resolve?
- Novos endpoints / telas — quais?
- Conexão com o existente — usa que módulos? quem chama?
- Dados novos vs existentes — tabela nova ou só colunas?
3. Avaliar impacto e segurança
- Arquivos novos — controllers, services, repositories, components a criar
- Arquivos modificados — quais existentes vão precisar mudar?
- Banco de dados — migrations + scripts de seed?
- Segurança específica (OWASP) — auth, autorização por recurso, validação, rate limit
- Performance — query nova é cara? cache? índice?
4. Gerar DARE/DESIGN-Feature-[Nome].md
Estrutura obrigatória:
# Feature Design: [Nome da Feature]
## Contexto no Projeto Existente
Resumo de como a feature se encaixa no ecossistema atual.
## Objetivos da Feature
- [O-01] [objetivo 1 com métrica]
- [O-02] [objetivo 2 com métrica]
## Stakeholders
| Papel | Pessoa/Time | Interesse |
|---|---|---|
## Análise de Impacto
### Novos Arquivos
- `app/Controllers/TwoFactorController.php`
- `app/Services/EnrollTotp.php`
- `app/Models/UserMfaSecret.php`
### Arquivos Modificados
- `app/Controllers/AuthController.php` — adiciona challenge step
- `routes/api.php` — novas rotas
### Banco de Dados
- Nova tabela `user_mfa_secrets`
- Coluna `users.mfa_enabled` (boolean default false)
## Requisitos Funcionais
| ID | Requisito | Prioridade | Critério de aceite |
|---|---|---|---|
| RF-01 | … | MUST | … |
## Segurança Específica (OWASP)
- **A01 (Access Control):** [como filtra por owner]
- **A02 (Crypto):** [TOTP secret cifrado at rest]
- **A03 (Injection):** [validações]
- **A07 (Auth):** [rate limit no challenge]
## Restrições e Cuidados
- **NÃO alterar:** [partes do código legado intocáveis]
- **Compatibilidade:** [usuários antigos sem MFA continuam funcionando]
- **Migrations:** [reversível? safe em produção sem downtime?]
## Estratégia de Rollout
- Feature flag `feature.mfa_enabled` default off
- Habilitar para 1% → 10% → 100%
- Rollback = desabilitar flag
## Métricas de Sucesso
- M-01: % de usuários com MFA habilitado após 30 dias
- M-02: queda em logins fraudulentos
- M-03: 0 incidentes de lockout de conta legítima
## Riscos e Mitigações
| Risco | Probabilidade | Impacto | Mitigação |
|---|---|---|---|
## Fora do Escopo (v1)
- WebAuthn (apenas TOTP)
- Backup codes (próxima iteração)
## Próximas Etapas
1. Revisar e aprovar este Feature Design
2. Rodar `/dare-blueprint` apontando para este arquivo
3. Gerar tasks com `/dare-tasks`
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 · 148 lines · 0 tokens per session scan A 28e7a72ebd9d
dare-feature-design is a command published in the GitHub repository dewtech-technologies/dare-method (5 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,351 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-09-03.
Other commands, from other repositories
context
Command "context" from Vimalk0703/shipworthy, covering process, 1. context infrastructure, 2. regression fence health, 3. session signals and 4. context completeness.
diagnose
Command "diagnose" from Vimalk0703/shipworthy, covering process, example output, project diagnosis report, critical (fix immediately) and high (fix soon).
health
Command "health" from Vimalk0703/shipworthy, covering part 1: plugin installation health and part 2: project health.
validate
Command "validate" from Vimalk0703/shipworthy, covering /validate — pre-push validation gate, what this does, steps, when to run and output format.
retro
Command "retro" from Vimalk0703/shipworthy, covering process and important.
audit
Before executing this command, output.