Desenvolvimento Orientado por Intenção

Produza critérios de aceitação úteis sem transformar a especificação em formalidade. Inspecione o contexto disponível primeiro, exponha ambiguidades genuínas e escolha métodos de verificação que se encaixem no trabalho e em seu risco.

Quando Ativar

• O usuário pede para esclarecer um recurso, definir critérios de aceitação ou reduzir o risco de uma alteração antes da implementação.
• A solicitação envolve segurança, autenticação, dados persistentes, migrações, APIs externas ou conformidade.
• O usuário deseja preparar um artefato de entrega para outro agente ou equipe.
• A solicitação é ambígua o suficiente para que o resultado esperado ainda não seja observável ou testável.
• O usuário invoca explicitamente esta habilidade com /intent-driven-development

Não ative para edições triviais, correções diretas de uma linha, sessões de depuração ativas, solicitações de revisão de código ou solicitações de implementação cujas condições de aceitação já estejam claras.

Como Funciona

1. Inspecione o contexto primeiro — lê o repositório, documentação, esquemas e infraestrutura de testes em busca de fatos técnicos antes de fazer qualquer pergunta, tratando as restrições de produto/negócios como algo que apenas o usuário ou um artefato de produto pode fornecer.
2. Escolha a profundidade — seleciona Captura Rápida (3-7 critérios, risco baixo/moderado) ou Briefing de Aceitação Completo (segurança, dados, migração, alterações entre sistemas) com base no perfil de risco.
3. Pergunte minimamente — faz perguntas cujas respostas não podem ser inferidas e que alteram materialmente o escopo ou o comportamento.
4. Escreva critérios observáveis — cada AC-NNN descreve uma condição inicial, gatilho, resultado esperado, efeito colateral proibido, método de verificação e prioridade; sem palavras vagas como "corretamente" ou "seguramente" sem evidências.
5. Prossiga ou entregue — para solicitações claras sem riscos bloqueadores, registra os critérios e continua; para alterações arriscadas, apresenta os bloqueadores e aguarda confirmação.
6. Lide com revisões — se um AC falhar no meio da implementação devido a restrições arquiteturais, marque-o como [revised], atualize o escopo ou o método de verificação, incremente o número da revisão e reapresente apenas os critérios alterados.

Exemplos

Captura Rápida — "Adicionar exportação CSV ao painel"

Goal: Authenticated users can download dashboard data as a CSV file.
In scope: Export of currently filtered rows; filename includes date.
Out of scope: Scheduled exports, email delivery, Excel format.
Assumptions: Max row count is under 10k; no PII in exported fields.

AC-001: Export generates file with correct headers
- Scenario: authenticated user, at least one data row visible
- Action: click "Export CSV"
- Expected: browser downloads file with columns [id, name, created_at]
- Must not: expose internal fields or rows belonging to other users
- Verification: automated integration test + manual schema spot-check
- Priority: Required

Gatilho de Briefing de Aceitação Completo — "Migrar autenticação de usuário para OAuth"

Alteração de autenticação + dependência externa + dados de sessão existentes → Briefing Completo com tabela de Revisão de Risco, decisões bloqueadoras sobre a estratégia de invalidação de sessão e AC de reversão explícito.

Revisão de especificação existente — usuário cola um PRD

A habilidade o revisa em busca de limites de escopo ausentes, requisitos não verificáveis ("o sistema deve ser rápido") e suposições silenciosas, em seguida, retorna critérios corrigidos ou suplementares sem reiniciar a descoberta.

Regras de Operação

1. Inspecione o repositório, documentação, issues, design e contexto de teste disponíveis antes de solicitar fatos técnicos que possam ser descobertos localmente.
2. Não infira restrições de produto ou de negócios a partir do código. Regras de negócios, obrigações de conformidade e regulatórias, SLAs contratuais, precificação, política de retenção de dados, priorização e usuários-alvo não podem ser lidos a partir de um repositório. Trate-os como desconhecidos até que o usuário os forneça ou um artefato de produto autoritativo (PRD, contrato, documento de política) os declare. Registre-os como suposições sinalizadas para confirmação, nunca como fatos descobertos. O repositório informa como o sistema se comporta hoje, não o que o negócio exige que ele faça.
3. Faça apenas perguntas cujas respostas sejam necessárias e não possam ser inferidas com segurança. Agrupe perguntas curtas e relacionadas quando isso economizar turnos desnecessários.
4. Não bloqueie a implementação por padrão. Quando o usuário pediu para implementar uma alteração suficientemente clara, registre suposições e critérios de aceitação chave brevemente, em seguida, prossiga ou entregue-os para o fluxo de trabalho de implementação.
5. Exija confirmação explícita do usuário antes de prosseguir apenas quando uma decisão não resolvida puder

…