task-submit

task 제출

사용: /task-submit — 반드시 task 작업 공간(.worktrees/ 하위) 안에서 실행돼야 한다. AGENTS.md의 추출 기준과 위키 규칙을 따른다. 절차:

0. 불변식 검사 (백스톱): workbench task check 를 실행한다. 위반(exit 1)이면 먼저 해소한 뒤 제출을 진행한다 — 훅이 다 없어도 제출은 검사를 통과해야 한다.

1. task 전체를 읽는다: task/index.md, task/log.md, task/status.md, task/docs/* — 이 task가 무엇을 했고 무엇을 배웠는지 파악한다.

2. 증분 후보 식별·분류 (판단, 아무것도 쓰지 않는다): task harvest와 task 중 생긴 워크벤치 자체 개선(utils/, 스키마 등)을 AGENTS.md 추출 기준으로 훑어 후보를 세 버킷으로 나눈다. 이 단계에서 docs/·AGENTS.md·skills/ 를 수정하지 않는다 — 분류만 한다.

   • 후보가 AGENTS.md, README.md, skills/, .agents/skills, .claude/skills, .codex/, .worktrees/, .codebases/, .gitignore처럼 에이전트 지침·스킬 탐색·도구 상태·작업 공간 탐색성에 영향을 주면 audit-codex-support 스킬을 호출해 Codex 지원성 리스크를 점검하고, 그 결과를 후보 보고의 리스크나 후속 티켓 이관 후보에 반영한다.
   • 절차 졸업 점검 (지식 harvest와 나란히): 지식이 docs/로 살아남는지 보는 것과 별도로, 이 task에서 한 반복될 완결 절차가 스킬·runbook·utils로 졸업할 만한지 skill-harvest-recommender로 점검한다. 산출은 보통 이 PR의 증분이 아니라 후속 티켓이므로(스킬 제작은 ticket→task→PR을 따로 거친다), 찾은 후보는 "후속 티켓 이관" 버킷에 넣는다. 없으면 넘어간다 — 대부분의 task는 졸업할 절차가 없는 게 정상이다.
   • 추출할 것이 정말 없으면 (docs/ 변경 없음 → submit이 거부함) 그대로 멈추고 사용자에게 보고한다 — "왜 안 됐는지"조차 남길 게 없는지 한 번 더 확인한 뒤에. 빈 증분을 억지로 만들지 않는다.

3. 후보 보고 + 승인 게이트 (사람 게이트): 아래 보고 형식대로 후보 목록과 추천을 보여주고 반드시 묻는다 — "이대로 흡수할까요? (그대로 진행 / 수정 지시 / 일부만)".

   • 사용자가 승인/수정 지시하기 전에는 docs/·AGENTS.md·skills/ 등 main에 살아남을 어떤 파일도 수정하지 않는다. 흡수는 비가역에 준하는 결정이라 사람의 몫이다.
   • 이 질문은 어떤 경우에도 생략하지 않는다 — "알아서 해줘", "빨리"라는 지시는 작업을 위임한 것이지 흡수 결정을 위임한 것이 아니다.
   • 후속 티켓 이관 후보를 사용자가 승인하면, 이 단계에서 gh issue create로 티켓 생성을 제안한다 (실행은 사용자 확인 후).
   • 승인 결과(흡수할 후보 목록)를 다음 단계로 넘긴다.

4. docs/ 반영 (판단): 승인된 harvest(경로 A)만 대상으로 /docs-ingest 스킬을 호출해 docs/에 짜 넣는다. 호출 시 승인 범위를 명시해 ingest가 그 범위로 한정하게 한다. 경로 B(직접 커밋)는 이미 task 브랜치에 있으니 docs-ingest를 거치지 않는다. 승인되지 않은 후보는 반영하지 않는다.

5. 추출 결과를 task 브랜치에 커밋한다.

6. 불변식 재검사 (최종 백스톱): 추출 커밋 뒤 workbench task check 를 다시 실행한다. 위반(exit 1)이면 먼저 해소한다. workbench task submit도 cleanup 직전 같은 검사를 실행하므로, skill 절차와 배관이 같은 최종 경계를 공유한다.

7. PR 산문 작성 (판단): 제목과 본문을 작성한다. 본문은 .github/PULL_REQUEST_TEMPLATE.md의 5섹션 골격을 따른다 (--body-file로 넘기면 GitHub 템플릿이 무시되므로, 골격을 직접 반영한다). harvest PR이므로 각 섹션을 증분 관점으로 채운다 —

   • 배경: task ID·이슈 링크, (있다면) codebase PR 링크 — 어디서 왔나
   • 목표: 무엇이 증분인가 (추가/갱신된 문서·도구와 그 요지)
   • 검증: docs-lint·상호참조 무결성 (사소하면 한 줄)
   • 특이사항: supersede·재오픈한 결정, 남긴 교훈
   • 참고 자료: 관련 docs 페이지 링크
   • 맨 위에 AI 작성 callout을 둔다 (템플릿 첫 줄과 동일, 작성 에이전트·모델 기입). 빈 섹션은 지운다.
   • 본문을 임시 파일로 저장한다 (예: /tmp/pr-body-<ID>.md).

8. 배관 실행: workbench task submit --title "<제목>" --body-file <파일>

   • 이 명령이 task/ cleanup 커밋 → push → PR 생성까지 한다.
   • PR 생성이 성공하면 task-submitted lifecycle event를 남긴다. PR 생성 실패 시에는 submitted event를 남기지 않는다.

9. 사람 게이트: PR URL을 보여주고 반드시 묻는다 — "PR 머지를 기다릴까요, 아니면 작업 공간을 지금 정리할까요?"

   • 정리를 원하면 /task-done <ID> 절차로 넘어간다.
   • 대기를 원하면 여기서 멈춘다 (머지 후 /task-done).

   이 질문은 어떤 경우에도 생략하지 않는다:

   • 사용자가 "알아서 해줘", "빨리 끝내줘"라고 했어도 — 그 지시는 작업을 위임한 것이지, 머지라는 비가역 결정을 위임한 것이 아니다
   • 연속 작업 중이라 흐름을 끊기 싫어도 — 멈추는 것이 절차다

---

보고 형식 (3단계 — 증분 후보 보고)

후보를 버킷으로 나눠 아래 표로 보고한다. 특정 하네스 도구(선택지 UI 등)에 의존하지 않는 순수 마크다운으로 쓴다 — 에이전트 중립(어느 도구에서 실행돼도 같게 읽힌다). 승인은 사용자의 자유 응답으로 받는다.

흡수 추천은 처리 경로로 가른다 — A. docs-ingest weave(harvest: decision/lesson/runbook은 docs-ingest가 docs/에 짜 넣는다)와 B. 직접 커밋 (skills/·AGENTS.md·utils/·.gitattributes 등은 이미 task 브랜치에 커밋돼 PR diff로 직행, docs-ingest 비대상). 4단계 docs-ingest는 A만 대상으로 한다.

## 증분 흡수 후보 보고

### ✅ 흡수 추천 — A. docs-ingest weave (harvest)
| 후보 | 유형 | 요지 | 이유 | 리스크 |
|---|---|---|---|---|
| <이름> | decision/lesson/runbook | <한줄> | <왜 올리나> | <있으면> |

### ✅ 흡수 추천 — B. 직접 커밋 (PR diff 직행, docs-ingest 비대상)
| 후보 | 유형 | 요지 | 이유 | 리스크 |
|---|---|---|---|---|
| <이름> | skills/AGENTS/utils/.gitattributes/스키마 | <한줄> | <왜 올리나> | <있으면> |

### ⏸ 흡수 비추천
| 후보 | 왜 안 올리나 |
|---|---|
| <이름> | <task 고유 맥락 / codebase 귀속 / 재도출 가능 등> |

### ➡ 후속 티켓 이관
| 후보 | 왜 별도 티켓 | 제안 제목 |
|---|---|---|
| <이름> | <이 task 범위 밖 / 더 큰 결정 필요 등> | <이슈 제목안> |

흡수 추천을 이대로 반영할까요? (그대로 진행 / 수정 지시 / 일부만)

• 비어 있는 버킷은 "(없음)"으로 표기하고 표는 생략해도 된다.
• 각 후보는 출처(task harvest 파일 또는 변경 파일)를 식별 가능하게 적는다.
• 리스크 칸엔 흡수했을 때의 위험(기존 결정과 모순 가능, supersede 필요 등)을 적는다 — 없으면 비운다.
• audit-codex-support를 호출한 경우, 발견된 Codex 지원성 리스크나 "리스크 없음" 판단을 관련 후보의 리스크 칸 또는 별도 짧은 메모로 포함한다.