sigma-create-ticket

/sigma-create-ticket

Resumen

/sigma-create-ticket crea y edita issues de tipo SPEC, EPIC y TICKET. Es la puerta de entrada para /sigma-to-spec y /sigma-to-tickets. /sigma-unslop no lo llama.

Esta habilidad es la única que ejecuta gh issue create o gh issue edit. No implementa, revisa ni fusiona.

Lee CONVENTIONS.md antes de una creación o edición. Ese archivo contiene el detalle de títulos, etiquetas y cuerpos.

Cuándo usarla

• Usar cuando: el usuario invoca /sigma-create-ticket, o /sigma-to-spec o /sigma-to-tickets entrega un cuerpo en esta sesión.
• Listar o ver: /sigma-to-spec pide list-specs. /sigma-to-tickets pide view. Ejecuta la lectura y devuelve. No crear.
• No usar cuando: el trabajo sigue siendo una entrevista de solución (/sigma-plan), un spec (/sigma-to-spec) o un desglose (/sigma-to-tickets). No implementar, revisar ni fusionar.

Entrada

Un traspaso tiene caller, action (list-specs, view, create o update), kind (spec, epic o ticket), title, body y a veces number, parent y blocked-by.

El sí del usuario es una respuesta en esta sesión. Estas respuestas cuentan como sí y no reciben una segunda pregunta:

• /sigma-to-spec después de que el usuario dijo sí al resumen
• /sigma-to-tickets después de que el usuario dijo sí al granulado y bloqueos

Cualquier otro lote de 2 o más issues espera un sí aquí.

Contrato de issues

• SPEC: título SPEC: <nombre>, etiqueta spec, sin padre. Cuerpo: qué es esta funcionalidad, qué no es, ids de aceptación, patrones de script bajo scripts/, fuera de alcance. Sin preguntas abiertas.
• EPIC: título EPIC: <nombre>, etiqueta type:epic. El padre es el SPEC.
• TICKET: título TICKET: <nombre>, etiqueta type:ticket más agent:hitl o agent:afk. El padre es un EPIC o el SPEC cuando /sigma-to-tickets nombra uno. Un ticket cortado de una revisión no tiene padre spec a menos que ese traspaso nombre un epic. Secciones del cuerpo: Contexto, Aceptación, Fuera de alcance, Rama agent/{N}-{slug}, Modo hitl o afk.

Etiquetas que esta habilidad asegura: spec, type:epic, type:ticket, agent:hitl, agent:afk. La etiqueta de Modo coincide con la línea de Modo.

Pasos

Paso 1 - Resolver el repositorio de trabajo

Ejecuta gh repo view --json nameWithOwner. Termina cuando imprime dueño/nombre. Si falla, dile al usuario que ejecute desde el repositorio de trabajo o que ejecute gh auth login, y detente.

Si el nombre del repositorio termina en sigma-build-factory, detente. Los issues pertenecen al repositorio de trabajo.

Paso 2 - Leer o escribir

Lee CONVENTIONS.md antes de una creación o edición.

list-specs ejecuta:

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

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

Devuelve el JSON al llamante. No asegures etiquetas y no hagas preguntas.

Termina cuando el llamante tiene la lista o el issue, o la ruta de escritura continúa en el Paso 3.

Paso 3 - Puerta del sí

Un traspaso de los tres casos de sí en Entrada está listo para ser archivado.

Un lote directo (2 o más issues) sin un sí en esta sesión: muestra título, tipo, padre y Modo para cada línea. Pregunta una vez: "¿Archivar estos issues?" Espera. El silencio no archiva.

Un issue único directo: pregunta una vez cuando falten el título, el tipo o un padre de línea de funcionalidad. Cuando esos campos están presentes, archiva.

Una actualización sin un sí en esta sesión: muestra el número y título del issue, pregunta una vez, luego edita. No crees un segundo issue.

Termina cuando el sí está registrado, o una creación única completa está lista para archivar.

Paso 4 - Asegurar etiquetas

En la ruta de escritura, lista las etiquetas y crea cualquier nombre faltante del contrato:

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

Termina cuando gh label list muestra spec, type:epic, type:ticket, agent:hitl y agent:afk.

Paso 5 - Coincidir con un issue existente

Lista los issues y compara el título exacto SPEC: <nombre>, EPIC: <nombre> o TICKET: <nombre>.

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

Una actualización confirmada edita ese número. No crea. Si el nuevo título ya está en un issue diferente, detén ese elemento e informa ambos números.

Una creación que encuentra un título exacto informa existe y reutiliza el número. No crea un segundo issue y no edita el cuerpo. Dos títulos exactos detienen ese elemento.

Termina cuando cada elemento es crear, actualizar, reutilizar o colisión.

Paso 6 - Crear o editar

Escribe el cuerpo en un archivo temporal. No lo escribas en el repositorio de trabajo.

Establece el prefijo del título cuando el nombre corto carezca de él. No dupliques el prefijo.

Crea en orden: epics antes que sus tickets, bloqueantes antes que dependientes. Añade --parent cuando el traspaso nombre uno. Añade --blocked-by cuando los números bloqueantes ya existan. Omite cada bandera cuando no tenga valor.

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

Analiza N de la URL. Un ticket cuyo cuerpo tiene la línea Branch faltante o aún contiene {N} se edita para que la línea sea agent/<N>-<slug>. El slug es el nombre después del prefijo, en minúsculas, espacios convertidos en guiones.

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

En una actualización confirmada, gh issue edit reemplaza título y cuerpo y corrige etiquetas. Elimina la otra etiqueta de modo para que solo quede la que coincide. No cambies el padre en una edición.

Un SPEC obtiene etiqueta spec solamente. Un EPIC obtiene type:epic solamente. Un TICKET obtiene type:ticket y la etiqueta de modo correspondiente.

Registra un fallo de gh y continúa con elementos independientes. No crees hijos de un epic fallido. No cierres el padre.

Termina cuando gh issue view <N> --json title,labels,body muestra el título, las etiquetas y, en un ticket, Branch agent/<N>-<slug> con Modo coincidiendo con la etiqueta.

Paso 7 - Devolver

Devuelve número, título y URL para cada elemento, incluyendo existe y fallos.

Cuando el llamante es otra habilidad, detente allí. Esa habilidad nombra el siguiente comando. Cuando el usuario invocó /sigma-create-ticket, nombra el siguiente comando y no lo invoques. Un SPEC va a /sigma-to-tickets <N>. Un ticket va a /sigma-implement <N>. Para un epic, di que /sigma-implement rechaza un epic.

Reglas estrictas

Regla	Por qué / cómo se ve una violación
Esta habilidad es la única que ejecuta gh issue create o gh issue edit. Listar y ver para las otras habilidades también se ejecuta aquí.	Una segunda ruta de escritura desvía título, etiqueta y padre.
Asegurar las cinco etiquetas, luego crear o editar.	Una etiqueta faltante falla el siguiente issue del lote.
Una actualización confirmada edita ese issue. Una coincidencia de título exacto no crea un duplicado.	Un segundo SPEC: o TICKET: divide una funcionalidad.
Un lote directo espera un sí. Un cuerpo ya confirmado por /sigma-to-spec o /sigma-to-tickets en esta sesión no recibe una segunda pregunta.	Preguntar de nuevo estanca el traspaso. Archivar un lote directo en silencio crea issues que el usuario no ha visto.
Después de crear, editar un ticket para que Branch sea agent/<N>-<slug>. La etiqueta de modo coincide con la línea Modo.	Un {N} residual, o afk con agent:hitl, envía al builder a la rama o modo incorrectos.
Establecer padre en la creación cuando el traspaso nombre uno. Un ticket de un spec tiene como padre un EPIC o el SPEC. Un ticket de una revisión omite el padre a menos que el traspaso nombre un epic.	Inventar un padre spec copia aceptación que el ticket de revisión no implementa.
No implementar, revisar ni fusionar.	Esta habilidad archiva el issue y se detiene.

Verificación

• gh repo view devolvió el repositorio de trabajo y el nombre del repositorio no termina en sigma-build-factory.
• Se leyó CONVENTIONS.md antes de cualquier creación o edición.
• list-specs y view devolvieron JSON y no crearon.
• Las cinco etiquetas existen antes de crear o editar.
• Un lote directo tuvo un sí explícito. Un sí de aguas arriba en esta sesión no recibió una segunda pregunta.
• Una actualización confirmada editó el issue nombrado. Ningún segundo issue comparte ese título exacto.
• La línea Branch de un ticket nuevo es agent/<N>-<slug>, y la etiqueta de modo coincide con la línea Modo.
• Un epic de un spec tiene como padre ese SPEC. Un ticket de un spec tiene como padre un EPIC o el SPEC. Un ticket de una revisión no tiene padre spec a menos que el traspaso haya nombrado un epic.
• El retorno es número, título y URL. Esta habilidad no implementó, revisó ni fusionó.