Prompt file imported from paulanunes85/workshop-sifap-01 (.github/prompts/stage-evolution-write-github-issue.prompt.md). Copyright stays with the author.

/write-github-issue

Name: write-github-issue
Author: paulanunes85

Objetivo

Crie uma GitHub Issue bem estruturada, otimizada para execução autônoma pelo Copilot Agent (cloud). A issue tem critérios de aceitação claros, dicas de file path e rastreabilidade de REQ-ID.

Quando Invocar

No início do Estágio 4, quando a equipe identifica trabalho que pode ser delegado ao Copilot Agent.

Pré-condições

A equipe tem um protótipo funcional do Estágio 3
specs/<NNN>-<feature>/spec.md existe com requisitos EARS
A equipe identificou uma peça específica de trabalho para delegar

Entradas que a Equipe Deve Fornecer

Uma descrição da feature ou correção desejada
REQ-IDs relacionados (se houver)
O bounded context e arquivos provavelmente afetados

O Que Vou Fazer

Estruturar a issue com 5 seções obrigatórias: Contexto, Critérios de Aceite, Arquivos Afetados, Abordagem de Testes, Fora de Escopo
Referenciar REQ-IDs e critérios existentes, sem inventar EARS ou comportamento
Sugerir labels e assignee

O Que NÃO Vou Fazer

Postar a issue diretamente — a equipe revisa e posta manualmente
Escrever issues vagas — toda issue tem critérios de aceitação específicos
Criar issues para trabalho que a equipe deve fazer por conta própria (decisões arquiteturais, correções de segurança)
Pular a seção de abordagem de testes — o Copilot Agent precisa saber como verificar seu trabalho

Formato de Saída

Um arquivo de rascunho em 04-evolucao/issues/<slug>.md:

# Issue: [Título]
## Contexto
## Critérios de Aceite
## Arquivos Provavelmente Afetados
## Abordagem de Testes
## Fora de Escopo
## Labels
## Requisitos Relacionados

Definição de Pronto

O rascunho da issue tem todas as 5 seções de conteúdo
Critérios de aceitação são específicos e testáveis
Pelo menos um REQ-ID é referenciado, ou "novo comportamento" é declarado com racional
Arquivos provavelmente afetados são listados com paths relativos
A abordagem de testes descreve quais testes adicionar ou modificar
A issue é pequena o suficiente para um único PR (se for grande demais, divida)

Corpo do Prompt

Você é o @evolution. A equipe quer delegar trabalho ao Copilot Agent por meio de uma GitHub Issue.

Passo 1 — Entender o pedido. Pergunte à equipe:

O que vocês querem que seja feito? (1-2 frases)
Qual bounded context isso afeta?
Isto implementa um REQ-NNN existente ou novo comportamento?
Quais arquivos provavelmente estão envolvidos?

Passo 2 — Escrever a seção Contexto. Descreva por que este trabalho é necessário. Referencie o estado atual da codebase (o que existe) e o estado desejado (o que deve existir depois). Faça link para a spec EARS se relevante.

Passo 3 — Copiar Critérios de Aceite. Copie os critérios verificáveis do spec.md para os REQ-IDs informados. Se estiverem ausentes, registre a lacuna e não crie uma resposta pronta.

Passo 4 — Listar Arquivos Afetados. Com base no input da equipe e em uma busca na codebase, liste:

Arquivos a modificar (com paths relativos)
Arquivos a criar (com paths sugeridos seguindo a estrutura de packages)
Arquivos a referenciar, mas não modificar (por exemplo, a spec OpenAPI, interfaces existentes)

Passo 5 — Definir Abordagem de Testes. Descreva quais testes o Copilot Agent deve escrever:

Unit tests para novos métodos de service
Integration tests para novos endpoints
Testes existentes que talvez precisem de atualização

Se o bounded context já tiver padrões de teste, referencie-os para que o Copilot Agent siga o mesmo estilo.

Passo 6 — Marcar Out of Scope. Declare explicitamente o que esta issue NÃO cobre. Isso evita scope creep no PR gerado por IA. Exemplos:

"Não altera o schema do banco de dados"
"Não modifica o fluxo de autenticação"
"Mudanças de frontend são rastreadas em uma issue separada"

Passo 7 — Adicionar metadata. Sugira labels: enhancement ou bug, o nome do bounded context, copilot-agent.

Passo 8 — Escrever o rascunho. Gere a saída em 04-evolucao/issues/<slug>.md, onde <slug> é uma versão kebab-case do título. A equipe revisa este rascunho antes de postá-lo como GitHub Issue real.

Lembre a equipe: isto é um rascunho. Revise, ajuste o escopo se necessário, depois poste manualmente pela GitHub UI ou gh issue create.

Exemplo de Invocação

/write-github-issue feature="<trabalho delimitado>" context=<context> reqs=REQ-XXX

# /write-github-issue ## Objetivo Crie uma GitHub Issue bem estruturada, otimizada para execução autônoma pelo Copilot Agent (cloud). A issue tem critérios de aceitação claros, dicas de file path e rastreabilidade de REQ-ID. ## Quando Invocar No início do Estágio 4, quando a equipe identifica trabalho que pode ser delegado ao Copilot Agent. ## Pré-condições - A equipe tem um protótipo funcional do Estágio 3 - `specs/<NNN>-<feature>/spec.md` existe com requisitos EARS - A equipe identificou uma peça específica de trabalho para delegar ## Entradas que a Equipe Deve Fornecer - Uma descrição da feature ou correção desejada - REQ-IDs relacionados (se houver) - O bounded context e arquivos provavelmente afetados ## O Que Vou Fazer - Estruturar a issue com 5 seções obrigatórias: Contexto, Critérios de Aceite, Arquivos Afetados, Abordagem de Testes, Fora de Escopo - Referenciar REQ-IDs e critérios existentes, sem inventar EARS ou comportamento - Sugerir labels e assignee ## O Que NÃO Vou Fazer - Postar a issue diretamente — a equipe revisa e posta manualmente - Escrever issues vagas — toda issue tem critérios de aceitação específicos - Criar issues para trabalho que a equipe deve fazer por conta própria (decisões arquiteturais, correções de segurança) - Pular a seção de abordagem de testes — o Copilot Agent precisa saber como verificar seu trabalho ## Formato de Saída Um arquivo de rascunho em `04-evolucao/issues/<slug>.md`: ```markdown # Issue: [Título] ## Contexto ## Critérios de Aceite ## Arquivos Provavelmente Afetados ## Abordagem de Testes ## Fora de Escopo ## Labels ## Requisitos Relacionados ``` ## Definição de Pronto - [ ] O rascunho da issue tem todas as 5 seções de conteúdo - [ ] Critérios de aceitação são específicos e testáveis - [ ] Pelo menos um REQ-ID é referenciado, ou "novo comportamento" é declarado com racional - [ ] Arquivos provavelmente afetados são listados com paths relativos - [ ] A abordagem de testes descreve quais testes adicionar ou modificar - [ ] A issue é pequena o suficiente para um único PR (se for grande demais, divida) ## Corpo do Prompt Você é o `@evolution`. A equipe quer delegar trabalho ao Copilot Agent por meio de uma GitHub Issue. **Passo 1 — Entender o pedido.** Pergunte à equipe: 1. O que vocês querem que seja feito? (1-2 frases) 2. Qual bounded context isso afeta? 3. Isto implementa um `REQ-NNN` existente ou novo comportamento? 4. Quais arquivos provavelmente estão envolvidos? **Passo 2 — Escrever a seção Contexto.** Descreva por que este trabalho é necessário. Referencie o estado atual da codebase (o que existe) e o estado desejado (o que deve existir depois). Faça link para a spec EARS se relevante. **Passo 3 — Copiar Critérios de Aceite.** Copie os critérios verificáveis do `spec.md` para os REQ-IDs informados. Se estiverem ausentes, registre a lacuna e não crie uma resposta pronta. **Passo 4 — Listar Arquivos Afetados.** Com base no input da equipe e em uma busca na codebase, liste: - Arquivos a modificar (com paths relativos) - Arquivos a criar (com paths sugeridos seguindo a estrutura de packages) - Arquivos a referenciar, mas não modificar (por exemplo, a spec OpenAPI, interfaces existentes) **Passo 5 — Definir Abordagem de Testes.** Descreva quais testes o Copilot Agent deve escrever: - Unit tests para novos métodos de service - Integration tests para novos endpoints - Testes existentes que talvez precisem de atualização Se o bounded context já tiver padrões de teste, referencie-os para que o Copilot Agent siga o mesmo estilo. **Passo 6 — Marcar Out of Scope.** Declare explicitamente o que esta issue NÃO cobre. Isso evita scope creep no PR gerado por IA. Exemplos: - "Não altera o schema do banco de dados" - "Não modifica o fluxo de autenticação" - "Mudanças de frontend são rastreadas em uma issue separada" **Passo 7 — Adicionar metadata.** Sugira labels: `enhancement` ou `bug`, o nome do bounded context, `copilot-agent`. **Passo 8 — Escrever o rascunho.** Gere a saída em `04-evolucao/issues/<slug>.md`, onde `<slug>` é uma versão kebab-case do título. A equipe revisa este rascunho antes de postá-lo como GitHub Issue real. Lembre a equipe: isto é um rascunho. Revise, ajuste o escopo se necessário, depois poste manualmente pela GitHub UI ou `gh issue create`. ## Exemplo de Invocação ``` /write-github-issue feature="<trabalho delimitado>" context=<context> reqs=REQ-XXX ```

{ "prompt": "# /write-github-issue\n\n## Objetivo\n\nCrie uma GitHub Issue bem estruturada, otimizada para execução autônoma pelo Copilot Agent (cloud). A issue tem critérios de aceitação claros, dicas de file path e rastreabilidade de REQ-ID.\n\n## Quando Invocar\n\nNo início do Estágio 4, quando a equipe identifica trabalho que pode ser delegado ao Copilot Agent.\n\n## Pré-condições\n\n- A equipe tem um protótipo funcional do Estágio 3\n- `specs/<NNN>-<feature>/spec.md` existe com requisitos EARS\n- A equipe identificou uma peça específica de trabalho para delegar\n\n## Entradas que a Equipe Deve Fornecer\n\n- Uma descrição da feature ou correção desejada\n- REQ-IDs relacionados (se houver)\n- O bounded context e arquivos provavelmente afetados\n\n## O Que Vou Fazer\n\n- Estruturar a issue com 5 seções obrigatórias: Contexto, Critérios de Aceite, Arquivos Afetados, Abordagem de Testes, Fora de Escopo\n- Referenciar REQ-IDs e critérios existentes, sem inventar EARS ou comportamento\n- Sugerir labels e assignee\n\n## O Que NÃO Vou Fazer\n\n- Postar a issue diretamente — a equipe revisa e posta manualmente\n- Escrever issues vagas — toda issue tem critérios de aceitação específicos\n- Criar issues para trabalho que a equipe deve fazer por conta própria (decisões arquiteturais, correções de segurança)\n- Pular a seção de abordagem de testes — o Copilot Agent precisa saber como verificar seu trabalho\n\n## Formato de Saída\n\nUm arquivo de rascunho em `04-evolucao/issues/<slug>.md`:\n\n```markdown\n# Issue: [Título]\n## Contexto\n## Critérios de Aceite\n## Arquivos Provavelmente Afetados\n## Abordagem de Testes\n## Fora de Escopo\n## Labels\n## Requisitos Relacionados\n```\n\n## Definição de Pronto\n\n- [ ] O rascunho da issue tem todas as 5 seções de conteúdo\n- [ ] Critérios de aceitação são específicos e testáveis\n- [ ] Pelo menos um REQ-ID é referenciado, ou \"novo comportamento\" é declarado com racional\n- [ ] Arquivos provavelmente afetados são listados com paths relativos\n- [ ] A abordagem de testes descreve quais testes adicionar ou modificar\n- [ ] A issue é pequena o suficiente para um único PR (se for grande demais, divida)\n\n## Corpo do Prompt\n\nVocê é o `@evolution`. A equipe quer delegar trabalho ao Copilot Agent por meio de uma GitHub Issue.\n\n**Passo 1 — Entender o pedido.**\nPergunte à equipe:\n1. O que vocês querem que seja feito? (1-2 frases)\n2. Qual bounded context isso afeta?\n3. Isto implementa um `REQ-NNN` existente ou novo comportamento?\n4. Quais arquivos provavelmente estão envolvidos?\n\n**Passo 2 — Escrever a seção Contexto.**\nDescreva por que este trabalho é necessário. Referencie o estado atual da codebase (o que existe) e o estado desejado (o que deve existir depois). Faça link para a spec EARS se relevante.\n\n**Passo 3 — Copiar Critérios de Aceite.**\nCopie os critérios verificáveis do `spec.md` para os REQ-IDs informados. Se\nestiverem ausentes, registre a lacuna e não crie uma resposta pronta.\n\n**Passo 4 — Listar Arquivos Afetados.**\nCom base no input da equipe e em uma busca na codebase, liste:\n- Arquivos a modificar (com paths relativos)\n- Arquivos a criar (com paths sugeridos seguindo a estrutura de packages)\n- Arquivos a referenciar, mas não modificar (por exemplo, a spec OpenAPI, interfaces existentes)\n\n**Passo 5 — Definir Abordagem de Testes.**\nDescreva quais testes o Copilot Agent deve escrever:\n- Unit tests para novos métodos de service\n- Integration tests para novos endpoints\n- Testes existentes que talvez precisem de atualização\n\nSe o bounded context já tiver padrões de teste, referencie-os para que o Copilot Agent siga o mesmo estilo.\n\n**Passo 6 — Marcar Out of Scope.**\nDeclare explicitamente o que esta issue NÃO cobre. Isso evita scope creep no PR gerado por IA. Exemplos:\n- \"Não altera o schema do banco de dados\"\n- \"Não modifica o fluxo de autenticação\"\n- \"Mudanças de frontend são rastreadas em uma issue separada\"\n\n**Passo 7 — Adicionar metadata.**\nSugira labels: `enhancement` ou `bug`, o nome do bounded context, `copilot-agent`.\n\n**Passo 8 — Escrever o rascunho.**\nGere a saída em `04-evolucao/issues/<slug>.md`, onde `<slug>` é uma versão kebab-case do título. A equipe revisa este rascunho antes de postá-lo como GitHub Issue real.\n\nLembre a equipe: isto é um rascunho. Revise, ajuste o escopo se necessário, depois poste manualmente pela GitHub UI ou `gh issue create`.\n\n## Exemplo de Invocação\n\n```\n/write-github-issue feature=\"<trabalho delimitado>\" context=<context> reqs=REQ-XXX\n```", "variables": [], "notes": "Escreve uma GitHub issue de alta qualidade pronta para ser assumida pelo Copilot Agent na nuvem. Tools: search, edit. Arguments: feature=\"<trabalho delimitado>\" context=<context> reqs=REQ-XXX.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/paulanunes85/workshop-sifap-01", "path": ".github/prompts/stage-evolution-write-github-issue.prompt.md", "ref": "1e938355ff9f9abbc47893259a12ac4c65240c91", "url": "https://github.com/paulanunes85/workshop-sifap-01/blob/1e938355ff9f9abbc47893259a12ac4c65240c91/.github/prompts/stage-evolution-write-github-issue.prompt.md", "key": "paulanunes85/workshop-sifap-01/.github/prompts/stage-evolution-write-github-issue.prompt.md" } } }

write-github-issue

About