Gate de Criação de Issue

Visão Geral

Use este fluxo de trabalho de "issue gating" apenas quando o usuário ou o projeto atual exigir explicitamente. Não é um pré-requisito universal para implementação ou permissão para criar issues públicas.

Regra principal: dentro de um "issue gate" explicitamente exigido, a execução dependente requer critérios de aceitação válidos. Derive-os do contexto de tarefa autorizado disponível quando possível; apenas decisões indispensáveis não resolvidas precisam de esclarecimento.

Quando Usar

• Você está iniciando uma nova tarefa de implementação e deseja que uma issue do GitHub seja o ponto de entrada de rastreamento obrigatório.
• O trabalho deve ser bloqueado até que o usuário forneça critérios de aceitação explícitos e testáveis.
• Você precisa distinguir entre trabalho draft, ready e blocked antes que a execução comece.

Campos Obrigatórios

Toda issue deve incluir estas seções:

• Problema
• Objetivo
• Escopo
• Não-Objetivos
• Critérios de Aceitação
• Dependências/Bloqueios
• Status (draft | ready | blocked | done)

Gate de Critérios de Aceitação

Os critérios de aceitação são válidos apenas quando são testáveis e verificáveis como aprovados/reprovados.

Exemplos:

• válido: "CreateCheckoutLambda-dev retorna uma URL de checkout de pagamento de terceiros que pode ser aberta"
• inválido: "corrigir checkout" / "melhorar UX" / "tornar melhor"

Se os critérios estiverem faltando ou não forem testáveis:

• prepare um rascunho revisável; crie uma issue pública apenas quando essa ação do repositório for autorizada
• defina Status: draft
• adicione Execution Gate: blocked (missing valid acceptance criteria)
• não mova a tarefa para execução

Modo de Criação de Issue

Por padrão, prepare o corpo exato da issue para revisão. Se a criação da issue for autorizada, use o repositório nomeado e o template existente; uma invocação de skill não concede permissão para postar em um repositório não relacionado.

Use um template de corpo como:

## Problem
<what is broken or missing>

## Goal
<what outcome is expected>

## Scope
- <in scope item>

## Non-Goals
- <out of scope item>

## Acceptance Criteria
- <explicit, testable criterion 1>

## Dependencies/Blockers
- <dependency or none>

## Status
draft|ready|blocked|done

## Execution Gate
allowed|blocked (<reason>)

Regras de Status

• draft: critérios de aceitação ausentes/fracos ou definição de tarefa incompleta
• ready: critérios de aceitação explícitos e testáveis
• blocked: dependência externa impede o progresso
• done: critérios de aceitação verificados com evidências

Nunca marque uma issue ready sem critérios de aceitação válidos.

Passagem para Execução

Fluxos de trabalho de execução (por exemplo, closed-loop-delivery) podem começar apenas quando:

• o status da issue for ready
• o gate de execução for allowed

Se uma issue obrigatória aplicável permanecer como rascunho devido a uma decisão indispensável ausente, pause essa etapa dependente e continue o trabalho seguro independente. Não peça novamente por critérios já claros na solicitação do usuário.

Limitações

• Use esta skill apenas quando a tarefa corresponder claramente ao escopo descrito acima.
• Não trate a saída como um substituto para validação específica do ambiente, testes ou revisão de especialistas.
• Pare e peça esclarecimentos se as entradas, permissões, limites de segurança ou critérios de sucesso necessários estiverem faltando.