W4: Feature Dev
O plugin oficial da Anthropic para desenvolvimento de features. Sete fases guiadas com três agentes especializados — projetado para prevenir o erro mais comum: implementar antes de entender.
O que é Feature Dev
Feature Dev é o plugin oficial da Anthropic para o Claude Code, com verificação Anthropic-verified e mais de 143 mil instalações ativas. Ele impõe um processo estruturado de sete fases antes de tocar em qualquer linha de código — o oposto do comportamento padrão onde o agente implementa imediatamente sem explorar o codebase.
O comando de entrada é único e deliberadamente simples. Toda a complexidade do processo é gerenciada internamente pelo plugin:
# Via Claude Code marketplace (recomendado)
/plugin install feature-dev
# Via CLI diretamente
claude plugins install feature-dev
# Uso após instalação
/feature-dev [descrição da feature]
# Exemplos
/feature-dev Adicionar rate limiting por IP na API REST
/feature-dev Migrar autenticação de JWT para OAuth 2.0 com Google
/feature-dev Implementar cache em Redis para consultas de produtosApós a instalação, o plugin fica disponível como slash command em qualquer sessão do Claude Code. Não requer configuração adicional — mas pode ser potencializado com instruções no CLAUDE.md do projeto (ver Seção 5 sobre TDD).
Os 3 agentes especializados
O Feature Dev orquestra três agentes especializados que são ativados em fases específicas do processo. Cada agente tem escopo restrito, o que mantém o contexto controlado e os outputs previsíveis.
code-explorer
- Mapeia a arquitetura existente do projeto
- Traça caminhos de execução relevantes para a feature
- Detecta convenções de nomenclatura, estrutura de pastas e padrões de código
- Identifica dependências e pontos de integração
- Produz um mapa de contexto para os agentes subsequentes
code-architect
- Propõe 2 a 3 estratégias de implementação distintas
- Documenta trade-offs explícitos: complexidade, performance, manutenibilidade
- Avalia compatibilidade com a arquitetura existente
- Seleciona ou solicita aprovação da abordagem preferida
- Respeita padrões detectados pelo code-explorer
code-reviewer
- Revisa o código implementado com confidence scores por finding
- Identifica bugs, edge cases e violações de convenção
- Executa security assessment alinhado ao OWASP Top 10
- Findings com score > 0.8 são classificados como bloqueantes
- Gera lista priorizada de ajustes antes do Final Summary
As 7 fases
O processo do Feature Dev é linear e sequencial. Cada fase tem um gate de conclusão explícito — a próxima fase só começa quando o output da anterior é validado, seja pelo próprio agente ou por confirmação do desenvolvedor.
Fluxo sequencial das 7 fases do Feature Dev — cada fase tem gate de conclusão antes de avançar
FASE 1 — Discovery
Agente: orquestrador
Input: descrição do usuário via /feature-dev
Output: objetivo, usuários-alvo, critérios de aceite preliminares
FASE 2 — Codebase Exploration
Agente: code-explorer
Input: output da Fase 1 + acesso ao codebase
Output: mapa de arquitetura, convenções detectadas, pontos de integração
FASE 3 — Clarifying Questions
Agente: orquestrador
Input: outputs das fases 1 e 2
Output: lista de perguntas → respostas do dev → contexto enriquecido
FASE 4 — Architecture Design
Agente: code-architect
Input: todo o contexto acumulado
Output: 2-3 abordagens com trade-offs → dev aprova uma
FASE 5 — Implementation
Agente: orquestrador (com acesso ao editor)
Input: abordagem aprovada na Fase 4
Output: código implementado, testes (se instruído via TDD)
FASE 6 — Quality Review
Agente: code-reviewer
Input: diff completo da Fase 5
Output: findings com confidence scores, lista de ajustes
FASE 7 — Final Summary
Agente: orquestrador
Input: todas as fases anteriores
Output: o que foi feito, o que mudou, o que testar, PR descriptionFase por fase em detalhe
Discovery
O orquestrador analisa a descrição recebida para extrair o objetivo real da feature, os usuários-alvo e os critérios de aceite preliminares. Nenhum código é lido ou escrito. O output é um brief estruturado que alimenta todas as fases seguintes.
Codebase Exploration
O code-explorer lê o codebase existente, mapeia a arquitetura (camadas, módulos, dependências), traça os caminhos de execução relevantes para a feature e detecta convenções: nomenclatura, estrutura de pastas, padrões de erro, estilo de testes.
Clarifying Questions
Com base no brief e no mapa do codebase, o orquestrador identifica o que ainda não sabe: comportamentos em edge cases, prioridades de design, dependências externas, requisitos não-funcionais. Faz as perguntas ao desenvolvedor e aguarda resposta antes de prosseguir.
Architecture Design
O code-architect propõe 2 a 3 abordagens de implementação distintas. Para cada abordagem: complexidade de implementação, impacto em performance, facilidade de teste, compatibilidade com a arquitetura existente e riscos identificados. O desenvolvedor escolhe uma abordagem antes de seguir para a Fase 5.
Implementation
Execução da abordagem aprovada respeitando as convenções detectadas na Fase 2. Por padrão, o Feature Dev implementa código funcional sem obrigatoriedade de TDD — mas aceita instrução explícita para escrever testes antes da implementação (ver Seção 5).
Quality Review
O code-reviewer analisa o diff completo produzido na Fase 5. Cada finding recebe um confidence score entre 0.0 e 1.0. Scores acima de 0.8 são classificados como bloqueantes — o orquestrador aplica as correções antes de avançar para a Fase 7.
Final Summary
O orquestrador consolida o trabalho de todas as fases em um relatório final: o que foi implementado, quais arquivos foram modificados, quais testes devem ser executados, e uma PR description pronta para uso. Este output é o ponto de handoff para o desenvolvedor.
Aplicando TDD na Fase 5
O Feature Dev não força TDD por padrão. A Fase 5 implementa código funcional diretamente. Para ativar o ciclo Red → Green → Refactor, você precisa instruir explicitamente — no prompt inicial ou no CLAUDE.md do projeto.
RED — escreve o teste que descreve o comportamento esperado; roda a suite e confirma falha.
GREEN — implementa o mínimo necessário para o teste passar; roda novamente.
REFACTOR — limpa o código sem quebrar os testes; roda a suite uma vez mais.
Opção 1: instrução no prompt inicial
# Instrução inline no /feature-dev
/feature-dev Adicionar rate limiting por IP na API REST \
— aplique TDD: escreva cada teste ANTES da implementação correspondente, \
confirme falha, implemente, confirme passagem
# Mais conciso
/feature-dev Autenticação OAuth com Google — TDD-first, Red/Green/RefactorOpção 2: diretiva no CLAUDE.md do projeto
Adicionar no CLAUDE.md garante TDD em todos os /feature-dev do projeto sem repetir a instrução a cada vez:
# CLAUDE.md
## Regras de desenvolvimento
### TDD obrigatório
Toda implementação deve seguir o ciclo TDD:
1. Escreva o teste (deve falhar — confirme com `npm test`)
2. Implemente o mínimo para passar (confirme com `npm test`)
3. Refatore sem quebrar (confirme com `npm test`)
Nunca escreva código de produção sem um teste falhando que o justifique.
### Stack de testes
- Unit/Integration: Vitest (`npx vitest run`)
- E2E: Cypress (`npx cypress run --headless`)
- Cobertura mínima: 80% nas novas featuresOWASP na Fase 6
A Fase 6 inclui um security assessment realizado pelo code-reviewer. Por padrão, o reviewer aplica heurísticas gerais de segurança. Para garantir cobertura explícita do OWASP Top 10 (2021), é necessário um prompt adicional na invocação.
Confidence scores — como interpretar
Cada finding retornado pelo code-reviewer carrega um confidence score de 0.0 a 1.0:
Prompt para cobertura OWASP completa
/feature-dev Implementar upload de arquivos S3 \
— na Fase 6, o code-reviewer deve cobrir explicitamente todos os \
itens do OWASP Top 10 2021: A01-A10, reportar cada um com \
confidence score e aplicar correções nos bloqueantesMapeamento OWASP no Feature Dev
| # | Vulnerabilidade | Gate no Feature Dev |
|---|---|---|
| A01 | Broken Access Control | code-reviewer Fase 6 + testes de autorização na Fase 5 |
| A02 | Cryptographic Failures | code-reviewer audita uso de crypto e gestão de secrets |
| A03 | Injection (SQL, NoSQL, Command) | code-architect Fase 4 + code-reviewer Fase 6 (bloqueante >0.8) |
| A04 | Insecure Design | code-architect Fase 4 documenta threat model na proposta |
| A05 | Security Misconfiguration | code-reviewer Fase 6 audita configurações de produção |
| A06 | Vulnerable Components | npm audit como gate obrigatório pós-Fase 7 |
| A07 | Auth & Session Failures | code-reviewer Fase 6 + revisão de fluxo de autenticação |
| A08 | Integrity Failures | Verificação de integridade de dependências |
| A09 | Logging & Monitoring | code-reviewer verifica ausência de dados sensíveis em logs |
| A10 | SSRF | code-reviewer audita URLs externas e requests de saída |
Pirâmide de testes pós-implementação
O Feature Dev implementa e revisa o código — mas a execução da pirâmide de testes é responsabilidade do desenvolvedor após receber o Final Summary da Fase 7. Este é o handoff esperado: o agente entrega código validado internamente, o dev valida contra o ambiente real.
Sequência após Fase 7
# Sequência completa pós-Fase 7
npx vitest run # unit + integration
npx cypress run --headless # E2E jornadas críticas
k6 run k6/load.js # load test (se API mudou)
npm audit # OWASP A06 — gate obrigatório
gh pr create \
--title "feat: [nome da feature]" \
--body "$(cat .feature-dev-summary.md)" # output da Fase 7Exemplo concreto
Feature real: adicionar autenticação OAuth 2.0 com Google a um backend Node.js/Express com banco Postgres e sessões em Redis. O codebase tem autenticação própria (email + senha) e o desenvolvedor não conhece profundamente os módulos de auth existentes.
Prompt exato para o /feature-dev
/feature-dev Adicionar autenticação OAuth 2.0 com Google ao sistema existente \
de login (email + senha). Os usuários devem poder escolher entre login \
tradicional e login com Google. Sessões em Redis já existem — manter \
compatibilidade. TDD-first na Fase 5. Na Fase 6 cobrir OWASP A01, A02, A07.O que cada fase produziu
FASE 1 — Discovery
Objetivo: login social como alternativa ao tradicional, sem breaking changes
Usuários: todos os existentes + novos com conta Google
Critérios: SSO funcional, sessão unificada com o sistema atual, revogação
FASE 2 — Codebase Exploration (code-explorer)
Arquitetura: Express + Passport.js (local strategy já configurada)
Convenções: controllers em src/controllers/, middlewares em src/middleware/
Padrão de sessão: express-session + connect-redis
Achado crítico: User model sem campo provider — precisa de migração
FASE 3 — Clarifying Questions
P: "Usuários que logaram com email podem vincular Google ao mesmo account?"
R: "Sim, via email como chave de deduplicação."
P: "Qual o comportamento quando o email Google já existe no sistema?"
R: "Vincular automaticamente, não criar conta duplicada."
FASE 4 — Architecture Design (code-architect)
Abordagem A: Passport.js google-oauth20 strategy (extensão natural)
→ compatível com infraestrutura existente, mínimo de novo código
Abordagem B: Biblioteca oauth4webapi direta, sem Passport
→ mais controle, mais código novo, risco de regressão
Aprovada: Abordagem A
FASE 5 — Implementation (TDD-first)
Testes escritos: auth.google.unit.test.ts, auth.google.integration.test.ts
Ciclos Red/Green/Refactor: 4 ciclos
Arquivos criados/modificados:
+ src/strategies/google.strategy.ts
+ src/routes/auth.google.ts
~ src/controllers/auth.controller.ts (extended)
~ prisma/migrations/add_oauth_provider.sql
~ src/middleware/session.middleware.ts
FASE 6 — Quality Review (code-reviewer)
Finding 1: "State parameter ausente no OAuth flow" — score 0.93 (BLOQUEANTE)
→ Corrigido: adicionado CSRF state token com crypto.randomBytes
Finding 2: "Email de verificação Google não validado" — score 0.87 (BLOQUEANTE)
→ Corrigido: verificação de email_verified antes de criar/vincular conta
Finding 3: "Log de email do usuário em debug" — score 0.71
→ Reportado, dev decide manter em desenvolvimentoOutput da Fase 7 (Final Summary)
# Feature: OAuth 2.0 com Google
## O que foi implementado
Autenticação OAuth 2.0 com Google via Passport.js google-oauth20 strategy,
integrada ao sistema de sessões Redis existente. Suporte a vinculação de
contas quando o email Google já existe no sistema (sem duplicatas).
## Arquivos modificados
- src/strategies/google.strategy.ts (novo)
- src/routes/auth.google.ts (novo)
- src/controllers/auth.controller.ts (estendido)
- prisma/migrations/add_oauth_provider.sql (novo)
- src/middleware/session.middleware.ts (atualizado)
## Segurança aplicada
- CSRF state token com crypto.randomBytes(32) no flow OAuth
- Validação de email_verified antes de criar/vincular conta
- Nenhum dado sensível em logs de produção
## O que testar
1. Login com Google em conta nova → cria usuário, sessão ativa
2. Login com Google em email já cadastrado → vincula, não duplica
3. Revogação de token Google → sessão invalidada
4. Tentativa de OAuth sem state → rejeitada com 403
## Variáveis de ambiente necessárias
GOOGLE_CLIENT_ID=...
GOOGLE_CLIENT_SECRET=...
GOOGLE_CALLBACK_URL=https://app.example.com/auth/google/callbackTestes rodados após a Fase 7
npx vitest run --reporter=verbose
# PASS src/__tests__/auth.google.unit.test.ts (8 tests)
# PASS src/__tests__/auth.google.integration.test.ts (5 tests)
npx cypress run --headless --spec "cypress/e2e/auth/**"
# 3 passing (14s)
npm audit
# found 0 vulnerabilities
gh pr create \
--title "feat: OAuth 2.0 com Google (#auth)" \
--body "$(cat .feature-dev-summary.md)"
# https://github.com/org/repo/pull/247Comparação com outros workflows
O Feature Dev não substitui os outros workflows — ele resolve um problema específico: desenvolvimento de uma feature complexa com processo garantido e auditável. Entender onde cada workflow se encaixa evita overhead desnecessário.
| Dimensão | W4: Feature Dev | W1: Claude Code Solo | W2: GSD | W3: Cortex |
|---|---|---|---|---|
| Escopo | Uma feature específica por invocação | Qualquer tarefa, sem estrutura imposta | Múltiplas features / milestones completos | Sessões persistentes com memória cross-session |
| Estrutura | 7 fases fixas com gates obrigatórios | Nenhuma — o dev define a estrutura | Fases definidas no plano do milestone | Contexto acumulado entre sessões, sem fases fixas |
| Agentes | 3 especializados (explorer, architect, reviewer) | Claude Code direto, sem orquestração | Configurável, tipicamente 2-4 agentes | Memória distribuída com subagentes por domínio |
| Memória cross-session | Nenhuma — cada /feature-dev começa do zero | Nenhuma por padrão (CLAUDE.md é estático) | PLAN.md persiste entre sessões | Core do Cortex — memória explícita e versionada |
| Melhor para | Feature nova em codebase desconhecido, features com risco de segurança | Tarefas rápidas, refactoring, debug pontual | Projetos com múltiplas features e linha do tempo definida | Projetos longos onde o contexto acumulado é vantagem |
| Overhead | Alto (7 fases) — justificado pela complexidade | Baixo — começa imediatamente | Médio — planejamento inicial, depois fluido | Médio — custo de manutenção da memória |
/feature-dev quando a feature é complexa o suficiente para justificar as 7 fases. O GSD gerencia o roadmap; o Feature Dev gerencia a qualidade de cada entrega.
Hooks neste workflow
O Feature Dev tem o code-reviewer na Fase 6 — mas o reviewer é probabilístico. Hooks adicionam gates mecânicos que bloqueiam antes do reviewer precisar agir.
settings.json para W4
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [{"type": "command", "command": "node scripts/quality-gate.mjs \"$CLAUDE_TOOL_INPUT_FILE_PATH\""}]
}
],
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [{"type": "command", "command": "node scripts/bash-guard.mjs"}]
}
]
}
}Gate extra — verificar se teste existe antes de nova feature
#!/usr/bin/env node
// require-test.mjs — se um source file novo é criado, deve ter teste correspondente
import { existsSync } from 'node:fs';
import { basename, dirname, extname, join } from 'node:path';
const file = process.argv[2];
if (!file) process.exit(0);
const ext = extname(file);
if (!['.ts', '.js'].includes(ext)) process.exit(0);
if (file.includes('.test.') || file.includes('.spec.') || file.includes('node_modules')) process.exit(0);
// Verifica se existe arquivo de teste correspondente
const base = basename(file, ext);
const dir = dirname(file);
const testPaths = [
join(dir, `${base}.test${ext}`),
join(dir, `${base}.spec${ext}`),
join(dir, '__tests__', `${base}.test${ext}`),
];
const hasTest = testPaths.some(p => existsSync(p));
if (!hasTest) {
console.warn(`[require-test] AVISO: nenhum teste encontrado para ${file}`);
console.warn(`[require-test] Esperado: ${testPaths[0]}`);
// warn apenas, não bloqueia — Feature Dev pode criar teste em seguida
}Scripts completos no Módulo 22 — Fundamentos.