菜单
Gera um Implementation Plan estruturado a partir de requisitos de usuário. Use quando o usuário descrever uma ideia ou feature que precisa ser desenvolvida. Cria um documento DESIGN.md com requisitos, funcionalidades e restrições.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Camada semântica da extração de DNA do projeto. Roda depois do comando `dare dna` e transforma os fatos de convenção em regras acionáveis no DARE/PROJECT-DNA.md, para o agente seguir o padrão da casa em projetos legados.
Camada semântica da engenharia reversa (Fase 0 / brownfield). Roda depois do comando `dare reverse` e preenche as inferências — propósito, domínio, responsabilidades e diagramas de fluxo — nos artefatos DARE/IDEIA.md e DARE/REVERSE/module-*.md.
Gera um Task List estruturado a partir do Design aprovado. Use quando o usuário aprovar o DESIGN.md. Cria um documento BLUEPRINT.md com arquitetura, endpoints, modelo de dados e plano de execução.
Camada semântica da migração (Fase 2 brownfield). Roda depois do comando `dare migrate` e escreve a estratégia de migração + cenários Gherkin de paridade reais no DARE/MIGRATION/, garantindo reimplementação fiel ao legado.
Analisa complexidade de uma task DARE e, quando alta, quebra em sub-tasks menores. Use após gerar o DAG (para tasks HIGH/CRITICAL), quando o dev pedir refinamento manual, ou quando o escopo mudou e uma task ficou grande. Combina heurística determinística (CLI) com decisão semântica do agente.
Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você).
| name | dare-design |
| description | Gera um Implementation Plan estruturado a partir de requisitos de usuário. Use quando o usuário descrever uma ideia ou feature que precisa ser desenvolvida. Cria um documento DESIGN.md com requisitos, funcionalidades e restrições. |
Você é um especialista em planejamento e análise de requisitos. Seu objetivo é transformar a ideia inicial do usuário em um documento de Design estruturado que servirá como base para as próximas fases do Método DARE.
Equivalente no terminal:
dare design "<description>" --ai
Leia cuidadosamente o que o usuário solicitou. Identifique:
Se dare design --interactive emitiu a seção ## Perguntas de Planejamento (Analyst/PM) no DESIGN.md, leia esse bloco.
Se o bloco de questionário existir, conduza 1 passagem sequencial (sem runtime multi-agente):
Ordem sequencial; sem message pool, sem loop de troca. Inferências 🟡; lacunas 🔴; fatos do CLI 🟢.
Se algo não estiver claro, pergunte ao usuário:
Sempre adicione requisitos de segurança:
Crie um documento DARE/DESIGN.md com a seguinte estrutura:
# Design: [Nome do Projeto]
## Visão Geral
[Descrição clara do projeto]
## Objetivos
- [Objetivo 1]
- [Objetivo 2]
- [Objetivo 3]
## Funcionalidades Principais
### Feature 1: [Nome]
- Descrição
- Casos de uso
### Feature 2: [Nome]
- Descrição
- Casos de uso
## Stack Técnica
- **Backend:** [Linguagem/Framework]
- **Frontend:** [Framework]
- **Banco de Dados:** [BD]
- **Containerização:** Docker
## Requisitos Não-Funcionais
### Segurança
- Autenticação: [Tipo]
- Criptografia: [Tipo]
- Rate Limiting: Sim/Não
- Validação: Estrita
### Performance
- Tempo de resposta: [ms]
- Escalabilidade: [Tipo]
### Confiabilidade
- Uptime: [%]
- Backup: [Frequência]
## Restrições
- [Restrição 1]
- [Restrição 2]
## Fora do Escopo (v1.0)
- [Feature não incluída]
- [Feature não incluída]
## Próximas Etapas
1. Revisar e aprovar este Design
2. Executar `/generate-blueprint DARE/DESIGN.md`
3. Continuar com o Método DARE
Após gerar o Design, peça ao usuário:
# Design: API de Autenticação com JWT
## Visão Geral
Sistema de autenticação robusto com JWT, refresh tokens e proteção contra força bruta.
## Objetivos
- Permitir login seguro de usuários
- Emitir JWT com expiração
- Suportar refresh tokens
- Proteger contra ataques de força bruta
## Funcionalidades Principais
### Feature 1: Login
- Usuário envia email e senha
- Sistema valida credenciais
- Retorna JWT e refresh token
### Feature 2: Refresh Token
- Usuário envia refresh token expirado
- Sistema valida e emite novo JWT
- Refresh token é rotacionado
### Feature 3: Proteção contra Força Bruta
- Máximo 5 tentativas por IP
- Bloqueio de 15 minutos após limite
- Log de tentativas
## Stack Técnica
- **Backend:** Laravel 11 + PHP 8.3
- **Frontend:** Vue.js 3
- **Banco de Dados:** PostgreSQL
- **Containerização:** Docker
## Requisitos Não-Funcionais
### Segurança
- Autenticação: JWT com RS256
- Criptografia: Bcrypt para senhas
- Rate Limiting: 5 tentativas/15min
- Validação: Estrita em todos os endpoints
### Performance
- Tempo de resposta: < 200ms
- Escalabilidade: Horizontal com Redis
## Restrições
- Apenas email/senha (sem OAuth nesta versão)
- Sem 2FA nesta versão
- Sem integração com LDAP
## Fora do Escopo (v1.0)
- Autenticação social (Google, GitHub)
- Two-Factor Authentication
- Biometria
## Próximas Etapas
1. Revisar e aprovar este Design
2. Executar `/generate-blueprint DARE/DESIGN.md`
.cursorrules ou .agents/rules/ para entender a stack do projetoexamples/ para manter consistênciatemplates/DESIGN-template.md como referênciaskill-security para requisitos de segurança