/sigma-create-ticket

概要

/sigma-create-ticket は、SPEC、EPIC、TICKET の Issue を作成および編集します。/sigma-to-spec と /sigma-to-tickets のゲートウェイです。/sigma-unslop はこれを呼び出しません。

このスキルは、gh issue create または gh issue edit を実行する唯一のスキルです。実装、レビュー、マージは行いません。

作成または編集を行う前に CONVENTIONS.md を読んでください。このファイルには、タイトル、ラベル、本文の詳細が記載されています。

使用するタイミング

使用する場合: ユーザーが /sigma-create-ticket を呼び出したとき、または /sigma-to-spec や /sigma-to-tickets がこのセッション内で本文を引き渡したとき。
一覧表示または表示: /sigma-to-spec が list-specs を要求した場合。/sigma-to-tickets が view を要求した場合。読み取りを行い、結果を返します。作成はしません。
使用しない場合: 作業がまだソリューションインタビュー (/sigma-plan)、仕様作成 (/sigma-to-spec)、または分割 (/sigma-to-tickets) の段階にある場合。実装、レビュー、マージは行いません。

入力

ハンドオフには、caller、action（list-specs、view、create、update）、kind（spec、epic、ticket）、title、body、場合によっては number、parent、blocked-by が含まれます。

ユーザーの承諾は、このセッション内での返信です。以下の返信は承諾とみなされ、再度確認を求められることはありません:

/sigma-to-spec の後、ユーザーが要約に対して承諾した場合
/sigma-to-tickets の後、ユーザーが粒度とブロッカーに対して承諾した場合

その他、2つ以上の Issue をまとめて作成する場合は、ここで承諾を待ちます。

Issue の契約

SPEC: タイトル SPEC: <名前>、ラベル spec、親なし。本文: この機能の説明、そうでないもの、受け入れ条件のID、scripts/ 以下のスクリプトグロブ、スコープ外。未解決の質問は含めません。
EPIC: タイトル EPIC: <名前>、ラベル type:epic。親は SPEC。
TICKET: タイトル TICKET: <名前>、ラベル type:ticket および agent:hitl または agent:afk。親は EPIC、または /sigma-to-tickets が SPEC を指定した場合は SPEC。レビューから切り出されたチケットは、ハンドオフが EPIC を指定しない限り、SPEC を親としません。本文セクション: Context、Acceptance、Out of scope、Branch agent/{N}-{slug}、Mode hitl または afk。

このスキルが保証するラベル: spec、type:epic、type:ticket、agent:hitl、agent:afk。Mode ラベルは Mode 行と一致します。

手順

手順 1 - 作業リポジトリを特定する

gh repo view --json nameWithOwner を実行します。owner/name が出力されたら完了です。失敗した場合は、ユーザーに作業リポジトリから実行するか、gh auth login を実行するように伝え、停止します。

リポジトリ名が sigma-build-factory で終わる場合は停止します。Issue は作業リポジトリに属します。

手順 2 - 読み取りまたは書き込み

作成または編集の前に CONVENTIONS.md を読みます。

list-specs は以下を実行します:

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

view は gh issue view <N> --repo "$REPO" --json number,title,labels,state,url,body を実行します。

JSON を呼び出し元に返します。ラベルの確認は行わず、質問もしません。

呼び出し元がリストまたは Issue を取得した時点、または書き込みパスが手順 3 に進んだ時点で完了です。

手順 3 - 承諾ゲート

入力の3つの承諾ケースからのハンドオフは、そのまま発行可能です。

このセッション内で承諾がない直接バッチ（2つ以上の Issue）: 各行のタイトル、種類、親、Mode を表示します。一度だけ「これらの Issue を発行しますか？」と尋ねます。待機します。沈黙は発行しません。

直接の単一 Issue: タイトル、種類、または機能レーンの親が不足している場合は一度尋ねます。これらのフィールドがすべて存在する場合は発行します。

このセッション内で承諾がない更新: Issue 番号とタイトルを表示し、一度尋ねてから編集します。2番目の Issue は作成しません。

承諾が記録されるか、単一の完全な作成が発行準備完了になった時点で完了です。

手順 4 - ラベルの確認

書き込みパス上で、ラベルを一覧表示し、契約に基づいて不足している名前を作成します:

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

gh label list に spec、type:epic、type:ticket、agent:hitl、agent:afk が表示された時点で完了です。

手順 5 - 既存の Issue との一致確認

Issue を一覧表示し、完全一致するタイトル SPEC: <名前>、EPIC: <名前>、または TICKET: <名前> を比較します。

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

確認された更新は、その番号を編集します。新しい Issue は作成しません。新しいタイトルが別の Issue に既に存在する場合は、その項目を停止し、両方の番号を報告します。

完全一致するタイトルを1つ見つけた作成は、exists を報告し、その番号を再利用します。2番目の Issue は作成せず、本文も編集しません。2つの完全一致するタイトルがある場合は、その項目を停止します。

各項目が作成、更新、再利用、または衝突のいずれかになった時点で完了です。

手順 6 - 作成または編集

本文を一時ファイルに書き込みます。作業リポジトリ内には書き込まないでください。

短い名前にプレフィックスがない場合は、タイトルにプレフィックスを追加します。プレフィックスが重複しないようにします。

順序通りに作成: チケットの前に EPIC、依存関係の前にブロッカー。ハンドオフが親を指定している場合は --parent を追加します。ブロッカー番号が既に存在する場合は --blocked-by を追加します。値がない各フラグは省略します。

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

URL から N を解析します。Branch 行が欠落しているか、まだ {N} を含んでいるチケット本文は、行が agent/<N>-<slug> となるように編集します。スラッグはプレフィックス以降の名前を小文字にし、スペースをハイフンに変換したものです。

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

確認された更新の場合、gh issue edit でタイトルと本文を置き換え、ラベルを修正します。一致しない方のモードラベルを削除して、一致するラベルのみを残します。編集時に親は変更しません。

SPEC はラベル spec のみを取得します。EPIC は type:epic のみを取得します。TICKET は type:ticket と1つのモードラベルを取得します。

gh の失敗をログに記録し、独立した項目は続行します。失敗した EPIC の子は作成しません。親はクローズしません。

gh issue view <N> --json title,labels,body で、タイトル、ラベル、およびチケットの場合は Branch agent/<N>-<slug> と Mode がラベルと一致していることが確認できた時点で完了です。

手順 7 - 結果を返す

各項目の番号、タイトル、URL を返します（exists と失敗を含む）。

呼び出し元が別のスキルである場合は、そこで停止します。そのスキルが次のコマンドを指定します。ユーザーが /sigma-create-ticket を呼び出した場合は、次のコマンドを指定しますが、実行はしません。SPEC の場合は /sigma-to-tickets <N> に進みます。チケットの場合は /sigma-implement <N> に進みます。EPIC の場合は、/sigma-implement は EPIC を拒否すると伝えます。

厳格なルール

ルール	理由 / 違反例
このスキルは `gh issue create` または `gh issue edit` を実行する唯一のスキルです。他のスキルに対する一覧表示と表示もここで実行します。	2つ目の書き込みパスがあると、タイトル、ラベル、親がずれます。
5つのラベルを確認してから、作成または編集します。	ラベルが欠けていると、バッチ内の次の Issue が失敗します。
確認された更新はその Issue を編集します。完全一致するタイトルは重複を作成しません。	2つ目の `SPEC:` や `TICKET:` は1つの機能を分割します。
直接バッチは承諾を待ちます。このセッション内で `/sigma-to-spec` または `/sigma-to-tickets` によって既に確認された本文には、2度目の質問はしません。	再度尋ねるとハンドオフが滞ります。沈黙のまま直接バッチを発行すると、ユーザーがまだ確認していない Issue が作成されます。
作成後、チケットが Branch `agent/<N>-<slug>` となるように編集します。モードラベルは Mode 行と一致させます。	残った `{N}`、または `agent:hitl` ラベルの付いた `afk` は、ビルダーを間違ったブランチまたはモードに送ります。
ハンドオフが親を指定している場合は、作成時に親を設定します。SPEC からのチケットは、EPIC または SPEC を親とします。レビューからのチケットは、ハンドオフが EPIC を指定しない限り親を省略します。	SPEC の親を発明すると、レビューチケットが実装しない受け入れ条件がコピーされます。
実装、レビュー、マージは行いません。	このスキルは Issue を発行して停止します。

検証

gh repo view が作業リポジトリを返し、リポジトリ名が sigma-build-factory で終わっていないこと。
作成または編集の前に CONVENTIONS.md が読まれていること。
list-specs と view が JSON を返し、作成を行っていないこと。
5つのラベルが作成または編集前に存在すること。
直接バッチに対して明示的な承諾があったこと。上流の承諾がこのセッション内にあった場合は、2度目の質問が行われなかったこと。
確認された更新が指定された Issue を編集したこと。その完全一致するタイトルを持つ2番目の Issue がないこと。
新しいチケットの Branch 行が agent/<N>-<slug> であり、モードラベルが Mode 行と一致していること。
SPEC からの EPIC はその SPEC を親とすること。SPEC からのチケットは EPIC または SPEC を親とすること。レビューからのチケットは、ハンドオフが EPIC を指定しない限り、SPEC を親としないこと。
戻り値が番号、タイトル、URL であること。このスキルは実装、レビュー、マージを行わなかったこと。

sigma-create-ticket