prompt-optimizer

Prompt Optimizer

Analise um rascunho de prompt, critique-o, associe-o a componentes do ecossistema ECC e gere um prompt otimizado e completo que o usuário possa copiar e executar.

Quando Usar

• O usuário diz "otimize este prompt", "melhore meu prompt", "reescreva este prompt"
• O usuário diz "me ajude a escrever um prompt melhor para..."
• O usuário diz "qual a melhor forma de perguntar ao Claude Code para..."
• O usuário diz "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
• O usuário cola um rascunho de prompt e pede feedback ou aprimoramento
• O usuário diz "não sei como criar um prompt para isso"
• O usuário diz "como devo usar o ECC para..."
• O usuário invoca explicitamente /prompt-optimize

Não Usar Quando

• O usuário quer que a tarefa seja feita diretamente (apenas execute-a)
• O usuário diz "优化代码", "优化性能", "otimize este código", "otimize o desempenho" — são tarefas de refatoração, não de otimização de prompt
• O usuário está perguntando sobre configuração do ECC (use configure-ecc)
• O usuário quer um inventário de skills (use skill-stocktake)
• O usuário diz "apenas faça" ou "直接做"

Como Funciona

Apenas consultivo — não execute a tarefa do usuário.

NÃO escreva código, crie arquivos, execute comandos ou tome qualquer ação de implementação. Sua ÚNICA saída é uma análise mais um prompt otimizado.

Se o usuário disser "apenas faça", "直接做" ou "não otimize, apenas execute", não mude para o modo de implementação dentro desta skill. Informe ao usuário que esta skill apenas produz prompts otimizados e instrua-o a fazer uma solicitação de tarefa normal se quiser execução.

Execute este pipeline de 6 fases sequencialmente. Apresente os resultados usando o Formato de Saída abaixo.

Pipeline de Análise

Fase 0: Detecção de Projeto

Antes de analisar o prompt, detecte o contexto do projeto atual:

1. Verifique se existe um arquivo CLAUDE.md no diretório de trabalho — leia-o para obter as convenções do projeto
2. Detecte a pilha de tecnologia a partir dos arquivos do projeto:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin (em seguida, verifique se há quarkus no arquivo de build → Quarkus, ou spring-boot → Spring Boot)
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. Anote a pilha de tecnologia detectada para uso nas Fases 3 e 4

Se nenhum arquivo de projeto for encontrado (por exemplo, o prompt é abstrato ou para um novo projeto), pule a detecção e sinalize "pilha de tecnologia desconhecida" na Fase 4.

Fase 1: Detecção de Intenção

Classifique a tarefa do usuário em uma ou mais categorias:

Categoria	Palavras-chave	Exemplo
Nova Funcionalidade	construir, criar, adicionar, implementar, 创建, 实现, 添加	"Criar uma página de login"
Correção de Bug	corrigir, quebrado, não funciona, erro, 修复, 报错	"Corrigir o fluxo de autenticação"
Refatoração	refatorar, limpar, reestruturar, 重构, 整理	"Refatorar a camada de API"
Pesquisa	como fazer, o que é, explorar, investigar, 怎么, 如何	"Como adicionar SSO"
Testes	testar, cobertura, verificar, 测试, 覆盖率	"Adicionar testes para o carrinho"
Revisão	revisar, auditar, verificar, 审查, 检查	"Revisar meu PR"
Documentação	documentar, atualizar docs, 文档	"Atualizar a documentação da API"
Infraestrutura	implantar, CI, docker, banco de dados, 部署, 数据库	"Configurar pipeline CI/CD"
Design	projetar, arquitetura, planejar, 设计, 架构	"Projetar o modelo de dados"

Fase 2: Avaliação de Escopo

Se a Fase 0 detectou um projeto, use o tamanho da base de código como sinal. Caso contrário, estime apenas a partir da descrição do prompt e marque a estimativa como incerta.

Escopo	Heurística	Orquestração
TRIVIAL	Arquivo único, < 50 linhas	Execução direta
BAIXO	Componente ou módulo único	Comando ou skill único
MÉDIO	Múltiplos componentes, mesmo domínio	Cadeia de comandos + /verify
ALTO	Entre domínios, 5+ arquivos	/plan primeiro, depois execução em fases
ÉPICO	Multi-sessão, multi-PR, mudança arquitetural	Use a skill blueprint para plano multi-sessão

Fase 3: Mapeamento de Componentes ECC

Mapeie intenção + escopo + pilha de tecnologia (da Fase 0) para componentes ECC específicos.

Por Tipo de Intenção

Intenção	Comandos	Skills	Agentes
Nova Funcionalidade	/plan, /tdd, /code-review, /verify	tdd-workflow, verification-loop	planner, tdd-guide, code-reviewer
Correção de Bug	/tdd, /build-fix, /verify	tdd-workflow	tdd-guide, build-error-resolver
Refatoração	/refactor-clean, /code-review, /verify	verification-loop	refactor-cleaner, code-reviewer
Pesquisa	/plan	search-first, iterative-retrieval	—
Testes	/tdd, /e2e, /test-coverage	tdd-workflow, e2e-testing	tdd-guide, e2e-runner
Revisão	/code-review	security-review	code-reviewer, security-reviewer
Documentação	/update-docs, /update-codemaps	—	doc-updater
Infraestrutura	/plan, /verify	docker-patterns, deployment-patterns, database-migrations	architect
Design (MÉDIO-ALTO)	/plan	—	planner, architect
Design (ÉPICO)	—	blueprint (invocar como skill)	planner, architect

Por Pilha de Tecnologia

Pilha de Tecnologia	Skills a Adicionar	Agente
Python / Django	django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing	python-reviewer
Go	golang-patterns, golang-testing	go-reviewer, go-build-resolver
Spring Boot / Java	springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns	java-reviewer
Quarkus / Java	quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns	java-reviewer
Kotlin / Android	kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture	kotlin-reviewer
TypeScript / React	frontend-patterns, backend-patterns, coding-standards	code-reviewer
Swift / iOS	swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing	code-reviewer
PostgreSQL	postgres-patterns, database-migrations	database-reviewer
Perl	perl-patterns, perl-testing, perl-security	code-reviewer
C++	cpp-coding-standards, cpp-testing	code-reviewer
Outros / Não Listados	coding-standards (universal)	code-reviewer

Fase 4: Detecção de Contexto Ausente

Examine o prompt em busca de informações críticas ausentes. Verifique cada item e marque se a Fase 0 o detectou automaticamente ou se o usuário deve fornecê-lo:

• Pilha de tecnologia — Detectada na Fase 0, ou o usuário precisa especificar?
• Escopo alvo — Arquivos, diretórios ou módulos mencionados?
• Critérios de aceitação — Como saber se a tarefa está concluída?
• Tratamento de erros — Casos extremos e modos de falha abordados?
• Requisitos de segurança — Autenticação, validação de entrada, segredos?
• Expectativas de teste — Unitário, integração, E2E?
• Restrições de desempenho — Carga, latência, limites de recursos?
• Requisitos de UI/UX — Especificações de design, responsivo, acessibilidade? (se frontend)
• Alterações no banco de dados — Esquema, migrações, índices? (se camada de dados)
• Padrões existentes — Arquivos de referência ou convenções a seguir?
• Limites do escopo — O que NÃO fazer?

Se 3+ itens críticos estiverem ausentes, faça ao usuário até 3 perguntas de esclarecimento antes de gerar o prompt otimizado. Em seguida, incorpore as respostas no prompt otimizado.

Fase 5: Recomendação de Workflow e Modelo

Determine onde este prompt se encaixa no ciclo de vida do desenvolvimento:

Pesquisa → Planejar → Implementar (TDD) → Revisar → Verificar → Confirmar

Para tarefas MÉDIAS+, sempre comece com /plan. Para tarefas ÉPICAS, use a skill blueprint.

Recomendação de modelo (incluir na saída):

Escopo	Modelo Recomendado	Justificativa
TRIVIAL-BAIXO	Sonnet 5	Rápido, econômico para tarefas simples
MÉDIO	Sonnet 5	Melhor modelo de codificação para trabalho padrão
ALTO	Sonnet 5 (principal) + Opus 5 (planejamento)	Opus para arquitetura, Sonnet para implementação
ÉPICO	Opus 5 (blueprint) + Sonnet 5 (execução)	Raciocínio profundo para planejamento multi-sessão

Divisão multi-prompt (para escopo ALTO/ÉPICO):

Para tarefas que excedem uma única sessão, divida em prompts sequenciais:

• Prompt 1: Pesquisa + Planejamento (use a skill search-first, depois /plan)
• Prompt 2-N: Implemente uma fase por prompt (cada um termina com /verify)
• Prompt Final: Teste de integração + /code-review em todas as fases
• Use /save-session e /resume-session para preservar o contexto entre as sessões

---

Formato de Saída

Apresente sua análise nesta estrutura exata. Responda no mesmo idioma da entrada do usuário.

Seção 1: Diagnóstico do Prompt

Pontos Fortes: Liste o que o prompt original faz bem.

Problemas:

Problema	Impacto	Correção Sugerida
(problema)	(consequência)	(como corrigir)

Precisa de Esclarecimento: Lista numerada de perguntas que o usuário deve responder. Se a Fase 0 detectou automaticamente a resposta, informe-a em vez de perguntar.

Seção 2: Componentes ECC Recomendados

Tipo	Componente	Propósito
Comando	/plan	Planejar arquitetura antes de codificar
Skill	tdd-workflow	Orientação sobre metodologia TDD
Agente	code-reviewer	Revisão pós-implementação
Modelo	Sonnet 5	Recomendado para este escopo

Seção 3: Prompt Otimizado — Versão Completa

Apresente o prompt otimizado completo dentro de um único bloco de código com cerca. O prompt deve ser autocontido e pronto para copiar e colar. Inclua:

• Descrição clara da tarefa com contexto
• Pilha de tecnologia (detectada ou especificada)
• Invocações de /comando nos estágios corretos do workflow
• Critérios de aceitação
• Etapas de verificação
• Limites do escopo (o que NÃO fazer)

Para itens que referenciam blueprint, escreva: "Use a skill blueprint para..." (não /blueprint, já que blueprint é uma skill, não um comando).

Seção 4: Prompt Otimizado — Versão Rápida

Uma versão compacta para usuários experientes do ECC. Varie por tipo de intenção:

Intenção	Padrão Rápido
Nova Funcionalidade	/plan [funcionalidade]. /tdd para implementar. /code-review. /verify.
Correção de Bug	/tdd — escrever teste falho para [bug]. Corrigir até ficar verde. /verify.
Refatoração	/refactor-clean [escopo]. /code-review. /verify.
Pesquisa	Use a skill search-first para [tópico]. /plan com base nos resultados.
Testes	/tdd [módulo]. /e2e para fluxos críticos. /test-coverage.
Revisão	/code-review. Em seguida, use o agente security-reviewer.
Documentação	/update-docs. /update-codemaps.
ÉPICO	Use a skill blueprint para "[objetivo]". Execute as fases com gates /verify.

Seção 5: Justificativa dos Aprimoramentos

Aprimoramento	Motivo
(o que foi adicionado)	(por que é importante)

Rodapé

Não é o que você precisa? Diga o que ajustar, ou faça uma solicitação de tarefa normal se quiser execução em vez de otimização de prompt.

---

Exemplos

Exemplos de Gatilho

• "Otimize este prompt para o ECC"
• "Reescreva este prompt para que o Claude Code use os comandos corretos"
• "帮我优化这个指令"
• "Como devo criar um prompt para o ECC para esta tarefa?"

Exemplo 1: Prompt Vago em Chinês (Projeto Detectado)

Entrada do usuário:

帮我写一个用户登录页面

Fase 0 detecta: package.json com Next.js 15, TypeScript, Tailwind CSS

Prompt Otimizado (Completo):

Usando a pilha de tecnologia existente do projeto (Next.js 15 + TypeScript + Tailwind CSS) implemente uma página de login de usuário.

Requisitos técnicos:
- Siga as convenções de componentes e roteamento existentes do projeto
- Validação de formulário usando o esquema de validação já existente no projeto (verifique se Zod/Yup/outro já está sendo usado)
- Método de autenticação: use o esquema de autenticação existente do projeto (se não houver, padrão JWT)
- Incluir: formulário de login com email/senha, validação de formulário, mensagens de erro, estado de carregamento, layout responsivo

Workflow:
1. /plan — primeiro, planeje a estrutura do componente e o fluxo de autenticação, referenciando os padrões de páginas existentes
2. /tdd — testes primeiro: escreva testes de unidade para o formulário de login e testes de integração para o fluxo de autenticação
3. Implemente a página de login e a lógica de autenticação
4. /code-review — revise a implementação
5. /verify — verifique se todos os testes passam e a página é renderizada corretamente

Requisitos de segurança:
- Senha não transmitida em texto claro
- Prevenção contra força bruta (rate limiting)
- Proteção XSS
- Token CSRF

Critérios de aceitação:
- Todos os testes passam, cobertura 80%+
- Página renderiza corretamente em dispositivos móveis e desktop
- Login bem-sucedido redireciona para o dashboard, falha exibe mensagem de erro

Não fazer:
- Não implementar página de registro
- Não implementar funcionalidade de "esqueci a senha"
- Não modificar a estrutura de roteamento existente

Exemplo 2: Prompt Moderado em Inglês

Entrada do usuário:

Add a REST API endpoint for user profile updates with validation

Fase 0 detecta: go.mod com Go 1.22, Chi router

Prompt Otimizado (Completo):

Adicione um endpoint de API REST para atualizações de perfil de usuário (PATCH /api/users/:id).

Pilha de tecnologia: Go 1.22 + Chi router (detectado do projeto)

Requisitos:
- PATCH /api/users/:id — atualização parcial do perfil do usuário
- Validação de entrada para campos: name, email, avatar_url, bio
- Autenticação: exigir token válido, usuários só podem atualizar o próprio perfil
- Retornar 200 com o usuário atualizado em caso de sucesso
- Retornar 400 com erros de validação em caso de entrada inválida
- Retornar 401/403 para falhas de autenticação
- Seguir os padrões de API existentes na base de código

Workflow:
1. /plan — planeje a estrutura do endpoint, cadeia de middlewares e lógica de validação
2. /tdd — escreva testes orientados por tabela para sucesso, falha de validação, falha de autenticação, não encontrado
3. Implemente seguindo os padrões de handler existentes
4. /go-review
5. /verify — execute o conjunto completo de testes, confirme que não há regressões

Não fazer:
- Não modificar endpoints existentes
- Não alterar o esquema do banco de dados (use a tabela de usuários existente)
- Não adicionar novas dependências sem verificar as existentes primeiro (use a skill search-first)

Exemplo 3: Projeto Épico

Entrada do usuário:

Migrate our monolith to microservices

Prompt Otimizado (Completo):

Use a skill blueprint para planejar: "Migrar monólito para arquitetura de microsserviços"

Antes de executar, responda estas perguntas no blueprint:
1. Quais limites de domínio existem no monólito atual?
2. Qual serviço deve ser extraído primeiro (menor acoplamento)?
3. Padrão de comunicação: APIs REST, gRPC ou orientado a eventos (Kafka/RabbitMQ)?
4. Estratégia de banco de dados: banco de dados compartilhado inicialmente ou banco de dados por serviço desde o início?
5. Alvo de implantação: Kubernetes, Docker Compose ou serverless?

O blueprint deve produzir fases como:
- Fase 1: Identificar limites de serviço e criar mapa de domínio
- Fase 2: Configurar infraestrutura (API gateway, service mesh, CI/CD por serviço)
- Fase 3: Extrair primeiro serviço (padrão strangler fig)
- Fase 4: Verificar com testes de integração, depois extrair próximo serviço
- Fase N: Descomissionar monólito

Cada fase = 1 PR, com gates /verify entre as fases.
Use /save-session entre as fases

...

[truncado para tradução]