/sigma-create-ticket

개요

/sigma-create-ticket은 SPEC, EPIC, TICKET 이슈를 생성하고 편집합니다. /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가 세분화(grain)와 차단자(blockers)에 대해 사용자가 "예"라고 답한 후

그 외 2개 이상의 이슈 배치는 여기서 "예"를 기다립니다.

이슈 규약

SPEC: 제목 SPEC: <이름>, 레이블 spec, 부모 없음. 본문: 이 기능이 무엇인지, 무엇이 아닌지, 승인 기준 ID, scripts/ 아래의 스크립트 글로브, 범위 외 항목. 미해결 질문 없음.
EPIC: 제목 EPIC: <이름>, 레이블 type:epic. 부모는 SPEC입니다.
TICKET: 제목 TICKET: <이름>, 레이블 type:ticket + agent:hitl 또는 agent:afk. 부모는 EPIC 또는 /sigma-to-tickets가 SPEC 하나를 지정할 때는 SPEC입니다. 리뷰에서 잘라낸 티켓은 해당 핸드오프가 에픽을 지정하지 않는 한 SPEC 부모가 없습니다. 본문 섹션: 컨텍스트(Context), 승인 기준(Acceptance), 범위 외(Out of scope), 브랜치 agent/{N}-{slug}, 모드 hitl 또는 afk.

이 스킬이 보장하는 레이블: spec, type:epic, type:ticket, agent:hitl, agent:afk. 모드 레이블은 모드 라인과 일치합니다.

단계

1단계 - 작업 저장소 확인

gh repo view --json nameWithOwner를 실행합니다. 소유자/이름을 출력하면 완료입니다. 실패하면 사용자에게 작업 저장소에서 실행하거나 gh auth login을 실행하도록 알리고 중지합니다.

저장소 이름이 sigma-build-factory로 끝나면 중지합니다. 이슈는 작업 저장소에 속합니다.

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을 호출자에게 반환하십시오. 레이블을 확인하지 말고 질문하지 마십시오.

호출자가 목록 또는 이슈를 가지고 있거나, 쓰기 경로가 3단계로 계속되면 완료됩니다.

3단계 - 예 게이트

입력에서 세 가지 "예" 케이스 중 하나로부터의 핸드오프는 제출할 준비가 된 것입니다.

이 세션에서 "예" 없이 직접 배치(2개 이상의 이슈): 각 항목에 대해 제목, 종류, 부모 및 모드를 표시합니다. 한 번 묻습니다: "이 이슈들을 제출할까요?" 기다리십시오. 침묵은 제출하지 않습니다.

직접 단일 이슈: 제목, 종류 또는 기능 라인의 부모가 누락된 경우 한 번 묻습니다. 해당 필드가 존재하면 제출합니다.

이 세션에서 "예" 없이 업데이트: 이슈 번호와 제목을 표시하고, 한 번 묻고, 편집합니다. 두 번째 이슈를 생성하지 마십시오.

"예"가 기록되거나, 완전한 단일 생성이 제출 준비가 되면 완료됩니다.

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단계 - 기존 이슈 일치 확인

이슈를 나열하고 정확한 제목 SPEC: <이름>, EPIC: <이름>, TICKET: <이름>과 비교합니다.

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

확인된 업데이트는 해당 번호를 편집합니다. 생성하지 않습니다. 새 제목이 이미 다른 이슈에 있으면 해당 항목을 중지하고 두 번호를 모두 보고합니다.

정확히 일치하는 제목을 하나 찾은 생성은 exists를 보고하고 해당 번호를 재사용합니다. 두 번째 이슈를 생성하지 않고 본문을 편집하지 않습니다. 정확히 일치하는 제목이 두 개 있으면 해당 항목을 중지합니다.

각 항목이 생성, 업데이트, 재사용 또는 충돌인 경우 완료됩니다.

6단계 - 생성 또는 편집

본문을 임시 파일에 씁니다. 작업 저장소에 쓰지 마십시오.

짧은 이름에 접두사가 없으면 제목에 접두사를 설정합니다. 접두사를 두 번 붙이지 마십시오.

순서대로 생성: EPIC은 그 하위 티켓보다 먼저, 차단자는 의존 항목보다 먼저. 핸드오프가 부모를 지정하면 --parent를 추가합니다. 차단자 번호가 이미 존재하면 --blocked-by를 추가합니다. 값이 없으면 각 플래그를 생략합니다.

gh issue create --repo "$REPO" --title "<제목>" --label "<레이블>" --body-file "$f"

URL에서 N을 파싱합니다. 브랜치 라인이 없거나 여전히 {N}을 포함하는 티켓 본문은 라인이 agent/<N>-<슬러그>가 되도록 편집됩니다. 슬러그는 접두사 뒤의 이름으로, 소문자로 바꾸고 공백을 하이픈으로 바꾼 것입니다.

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

확인된 업데이트에서 gh issue edit는 제목과 본문을 교체하고 레이블을 수정합니다. 일치하는 하나의 모드 레이블만 남기고 다른 모드 레이블을 제거합니다. 편집 시 부모를 변경하지 마십시오.

SPEC은 spec 레이블만 가져옵니다. EPIC은 type:epic만 가져옵니다. TICKET은 type:ticket과 하나의 모드 레이블을 가져옵니다.

gh 실패를 기록하고 독립 항목을 계속 진행합니다. 실패한 EPIC의 하위를 생성하지 마십시오. 부모를 닫지 마십시오.

gh issue view <N> --json title,labels,body에 제목, 레이블, 그리고 티켓의 경우 모드와 일치하는 Branch agent/<N>-<슬러그>가 표시되면 완료됩니다.

7단계 - 반환

각 항목에 대해 번호, 제목 및 URL을 반환합니다. exists 및 실패를 포함합니다.

호출자가 다른 스킬이면 거기서 중지합니다. 해당 스킬이 다음 명령을 지정합니다. 사용자가 /sigma-create-ticket을 호출한 경우, 다음 명령을 지정하고 호출하지 마십시오. SPEC은 /sigma-to-tickets <N>으로 이동합니다. 티켓은 /sigma-implement <N>으로 이동합니다. EPIC의 경우, /sigma-implement가 EPIC을 거부한다고 말합니다.

엄격한 규칙

규칙	이유 / 위반 예시
이 스킬은 `gh issue create` 또는 `gh issue edit`를 실행하는 유일한 스킬입니다. 다른 스킬을 위한 목록 및 보기도 여기서 실행됩니다.	두 번째 쓰기 경로는 제목, 레이블 및 부모를 표류시킵니다.
다섯 개의 레이블을 확인한 다음 생성 또는 편집합니다.	누락된 레이블은 배치의 다음 이슈를 실패시킵니다.
확인된 업데이트는 해당 이슈를 편집합니다. 정확한 제목 일치는 중복을 생성하지 않습니다.	두 번째 `SPEC:` 또는 `TICKET:`은 하나의 기능을 분할합니다.
직접 배치는 "예"를 기다립니다. 이미 `/sigma-to-spec` 또는 `/sigma-to-tickets`에 의해 이 세션에서 확인된 본문은 두 번째 질문을 받지 않습니다.	다시 묻는 것은 핸드오프를 지연시킵니다. 침묵 상태에서 직접 배치를 제출하면 사용자가 보지 못한 이슈를 생성합니다.
생성 후 티켓을 편집하여 Branch가 `agent/<N>-<슬러그>`가 되도록 합니다. 모드 레이블은 모드 라인과 일치합니다.	남은 `{N}` 또는 `agent:hitl`과 `afk`는 빌더를 잘못된 브랜치나 잘못된 모드로 보냅니다.
핸드오프가 부모를 지정하면 생성 시 부모를 설정합니다. SPEC의 티켓은 EPIC 또는 SPEC을 부모로 합니다. 리뷰의 티켓은 핸드오프가 EPIC을 지정하지 않는 한 부모를 생략합니다.	SPEC 부모를 임의로 생성하면 리뷰 티켓이 구현하지 않는 승인 기준을 복사합니다.
구현, 리뷰, 병합하지 마십시오.	이 스킬은 이슈를 제출하고 중지합니다.

검증

gh repo view가 작업 저장소를 반환했으며, 저장소 이름이 sigma-build-factory로 끝나지 않습니다.
생성 또는 편집 전에 CONVENTIONS.md를 읽었습니다.
list-specs 및 view는 JSON을 반환하고 생성하지 않았습니다.
생성 또는 편집 전에 다섯 개의 레이블이 존재합니다.
직접 배치는 명시적인 "예"를 받았습니다. 이 세션에서 상위 스킬의 "예"는 두 번째 질문을 받지 않았습니다.
확인된 업데이트는 명명된 이슈를 편집했습니다. 해당 정확한 제목을 공유하는 두 번째 이슈가 없습니다.
새 티켓의 Branch 라인은 agent/<N>-<슬러그>이며, 모드 레이블이 모드 라인과 일치합니다.
SPEC의 EPIC은 해당 SPEC을 부모로 합니다. SPEC의 티켓은 EPIC 또는 SPEC을 부모로 합니다. 리뷰의 티켓은 핸드오프가 EPIC을 지정하지 않는 한 SPEC 부모가 없습니다.
반환값은 번호, 제목 및 URL입니다. 이 스킬은 구현, 리뷰, 병합을 수행하지 않았습니다.

sigma-create-ticket