O que Otimizador de Prompt faz?
Analise um rascunho de prompt, critique-o, mapeie-o para os componentes do ecossistema ECC e gere um prompt otimizado 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 maneira de pedir 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 fazer 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 a tarefa feita diretamente (apenas execute-a)
- O usuário diz "优化代码", "优化性能", "otimize este código", "otimize desempenho" — estas 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 habilidades (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 habilidade. Diga ao usuário que esta habilidade 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:
- Verifique se um
CLAUDE.mdexiste no diretório de trabalho — leia-o para convenções do projeto - Detecte a stack de tecnologia a partir dos arquivos do projeto:
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin (então verifique porquarkusno arquivo de build → Quarkus, ouspring-boot→ Spring Boot)Package.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- Anote a stack 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 "stack 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, 创建, 实现, 添加 | "Construir 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, o que é, explorar, investigar, 怎么, 如何 | "Como adicionar SSO" |
| Teste | 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 do código como sinal. Caso contrário, estime 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 habilidade única |
| MÉDIO | Vários componentes, mesmo domínio | Cadeia de comandos + /verify |
| ALTO | Multi-domínio, 5+ arquivos | /plan primeiro, depois execução em fases |
| ÉPICO | Multi-sessão, multi-PR, mudança arquitetural | Usar habilidade blueprint para plano multi-sessão |
Fase 3: Correspondência de Componentes ECC
Mapeie intenção + escopo + stack de tecnologia (da Fase 0) para componentes ECC específicos.
Por Tipo de Intenção
| Intenção | Comandos | Habilidades | 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 | — |
| Teste | /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 habilidade) | planner, architect |
Por Stack de Tecnologia
| Stack de Tecnologia | Habilidades 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 |
| Outro / Não listado | 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 detectou automaticamente ou o usuário deve fornecer:
- Stack de tecnologia — Detectada na Fase 0, ou o usuário deve 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 de borda 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 de escopo — O que NÃO fazer?
Se 3+ itens críticos estiverem faltando, 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 Fluxo de Trabalho e Modelo
Determine onde este prompt se situa no ciclo de vida de desenvolvimento:
Pesquisa → Planejar → Implementar (TDD) → Revisar → Verificar → Commit
Para tarefas MÉDIAS+, sempre comece com /plan. Para tarefas ÉPICAS, use a habilidade 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 em múltiplos prompts (para escopo ALTO/ÉPICO):
Para tarefas que excedem uma única sessão, divida em prompts sequenciais:
- Prompt 1: Pesquisa + Plano (use a habilidade 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 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 |
| Habilidade | tdd-workflow | Orientação de 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 cercado. O prompt deve ser autocontido e pronto para copiar e colar. Inclua:
- Descrição clara da tarefa com contexto
- Stack de tecnologia (detectada ou especificada)
- Invocações de /command nos estágios corretos do fluxo de trabalho
- Critérios de aceitação
- Etapas de verificação
- Limites de escopo (o que NÃO fazer)
Para itens que referenciam blueprint, escreva: "Use a habilidade blueprint para..." (não /blueprint, já que blueprint é uma habilidade, 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 — escreva teste com falha para [bug]. Corrija até ficar verde. /verify. |
| Refatoração | /refactor-clean [escopo]. /code-review. /verify. |
| Pesquisa | Use a habilidade search-first para [tópico]. /plan com base nos resultados. |
| Teste | /tdd [módulo]. /e2e para fluxos críticos. /test-coverage. |
| Revisão | /code-review. Depois use o agente security-reviewer. |
| Documentos | /update-docs. /update-codemaps. |
| ÉPICO | Use a habilidade blueprint para "[objetivo]". Execute as fases com portões /verify. |
Seção 5: Justificativa de Melhoria
| Melhoria | Motivo |
|---|---|
| (o que foi adicionado) | (por que é importante) |
Rodapé
Não é o que você precisa? Diga-me 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 fazer 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):
使用项目现有技术栈（Next.js 15 + TypeScript + Tailwind CSS）实现用户登录页面。
技术要求：
- 沿用项目现有的组件结构和路由约定
- 表单验证使用项目中已有的验证方案（检查是否已用 Zod/Yup/其他）
- 认证方式：沿用项目现有认证方案（如无，默认 JWT）
- 包含：邮箱/密码登录表单、表单验证、错误提示、加载状态、响应式布局
工作流：
1. /plan 先规划组件结构和认证流程，参考现有页面的模式
2. /tdd 测试先行：编写登录表单的单元测试和认证流程的集成测试
3. 实现登录页面和认证逻辑
4. /code-review 审查实现
5. /verify 验证所有测试通过且页面正常渲染
安全要求：
- 密码不明文传输
- 防止暴力破解（rate limiting）
- XSS 防护
- CSRF token
验收标准：
- 所有测试通过，覆盖率 80%+
- 页面在移动端和桌面端正常渲染
- 登录成功跳转到 dashboard，失败显示错误信息
不要做：
- 不要实现注册页面
- 不要实现忘记密码功能
- 不要修改现有的路由结构
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).
Stack 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 os campos: nome, email, avatar_url, bio
- Autenticação: exigir token válido, usuários só podem atualizar seu próprio perfil
- Retornar 200 com usuário atualizado em caso de sucesso
- Retornar 400 com erros de validação para entrada inválida
- Retornar 401/403 para falhas de autenticação
- Seguir os padrões de API existentes no código
Fluxo de trabalho:
1. /plan a estrutura do endpoint, cadeia de middleware e lógica de validação
2. /tdd — escreva testes orientados a tabela para sucesso, falha de validação, falha de autenticação, não encontrado
3. Implementar seguindo os padrões de handler existentes
4. /go-review
5. /verify — execute o conjunto completo de testes, confirme sem regressões
Não faça:
- Modificar endpoints existentes
- Alterar o esquema do banco de dados (use a tabela de usuário existente)
- Adicionar novas dependências sem verificar as existentes primeiro (use a habilidade search-first)
Exemplo 3: Projeto ÉPICO
Entrada do usuário:
Migrate our monolith to microservices
Prompt Otimizado (Completo):
Use a habilidade blueprint para planejar: "Migrar monólito para arquitetura de microsserviços"
Antes de executar, responda a 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 compartilhado inicialmente ou banco 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 portões /verify entre as fases.
Use /save-session entre as fases