sigma-create-ticket

/sigma-create-ticket

Visão Geral

/sigma-create-ticket cria e edita issues SPEC, EPIC e TICKET. É o gateway para /sigma-to-spec e /sigma-to-tickets. /sigma-unslop não a chama.

Esta skill é a única que executa gh issue create ou gh issue edit. Ela não implementa, revisa ou faz merge.

Leia CONVENTIONS.md antes de criar ou editar. Esse arquivo contém detalhes sobre título, label e corpo.

Quando Usar

• Use quando: o usuário invocar /sigma-create-ticket, ou /sigma-to-spec ou /sigma-to-tickets passar um corpo nesta sessão.
• Listar ou visualizar: /sigma-to-spec solicita list-specs. /sigma-to-tickets solicita view. Execute a leitura e retorne. Não crie.
• Não use quando: o trabalho ainda for uma entrevista de solução (/sigma-plan), um spec (/sigma-to-spec) ou uma divisão (/sigma-to-tickets). Não implemente, revise ou faça merge.

Entrada

Uma transferência contém caller, action (list-specs, view, create ou update), kind (spec, epic ou ticket), title, body e, às vezes, number, parent e blocked-by.

O "sim" do usuário é uma resposta nesta sessão. Estas respostas contam como "sim" e não recebem uma segunda pergunta:

• /sigma-to-spec após o usuário dizer sim ao resumo
• /sigma-to-tickets após o usuário dizer sim à granulação e aos bloqueadores

Qualquer outro lote de 2 ou mais issues aguarda um "sim" aqui.

Contrato de Issue

• SPEC: título SPEC: <nome>, label spec, sem parent. Corpo: o que este recurso é, o que não é, IDs de aceitação, globs de script em scripts/, fora de escopo. Sem perguntas em aberto.
• EPIC: título EPIC: <nome>, label type:epic. Parent é a SPEC.
• TICKET: título TICKET: <nome>, label type:ticket mais agent:hitl ou agent:afk. Parent é um EPIC ou a SPEC quando /sigma-to-tickets nomeia um. Um ticket cortado de uma revisão não tem parent spec, a menos que a transferência nomeie um epic. Seções do corpo: Contexto, Aceitação, Fora de escopo, Branch agent/{N}-{slug}, Modo hitl ou afk.

Labels que esta skill garante: spec, type:epic, type:ticket, agent:hitl, agent:afk. A label Modo corresponde à linha Modo.

Etapas

Etapa 1 - Resolver o repositório de trabalho

Execute gh repo view --json nameWithOwner. Concluído quando imprimir owner/name. Se falhar, diga ao usuário para executar a partir do repositório de trabalho ou executar gh auth login e pare.

Se o nome do repositório terminar com sigma-build-factory, pare. As issues pertencem ao repositório de trabalho.

Etapa 2 - Ler ou escrever

Leia CONVENTIONS.md antes de criar ou editar.

list-specs executa:

gh issue list --repo "$REPO" --label spec --state all --limit 50 \
  --json number,title,state,url,body

view executa gh issue view <N> --repo "$REPO" --json number,title,labels,state,url,body.

Retorne o JSON para quem chamou. Não garanta labels e não faça perguntas.

Concluído quando quem chamou tem a lista ou a issue, ou o caminho de escrita continua na Etapa 3.

Etapa 3 - Portão de confirmação ("yes gate")

Uma transferência dos três casos de "sim" em Entrada está pronta para ser arquivada.

Um lote direto (2 ou mais issues) sem "sim" nesta sessão: mostre título, kind, parent e Modo para cada linha. Pergunte uma vez: "Arquivar estas issues?" Aguarde. Silêncio não arquiva.

Uma única issue direta: pergunte uma vez quando título, kind ou um parent de feature-lane estiver faltando. Quando esses campos estiverem presentes, arquive.

Uma atualização sem "sim" nesta sessão: mostre o número e título da issue, pergunte uma vez, depois edite. Não crie uma segunda issue.

Concluído quando o "sim" é registrado, ou uma única criação completa está pronta para ser arquivada.

Etapa 4 - Garantir labels

No caminho de escrita, liste labels e crie qualquer nome ausente do contrato:

gh label list --repo "$REPO" --limit 100 --json name
gh label create <name> --repo "$REPO" --description "<de CONVENTIONS.md>"

Concluído quando gh label list mostra spec, type:epic, type:ticket, agent:hitl e agent:afk.

Etapa 5 - Corresponder a uma issue existente

Liste issues e compare o título exato SPEC: <nome>, EPIC: <nome> ou TICKET: <nome>.

gh issue list --repo "$REPO" --state all --limit 200 --json number,title,state,url

Uma atualização confirmada edita esse número. Ela não cria. Se o novo título já estiver em uma issue diferente, pare esse item e relate ambos os números.

Uma criação que encontra um título exato relata exists e reutiliza o número. Ela não cria uma segunda issue e não edita o corpo. Dois títulos exatos param esse item.

Concluído quando cada item é criação, atualização, reutilização ou colisão.

Etapa 6 - Criar ou editar

Escreva o corpo em um arquivo temporário. Não o escreva no repositório de trabalho.

Defina o prefixo do título quando o nome curto não o tiver. Não duplique o prefixo.

Crie em ordem: epics antes de seus tickets, bloqueadores antes de dependentes. Adicione --parent quando a transferência nomear um. Adicione --blocked-by quando os números dos bloqueadores já existirem. Omita cada flag quando não tiver valor.

gh issue create --repo "$REPO" --title "<título>" --label "<labels>" --body-file "$f"

Parseie N da URL. Um ticket cuja linha Branch está faltando ou ainda contém {N} é editado para que a linha seja agent/<N>-<slug>. O slug é o nome após o prefixo, em minúsculas, espaços transformados em hífens.

gh issue edit <N> --repo "$REPO" --body-file "$f"

Em uma atualização confirmada, gh issue edit substitui título e corpo e corrige labels. Remova a outra label de modo para que apenas a correspondente permaneça. Não altere parent na edição.

Uma SPEC recebe apenas label spec. Um EPIC recebe apenas type:epic. Um TICKET recebe type:ticket e a única label de modo.

Registre uma falha de gh e continue itens independentes. Não crie filhos de um epic falho. Não feche o parent.

Concluído quando gh issue view <N> --json title,labels,body mostra o título, as labels e, em um ticket, Branch agent/<N>-<slug> com Modo correspondendo à label.

Etapa 7 - Retornar

Retorne número, título e URL para cada item, incluindo exists e falhas.

Quando quem chamou for outra skill, pare aí. Essa skill nomeia o próximo comando. Quando o usuário invocou /sigma-create-ticket, nomeie o próximo comando e não o invoque. Uma SPEC vai para /sigma-to-tickets <N>. Um ticket vai para /sigma-implement <N>. Para um epic, diga que /sigma-implement recusa um epic.

Regras rígidas

Regra	Por que / como a violação se parece
Esta skill é a única que executa gh issue create ou gh issue edit. Listar e visualizar para as outras skills também ocorrem aqui.	Um segundo caminho de escrita desvia título, label e parent.
Garanta as cinco labels, depois crie ou edite.	Uma label ausente falha a próxima issue no lote.
Uma atualização confirmada edita essa issue. Uma correspondência exata de título não cria uma duplicata.	Um segundo SPEC: ou TICKET: divide um recurso.
Um lote direto aguarda um "sim". Um corpo já confirmado por /sigma-to-spec ou /sigma-to-tickets nesta sessão não recebe uma segunda pergunta.	Perguntar novamente trava a transferência. Arquivar um lote direto em silêncio cria issues que o usuário não viu.
Após a criação, edite um ticket para que Branch seja agent/<N>-<slug>. A label de modo corresponde à linha Modo.	Um {N} residual, ou afk com agent:hitl, envia o builder para a branch ou modo errados.
Defina parent na criação quando a transferência nomear um. Um ticket de um spec parentiza para um EPIC ou a SPEC. Um ticket de uma revisão omite parent, a menos que a transferência nomeie um epic.	Inventar um parent spec copia aceitação que o ticket de revisão não implementa.
Não implemente, revise ou faça merge.	Esta skill arquiva a issue e para.

Verificação

• gh repo view retornou o repositório de trabalho, e o nome do repositório não termina com sigma-build-factory.
• CONVENTIONS.md foi lido antes de qualquer criação ou edição.
• list-specs e view retornaram JSON e não criaram.
• As cinco labels existem antes da criação ou edição.
• Um lote direto teve um "sim" explícito. Um "sim" upstream nesta sessão não recebeu uma segunda pergunta.
• Uma atualização confirmada editou a issue nomeada. Nenhuma segunda issue compartilha aquele título exato.
• A linha Branch de um novo ticket é agent/<N>-<slug>, e a label de modo corresponde à linha Modo.
• Um epic de um spec parentiza para essa SPEC. Um ticket de um spec parentiza para um EPIC ou a SPEC. Um ticket de uma revisão não tem parent spec, a menos que a transferência tenha nomeado um epic.
• O retorno é número, título e URL. Esta skill não implementou, revisou ou fez merge.