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-blueprintgit 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-blueprint)<a href="https://agentmods.dev/skills/dewtech-technologies/dare-method/dare-blueprint"><img src="https://agentmods.dev/badge/skills/dewtech-technologies/dare-method/dare-blueprint/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-blueprint"><img src="https://agentmods.dev/badge/skills/dewtech-technologies/dare-method/dare-blueprint.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.00048 | $0.03002 |
| Opus 5.5 | $0.00019 | $0.01201 |
| Sonnet 5.5 | $0.00010 | $0.00600 |
| Haiku 4.5 | $0.00005 | $0.00300 |
Grade A, and why
dare-blueprint 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 — 375 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DARE Blueprint Skill
Você é um arquiteto de software especializado em design de APIs e sistemas. Seu objetivo é transformar o Design aprovado em uma arquitetura detalhada que será a base para implementação.
Quando usar esta skill
- Design.md foi aprovado pelo usuário
- Precisa-se detalhar a arquitetura técnica
- Necessário documentar endpoints e modelos
- Segunda fase do Método DARE
Equivalente no terminal:
dare blueprint --ai
Como usar
Passo 1: Ler o Design Aprovado
Leia o arquivo DARE/DESIGN.md que foi aprovado. Extraia:
- Stack técnica
- Funcionalidades principais
- Requisitos não-funcionais
- Restrições
Passo 1b: Trade-offs (Architect)
Antes do scaffold, leia DARE/PATTERNS.md e DARE/patterns-facts.json. Formule perguntas de trade-off ancoradas em padrões reais — cada pergunta cita o id do DiscoveredPattern. 1 passagem sequencial; sem runtime multi-agente. Não invente padrões: só referencie os 🟢 do CLI; conclusões 🟡.
Passo 2: Analisar Contexto
Leia os arquivos de contexto:
.agents/rules/dare-workflow.md(ou.cursorrulesse Cursor)- Exemplos em
examples/ - Templates em
templates/
Passo 3: Integrar Segurança
Consulte skill-security para:
- Autenticação/Autorização
- Validação de entrada
- Criptografia
- Proteção contra vulnerabilidades OWASP
Passo 4: Gerar a Arquitetura
Crie um documento DARE/BLUEPRINT.md com a seguinte estrutura:
# Blueprint: [Nome do Projeto]
## Visão Geral da Arquitetura
[Descrição da arquitetura escolhida: Monolito, Microserviços, Hexagonal, etc]
## Segurança (OWASP)
### Autenticação e Autorização
- Método: JWT com RS256
- Armazenamento: Bearer token no header
- Validação: Middleware em todos os endpoints protegidos
### Proteção de Dados
- Senhas: Bcrypt com salt
- Dados sensíveis: Encriptados em repouso
- Transmissão: HTTPS obrigatório
### Validação
- Input: Whitelist de valores permitidos
- Output: Escape de caracteres especiais
- Rate Limiting: 5 req/min por IP
## Modelo de Dados
### Tabela: users
| Campo | Tipo | Restrições |
|-------|------|-----------|
| id | UUID | PK |
| email | VARCHAR(255) | UNIQUE, NOT NULL |
| password_hash | VARCHAR(255) | NOT NULL (Bcrypt) |
| name | VARCHAR(255) | NOT NULL |
| is_active | BOOLEAN | DEFAULT true |
| created_at | TIMESTAMP | DEFAULT NOW() |
| updated_at | TIMESTAMP | DEFAULT NOW() |
### Tabela: refresh_tokens
| Campo | Tipo | Restrições |
|-------|------|-----------|
| id | UUID | PK |
| user_id | UUID | FK users.id |
| token | VARCHAR(500) | UNIQUE |
| expires_at | TIMESTAMP | NOT NULL |
| revoked_at | TIMESTAMP | NULL |
| created_at | TIMESTAMP | DEFAULT NOW() |
## Endpoints da API
| Método | Endpoint | Autenticação | Descrição |
|--------|----------|--------------|-----------|
| POST | /api/auth/register | Não | Registrar novo usuário |
| POST | /api/auth/login | Não | Login e obter JWT |
| POST | /api/auth/refresh | Não | Renovar JWT com refresh token |
| POST | /api/auth/logout | JWT | Logout e revogar tokens |
| GET | /api/users/me | JWT | Obter dados do usuário logado |
### Detalhes dos Endpoints
#### POST /api/auth/register
**Request:**
```json
{
"email": "[email protected]",
"password": "SecurePass123!",
"name": "John Doe"
}
Response (201):
{
"id": "uuid",
"email": "[email protected]",
"name": "John Doe",
"created_at": "2026-04-14T10:00:00Z"
}
Validações:
- Email válido e único
- Senha: mínimo 8 caracteres, 1 maiúscula, 1 número, 1 caractere especial
- Name: mínimo 3 caracteres
Estrutura de Diretórios
Mantenha esta seção stack-agnóstica. Liste os agrupamentos lógicos (domínio, infraestrutura, interfaces, testes, migrations) e use a nomenclatura idiomática da stack escolhida no
dare init. Os exemplos abaixo cobrem as 5 stacks suportadas — use apenas o bloco da stack do projeto, não os 5 juntos.
projeto/
├── src/
│ ├── auth/
│ │ ├── auth.controller.ts
│ │ ├── auth.service.ts
│ │ ├── auth.module.ts
│ │ └── dto/{register,login}.dto.ts
│ ├── users/{users.entity.ts,users.service.ts}
│ └── main.ts
├── migrations/{001_users.ts,002_refresh_tokens.ts}
└── test/auth.e2e-spec.ts
projeto/
├── src/
│ ├── domain/{user.rs,refresh_token.rs}
│ ├── handlers/{register.rs,login.rs,refresh.rs,logout.rs}
│ ├── middleware/jwt.rs
│ └── main.rs
├── migrations/{001_users.sql,002_refresh_tokens.sql}
└── tests/auth_integration.rs
projeto/
├── app/
│ ├── routers/auth.py
│ ├── models/{user.py,refresh_token.py}
│ ├── schemas/{register.py,login.py}
│ ├── services/auth.py
│ └── main.py
├── alembic/versions/{001_users.py,002_refresh_tokens.py}
└── tests/test_auth.py
projeto/
├── app/Http/Controllers/AuthController.php
├── app/Http/Requests/{RegisterRequest,LoginRequest}.php
├── app/Models/{User,RefreshToken}.php
├── app/Services/AuthService.php
├── database/migrations/{create_users,create_refresh_tokens}_table.php
├── routes/api.php
└── tests/Feature/AuthTest.php
projeto/
├── cmd/server/main.go
├── internal/
│ ├── handlers/{register,login,refresh,logout}.go
│ ├── models/{user,refresh_token}.go
│ └── middleware/jwt.go
├── migrations/{001_users.sql,002_refresh_tokens.sql}
└── handlers_test.go
Plano de Execução
Fase 1: Setup Inicial
- Criar migrations (users, refresh_tokens)
- Configurar autenticação JWT
- Setup de testes
Fase 2: Autenticação
- Implementar RegisterController
- Implementar LoginController
- Implementar RefreshController
Fase 3: Proteção
- Implementar Middleware de JWT
- Implementar Rate Limiting
- Implementar Logout
Fase 4: Testes e Deploy
- Testes unitários
- Testes de integração
- Containerização com Docker
Comandos de Setup
Liste somente os comandos da stack do projeto (definida em
dare init/dare.config.json#backend). Não inclua todos os blocos abaixo — use o que casa com a stack escolhida.
npm install
cp .env.example .env
npm run migration:run
npm test
npm run start:dev
cargo build
cp .env.example .env
sqlx migrate run
cargo test
cargo run
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
alembic upgrade head
pytest
uvicorn app.main:app --reload
composer install
cp .env.example .env
php artisan key:generate
php artisan migrate
php artisan test
php artisan serve
go mod download
cp .env.example .env
migrate -path ./migrations -database "$DATABASE_URL" up
go test ./...
go run ./cmd/server
Próximas Etapas
- Revisar e aprovar este Blueprint
- Executar
/generate-tasks DARE/BLUEPRINT.md - Continuar com o Método DARE
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 · 375 lines · 48 tokens per session scan A 14a321851215
dare-blueprint is a skill published in the GitHub repository dewtech-technologies/dare-method (5 stars, last pushed 3mo ago), licensed MIT. It adds 48 tokens to every session and 3,002 once invoked, about $0.0002 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
writing-skills
Use when creating a new skill for the Shipworthy plugin, or when a recurring failure mode needs to be codified into a reusable guide. Covers TDD-for-documentation, CSO (Claude Search Optimization), adversarial testing, and the full skill lifecycle.
production-readiness
Pre-launch checklist covering security, performance, reliability, legal, SEO, monitoring, backups, and custom domains. Each item has both a plain-language explanation and technical implementation detail. Ensures nothing critical is missed before going live.
design-documents
Formal RFC/design doc template for significant engineering changes. Covers context, goals, non-goals, proposed solution, alternatives considered, data model changes, API changes with backward compatibility analysis, security considerations, performance implications, rollout plan, rollback plan, second-order effects…
compliance-awareness
Practical engineering guidance for SOC 2, GDPR, HIPAA compliance and data classification. Covers access controls, audit logging, change management, right to deletion, data portability, consent, PHI encryption, and data classification levels. Engineering checks, not legal advice.
threat-modeling
Apply the STRIDE framework to identify and mitigate security threats. Covers Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege with practical questions, verification steps, and mitigations for each threat category.
distributed-systems
Apply distributed systems patterns including idempotency, saga pattern, outbox pattern, eventual consistency, and CQRS to build reliable, consistent distributed services.