Menú
Transforma a conversa atual em uma spec e publica no issue tracker do projeto — sem entrevista, só síntese do que você já discutiu.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Sincroniza este repositório com um novo release do upstream (mattpocock/skills), adaptando as mudanças para pt-BR em vez de copiá-las. Use quando sair um release novo no upstream ou quando uma issue de "Sync upstream" for aberta pelo workflow check-upstream.
Pergunte qual skill ou fluxo encaixa na sua situação. Um router sobre as skills deste repo.
Revisa as mudanças desde um ponto fixo (commit, branch, tag ou merge-base) em dois eixos — Standards (o código segue os padrões de codificação documentados deste repo?) e Spec (o código faz o que a issue/spec de origem pediu?). Roda as duas revisões em sub-agents paralelos e reporta lado a lado. Use quando o usuário quiser revisar um branch, um PR, mudanças em andamento, ou pedir para "revisar desde X".
Implementa um pedaço de trabalho baseado em uma spec ou conjunto de tickets.
Constrói um prototype descartável para responder a uma pergunta de design. Use quando o usuário quiser checar se um modelo de estado ou uma lógica faz sentido, ou explorar como uma UI deveria ser.
Investiga uma pergunta contra fontes primárias de alta confiança e registra os achados como um arquivo Markdown no repo. Use quando o usuário quiser um tema pesquisado, fatos de docs ou de API reunidos, ou o trabalho braçal de leitura delegado a um background agent.
| name | to-spec |
| description | Transforma a conversa atual em uma spec e publica no issue tracker do projeto — sem entrevista, só síntese do que você já discutiu. |
| disable-model-invocation | true |
Esta skill pega o contexto atual da conversa e o entendimento da codebase e produz uma spec (você talvez conheça este documento como PRD). NÃO entreviste o usuário — apenas sintetize o que já sabe.
O issue tracker e o vocabulário de triage labels devem ter sido fornecidos a você — rode /setup-leandrocfe-skills se não.
Explore o repo para entender o estado atual da codebase, se ainda não fez isso. Use o vocabulário do glossário de domínio do projeto ao longo de toda a spec, e respeite quaisquer ADRs na área que você está tocando.
Esboce os seams nos quais você vai testar a feature. Seams existentes são preferíveis a novos. Use o seam mais alto possível. Se novos seams forem necessários, proponha-os no ponto mais alto que conseguir. Quanto menos seams espalhados pela codebase, melhor — o número ideal é um.
Confirme com o usuário que esses seams batem com o que ele espera.
ready-for-agent — não é preciso triage adicional.O problema que o usuário enfrenta, da perspectiva dele.
A solução para o problema, da perspectiva do usuário.
Uma lista numerada LONGA de user stories. Cada user story deve estar no formato:
Esta lista de user stories deve ser extremamente extensa e cobrir todos os aspectos da feature.
Uma lista das decisões de implementação tomadas. Pode incluir:
NÃO inclua caminhos de arquivo específicos nem trechos de código. Eles podem ficar desatualizados muito rápido.
Exceção: se um prototype produziu um trecho que codifica uma decisão com mais precisão do que a prosa consegue (state machine, reducer, schema, formato de tipo), inclua-o dentro da decisão relevante e anote brevemente que veio de um prototype. Corte para as partes ricas em decisão — não é um demo funcional, só o que importa.
Uma lista das decisões de teste tomadas. Inclua:
Uma descrição do que está fora do escopo desta spec.
Quaisquer notas adicionais sobre a feature.