---
name: vibe-implement
description: 사용자가 이미 합의된 명세, 티켓, 계획의 구현, 빌드, 배포를 요청할 때 사용한다.
disable-model-invocation: true
---

# 작업 구현

사용자가 명세나 티켓에 기술한 작업을 구현한다. `/vibe-implement execute <plan>`은 합의된 실행 계획을 별도 실행자에게 맡기고 검토하는 감독 진입점이다.

## 호출 경계

다른 절을 적용하기 전에 입력과 호출자의 역할을 확인한다.

- `execute <plan>` 또는 `Kind: execution-plan` / `Kind: design-spike`인 계획을 실행하라는 입력은 [EXECUTE.md](EXECUTE.md)를 전부 읽고 감독 절차로 처리한다. `execute` 단어가 없어도 계획 전용 입력을 일반 직접 호출로 처리하지 않는다.
- 감독자는 전체 계획과 작업공간 할당 기록을 파견된 원자 실행자에게 전달한다. 그 기록을 받은 파견된 원자 실행자는 다시 감독자가 되거나 실행을 재위임하지 않는다. 같은 구현 핵심(TDD, 검증, 읽기 전용 검토)을 사용하되, `EXECUTE.md`의 권한·상태·반환 계약을 따른다.
- 일반 명세·티켓 호출과 `vibe-goal`이 미리 할당한 작업공간을 사용하는 호출은 아래 계약을 따른다. 실행 계획이 아닌 기존 명세·티켓·결정지도를 임의 변환하지 않는다. `execute` 입력의 형식이 불충분하면 일반 직접 호출로 우회하지 않고 `/vibe-plan`에 반환한다.

감독 경로와 그 실행자에는 아래 소규모 작업이나 Git이 아닌 저장소에서 제자리로 실행하는 예외, 일반 완료 처분, 담당자 지정, 트래커 갱신, 게시·정리 규칙을 적용하지 않는다. 감독자는 직접 구현하지 않고 계획·색인의 실행 상태와 근거만 기록한다. 실행자도 계획·색인을 갱신하지 않는다. 실행 계획의 작성·검토·reconcile·`--issues`는 [vibe-plan의 EXECUTION-PLAN.md](../vibe-plan/EXECUTION-PLAN.md)가 소유한다.

## 계획 경계

이 스킬은 계획 계열 작업을 결코 수행하지 않는다. 트리아지, 탐색, 명세 작성이나 수정, 분해, 티켓 생성이나 분할, 티켓 게시, 계획 수정을 하지 않는다. 구현은 이미 합의된 명세·티켓 또는 감독 절차가 검증한 실행 계획에서만 시작한다. 감독 절차의 실행 상태 기록은 계획 내용 수정과 구분한다.

입력에 계획이 필요하거나, 계획이 잘못됐거나 명세가 불충분하면, 구현을 멈추고 작업을 호출자나 `/vibe-plan`/`/vibe-deep-plan`에 돌려보낸다. 이 스킬 안에서 계획을 고치거나 바꾸지 않는다.

## 완료 소유권

`vibe-implement`는 모드별 복제 없이 원자적인 단일 작업을 실행한다. 감독 진입점은 이 작업을 별도 실행자에게 맡기는 호출 경계이며, 두 번째 구현 모드가 아니다.

호출자(예: `vibe-goal`)가 원장이나 인계 기록으로 할당 정보를 제공하면 그 작업공간을 재사용한다. 할당 정보에는 작업 단위 ID, 원래 target/ref, fixed point(검토 기준으로 삼는 커밋), 브랜치, worktree 경로, 소유자와 상태가 포함된다. 할당 정보가 없으면 아래 작업공간 격리 규칙에 따라 작업공간 하나를 만든다.

같은 논리 작업의 구현, 검토, 검토 결과 수정, 재개는 정확히 같은 작업공간을 사용한다. 두 번째 작업공간은 추가하지 않는다. 현재 worktree 경로(`.agents/worktrees/*`)나 브랜치 이름(`vibe/*`)은 상태를 판단하는 근거가 아니다. 이 스킬은 `vibe-goal` 내부의 `caller-supplied` 같은 모드 분기를 소유하지 않는다.

어떤 파일도 편집하거나 명령을 실행하기 전에 같은 논리 작업의 기존 **작업공간 기록**을 찾는다. 구현, 검토, 검토 결과 수정, 이전 실행 재개는 모두 같은 작업이다. 작업공간 기록은 작업 단위 ID를 원래 target/ref, fixed point, 브랜치, worktree 경로, 기록 시점의 소유자와 상태에 연결한다. 이 기록은 외부에서 공급한 할당 기록이나 실행 자체의 이전 반환 기록에 있다.

기존 작업의 기록이 하나뿐이고 다른 활성 소유자가 없으면 그 작업공간만 사용한다. 기존 worktree에서 모든 작업을 이어간다. worktree가 제거됐으면 유지된 브랜치에 다시 연결한다. 새 번호 브랜치와 같은 작업을 위한 새 브랜치나 worktree는 만들지 않는다. 원래 fixed point를 유지한다. 현재 HEAD에서 다시 계산하지 않는다.

기존 작업의 기록이 없거나 후보가 둘 이상이거나 다른 활성 소유자가 있거나 예상치 못한 head나 안전하지 않은 더티 상태가 있으면 멈추고 보고한다. 브랜치 이름, 번호, slug, 최신 `vibe/*`만으로 상태를 추측하지 않는다. 같은 작업을 위한 새 브랜치나 worktree를 만들지 않는다.

기록이 없는 새 논리 작업이면 그 작업을 시작할 때의 커밋(`git rev-parse HEAD`)을 검토 기준 커밋인 **fixed point**로 기록한다. 아래 작업공간 격리 규칙에 따라 작업공간 하나를 만든다. 완료 반환 기록에 그 작업공간을 적는다.

## 작업공간 격리

변경 크기를 분류하기 전에 완료 소유권 규칙에 따라 기록을 찾는다. 같은 논리 작업의 기존 기록이 있으면 변경 크기와 관계없이 그 기록이 지정한 작업공간을 사용한다. 한 줄 검토 결과 수정과 재개도 이 조건에 포함한다. 기존 worktree에서 구현, 테스트, 검토 결과 수정, 재개를 계속한다. worktree가 제거됐으면 유지된 브랜치에 worktree를 다시 연결한다.

그 작업공간에서 계속되는 작업은 아래 선형성 규칙에서 제외한다. 원래 checkout으로 보내지 않는다. 외부에서 할당 기록을 공급받았으면 그 기록이 지정한 작업공간만 사용한다. 통합 브랜치 사용은 금지한다. 같은 논리 작업을 재시도할 때 두 번째 작업공간을 추가하는 행위도 금지한다.

외부에서 할당한 작업공간의 기록이 누락되거나 모호하면 멈추고 보고한다. 새 작업공간을 만드는 허가로 보지 않는다. 기존 기록이 없는 새 논리 작업이면 요청된 변경을 분류한다. 단일 파일 변경이나 사소한 변경은 격리 임계값 이하이므로 제자리에서 진행한다. 이 경우 전용 worktree를 만들지 않는다.

기록이 없는 큰 변경은 프로젝트가 최소 하나의 커밋을 가진 Git 저장소일 때만 격리한다. `git rev-parse HEAD`가 성공해야 한다. 이 조건을 충족하면 원래 checkout을 편집하지 않고 전용 worktree에서 작업한다:

1. 브랜치 이름을 `vibe/{number}-{function}`로 짓는다. `{number}`는 기존 `vibe/*` 브랜치 중 다음 순차 번호(1부터 시작), `{function}`은 기능의 짧은 kebab-case slug(예: `vibe/3-user-auth`).
2. 다음 명령으로 fixed point에서 브랜치와 worktree를 만든다: `git worktree add .agents/worktrees/{number}-{function} -b vibe/{number}-{function}`.
3. `.agents/worktrees/`가 git-ignore 되어 있는지 확인한다.
4. 모든 구현, 테스트, 검토를 그 worktree 안에서 한다.

작업 브랜치를 구현 소스로 유지하고 원래 브랜치는 바꾸지 않는다. 같은 논리 작업의 초기 구현, 검토 결과 수정, 모든 재개는 기록이 지정한 작업공간에서 이어 간다. 새 브랜치나 worktree를 추가하지 않는다. 계속되는 실행에서도 새 `vibe/{next-number}-*` 브랜치를 만들지 않는다. 한 번의 실행에서 만드는 브랜치는 최대 하나고 worktree도 최대 하나다. 작업 브랜치의 이력은 선형으로 유지한다.

원래 브랜치, 통합 브랜치, target은 작업 브랜치에 머지하지 않는다. base에 새 커밋이 생기면 공급 여부를 확인한다. 외부 공급 기록이 없으면 작업 브랜치를 새 base 위로 rebase한다. 외부 공급 기록이 있으면 직접 머지하거나 rebase하지 않고 바뀐 base를 호출자에게 보고한다.

외부에서 공급한 작업공간에서는 추가 브랜치나 worktree를 만들지 않는다. 원래 target checkout은 수정할 수 없다. 작업 브랜치를 게시하거나 머지하지 않는다. 반환 후 공급된 worktree를 정리, 삭제하거나 변경하지 않는다. 호출자가 해당 작업공간을 소유하고 처분한다.

검토된 작업을 커밋한 후 아래 완료 처분을 따른다. 자동 머지는 하지 않는다. 완료 반환 기록에는 작업 단위 ID, 원래 target/ref, fixed point, 브랜치, worktree 경로, 기록 시점의 소유자와 상태를 포함한다. 같은 논리 작업의 후속 검토 결과 수정이나 재개는 이 기록이 지정한 작업공간을 재사용한다. 새 작업공간을 만들지 않는다.

저장소에 아직 커밋이 없으면(또는 프로젝트가 git 저장소가 아니면), 격리를 건너뛰고 제자리에서 작업한다.

## 티켓 담당자 지정

파일을 편집하기 전에 구현 대상 티켓의 담당자를 지정한다. 대상은 호스티드 트래커(GitHub, GitLab)의 구현 티켓 하나다. 부모 명세 이슈는 지정하지 않는다. 다음 경우에도 지정하지 않는다.

- 입력이 local Markdown 티켓이거나 프로젝트가 Git 저장소가 아니다.
- `docs/agents/issue-tracker.md`가 없거나 담당자 지정 절이 없다.
- 대상 이슈 번호를 확인하지 못했다.

절차는 `docs/agents/issue-tracker.md`의 담당자 지정 절을 따른다. 먼저 현재 담당자를 읽는다. 내가 아닌 담당자가 있으면 목록을 덮어쓰지 않고 그 사실을 보고한 뒤 구현을 계속한다. 지정한 뒤 같은 절차로 다시 읽어 인증된 사용자가 담당자에 있는지 확인한다.

지정에 실패하거나 확인하지 못하면 구현을 멈추지 않는다. 실패한 명령과 확인 결과를 최종 보고에 적는다. 완료해도 담당자를 해제하지 않는다. 사람이 머지할 때까지 인증된 사용자가 담당자로 남는다.

## 구현

사전에 합의한 경계에서 테스트 우선으로 구현한다. [TDD.md](TDD.md)를 따른다. TDD 문서는 red → green 루프, 경계 규칙, 피해야 할 안티 패턴을 다룬다.

필요에 따라 읽는 참고 문서:

- [TDD.md](TDD.md): red → green 루프와 그 규칙
- [tests.md](tests.md): 좋은 테스트가 어떤 모습인지, 예시 포함
- [mocking.md](mocking.md): 언제 모킹할지, 대신 무엇을 모킹할지
- [MERGE-CONFLICTS.md](MERGE-CONFLICTS.md): 진행 중인 머지나 rebase 충돌 해결

타입 검사와 단일 테스트 파일 검사는 작업 중 되풀이한다. 전체 테스트 스위트는 마지막에 한 번 실행한다.

## 커밋 서명

이 워크플로의 커밋은 사람이 아닌 AI가 작성하므로, 사람이 만든 것처럼 서명해서는 안 된다. `git commit`에 `-S`, `--gpg-sign`, `--signoff`를 결코 전달하지 않는다. 저장소나 전역 설정이 커밋 서명을 기본으로 켜면(`commit.gpgsign = true`), 매 커밋에서 `git -c commit.gpgsign=false commit …` 명령을 실행한다. 이 명령은 AI가 작성한 커밋에 서명을 붙이지 않는다. 이 규칙은 구현 커밋에 포함되는 인수 체크박스 편집에도 적용된다.

## 완료 처분

1. **트래커 설정을 확인한다.**
   1. [설정 문서와 기본값](../vibe-init/references/defaults.md)에 따라 `docs/agents/issue-tracker.md`가 있으면 읽는다.
   2. 그 파일이 없고 다른 선택도 명시되지 않았으면 이 스킬에 들어 있는 로컬 Markdown 규칙을 사용한다.
   3. 초기화를 요구하거나 설정 파일을 만들지 않는다.
2. **작업 브랜치에서 읽기 전용 검토를 수행한다.**
   1. 작업 브랜치에서 `vibe-review` 스킬을 로드해 그 지침을 따른다.
   2. 시작할 때 기록한 fixed point를 기준으로 작업 브랜치를 검토한다.
   3. 구현된 명세나 티켓을 검토 입력으로 제공한다.
   4. 켠 검토 축에 필요한 출처가 그 입력에 있는지 확인한다.
   5. 위험 요청이나 고위험 변경이면 `/vibe-review`의 규칙에 따라 Risk를 켠다.
   6. 이 스킬은 Risk의 별도 조건을 만들지 않는다.
   7. 작업공간 할당 기록에서 fixed point를 확인한다.
   8. 사용자에게 fixed point를 묻지 않는다.
   9. `/vibe-review`는 읽기 전용이다.
   10. 검토 결과를 보고한다.
   11. 이슈 본문, 체크박스, 코멘트, 라벨, 상태를 바꾸지 않는다.
   12. 통과한 검토는 이슈 닫기를 승인하지 않는다.
3. **검토 결과에 따라 완료 처분을 한다.**
   1. 읽기 전용 검토에 미해결 결과가 없으면 검토된 작업을 작업 브랜치에 커밋한다.
   2. 이 조건을 충족하면 사람이 머지하기 전에 [트래커 갱신](#트래커-갱신) 규칙에 따라 인수 체크박스를 켠다.
   3. 외부 공급 기록의 유무에 따라 완료 처분을 선택한다.
   - **외부 공급 기록이 있는 경우(예: `vibe-goal`이 공급한 할당 작업공간).** 공급된 작업 브랜치에 직접 커밋한다. 공급된 base 위에서 이력을 선형으로 유지한다. 추가 브랜치나 worktree를 만들지 않는다. 작업 브랜치를 게시하거나 지속 산물로 취급하지 않는다.

     직접 정리하지 않고, 원래 target에 머지하거나 반영하지도 않는다. 호출자에게 반환한 뒤 공급된 worktree를 정리, 삭제하거나 변경하지 않는다. 호출자가 작업공간을 소유하고 처분한다.

     호스티드 트래커에서는 [트래커 갱신](#트래커-갱신)에 따라 인수 체크박스만 켠다. 이슈를 닫거나 종료 상태를 바꾸지 않는다. 버전 관리 대상인 local Markdown 티켓 파일은 브랜치 내용이다. [트래커 갱신](#트래커-갱신) 규칙에 따라 그 파일을 티켓 커밋에 포함한다.

     다음 정보를 반환한다: 작업 브랜치 이름, 공급된 티켓의 정확한 base SHA, 정확한 검토 head SHA, 검증 근거, 읽기 전용 `/vibe-review`의 판정과 보고서. 공급된 base에 새 커밋이 생겼으면 그 변화를 설명하는 메모도 반환한다. 한 줄 재개 기록에는 작업 단위 ID, 작업 브랜치, worktree 경로, 기록 시점의 소유자와 상태를 적는다. 이후 같은 티켓의 검토 결과 수정이나 재시도는 새 브랜치나 worktree를 만들지 않고 정확한 작업공간을 재사용한다. 호출자가 통합과 최종 반영을 소유한다. 다른 반환 정보는 덧붙이지 않는다.

   - **외부 공급 기록이 없는 직접 호출.** 작업 브랜치 하나만 유지하고 worktree는 남기지 않는다. 검토된 `vibe/*` 작업 브랜치를 fixed point 위에 선형으로 유지한다. target에 새 커밋이 생기면 작업 브랜치를 그 위로 rebase한다. 병합 커밋은 만들지 않는다. 그 브랜치를 원래 target에 반영하지 않고 구현 소스로 유지한다.

     local Markdown 트래커에서는 worktree를 제거하기 전에 머지되지 않은 작업 브랜치가 유지됐는지 확인한다. 브랜치 이름을 보고한다. GitHub에서는 작업 브랜치를 push한다. 원래 브랜치를 대상으로 pull request를 만든다. GitLab에서는 작업 브랜치를 push한다. 원래 브랜치를 대상으로 merge request를 만든다.

     호스티드 트래커에서는 게시 전에 인수 체크박스를 켠다. [트래커 갱신](#트래커-갱신)의 네이티브 닫기 자격에 따라 PR/MR 본문에 닫기 참조나 닫기 키워드가 없는 참조를 넣는다. 게시 직후 target 브랜치와 닫기 대상 이슈 목록을 검증한다. 이슈를 직접 닫지 않는다. 자동 머지는 하지 않는다. pull request나 merge request를 지원하는 다른 호스티드 트래커에서는 문서화한 게시 절차를 따른다.

     worktree에 커밋하지 않은 변경이 있으면 제거 후 복구할 수 없다. 브랜치를 유지하거나 게시하는 일이 성공한 후에만 worktree를 제거한다. 유지된 브랜치 이름을 보고한다. 호스티드 트래커에서는 요청 URL도 보고한다.

     한 줄 재개 기록에 작업 단위 ID, 원래 target/ref, fixed point, 유지된 브랜치, worktree 경로, 기록 시점의 소유자와 상태를 적는다. worktree를 제거했다면 경로를 빈 값으로 둔다. 이후 검토 결과 수정이나 재개에서는 새 `vibe/*` 브랜치를 만들지 않고 그 브랜치에 worktree를 다시 연결한다. 한 번의 실행에서 다른 `vibe/*` 브랜치나 worktree를 남기지 않는다. 자동 머지는 하지 않는다. 원래 브랜치는 그대로 둔다.

이번 작업에서 비롯되지 않은 더티 상태, 충돌의 원인을 알 수 없는 상황, 다른 안전하지 않은 조건이 안전한 처분을 막으면 게시, 머지, 정리, 삭제를 하지 않는다. 원본과 결과 브랜치와 커밋을 보존한다. 사용자 상태는 변경하지 않고 차단 요소를 보고한다. 처분이 안전해진 뒤에만 브랜치나 worktree를 제거한다. 진행 중인 머지나 rebase 충돌은 [MERGE-CONFLICTS.md](MERGE-CONFLICTS.md)를 따른다.

## PR/MR 본문의 검증 근거와 위험

완료 처분에 따라 PR/MR을 게시하는 경우에만 적용한다. 저장소의 기존 템플릿과 도메인 용어를 유지하면서 다음 내용을 짧게 덧붙인다.

- **변경 전후의 증거.** 주요 동작 주장마다 이미 수집한 변경 전후의 관찰값을 짝지어 제시한다. 시각적 변경이고 환경이 지원하면 화면을 비교하고, 그 외에는 실제 실패→통과 테스트나 실행 결과와 재현 명령을 제시한다. 테스트의 핵심 단계를 짧게 설명하고, 단순히 "테스트 통과"라고만 쓰지 않는다. 이전 증거가 없으면 그 한계와 이유를 밝힌다. 실행 결과를 지어내거나 양식을 채우려고 위험한 운영 재현을 하지 않는다. 로그·화면의 비밀값과 개인 식별 정보는 가린다.
- **되돌리기와 영향 범위.** 단순히 되돌릴 수 있는지 밝힌다. 데이터 삭제, 마이그레이션, 외부 변경은 별도 복구가 필요한지 적는다. 실제로 영향을 받는 호출자, 데이터, 화면을 적는다. 확인하지 못한 위험은 불확실하다고 밝힌다.
- **변경을 설명하는 가장 작은 도식.** 글보다 구조가 잘 드러나는 변경이면 요약에 표현 하나를 고른다. 로직은 의사코드로 나타낸다. 실행 흐름은 호출 트리로 나타낸다. 파일 책임은 얕은 파일 트리로 나타낸다. 컴포넌트 상호작용이나 데이터 흐름은 Mermaid로 나타낸다.

  주변 형태가 이미 있고 바뀌는 점이 핵심이면 diff를 쓴다. 도식은 설명하는 짧은 문장 옆에 둔다. 지금 밝히려는 점에 필요한 요소만 남긴다. 도식은 하나만 쓰거나 둘 이상 쓸 수 있다. 양식을 채우려고 도식을 늘리지 않는다.

- **권한과 참조 유지.** 이 형식은 게시·머지·이슈 닫기 권한을 추가하지 않는다. 닫기 참조의 자격과 게시 뒤 검증은 아래 트래커 갱신 규칙을 그대로 따른다. 외부 공급 작업공간은 PR/MR을 만들지 않고 기존 반환 계약에 따라 검증 근거를 호출자에게 전달한다.

## 트래커 갱신

- **Local Markdown, 버전 관리됨.** 티켓 파일은 외부 시스템이 아닌 브랜치 내용이다. 작업 브랜치의 worktree 안에서 해당 티켓의 인수 체크리스트에 있는 인수 체크박스를 `[X]`로 바꾼다. 그 편집을 구현과 같은 커밋에 포함한다. 별도 트래커 커밋, 코멘트, 원래나 target 브랜치의 커밋은 없다. 원래 target 브랜치에 머지됐다는 근거를 기다리지 않는다. 트래커 변경 승인을 요구하지 않는다.

  사용자가 머지를 결정한다. 사용자가 머지하면 코드와 체크리스트가 함께 반영된다. 머지하지 않으면 둘 다 반영되지 않는다. `상태:` 줄을 바꾸지 않는다.

- **호스티드 트래커(GitHub, GitLab, 기타 호스티드 트래커).** 인수 체크박스와 이슈 닫기는 별개다. 머지는 사람이 하며 에이전트는 하지 않는다. 게시는 반영이 아니다.
  - **체크리스트.** 읽기 전용 검토에 미해결 결과가 없으면 외부 공급 기록이 없는 직접 호출에서는 PR/MR 게시 전에 인수 체크박스를 켠다. 외부 공급 기록이 있는 호출에서는 호출자에게 반환하기 전에 그 체크박스를 켠다. 반영 증명을 기다리지 않는다. 체크박스 전용 승인을 요구하지 않는다. 에이전트가 직접 이슈를 닫지 않는다. 자격 있는 PR/MR에서는 사람이 UI에서 머지할 때 provider가 provider-native 방식으로 이슈를 자동으로 닫는다.
  - **네이티브 닫기 자격.** 외부 공급 기록이 없는 직접 호출이고 PR/MR의 target이 provider default 브랜치일 때만 자격이 있다. 머지로 인수가 끝나는 정확한 구현 티켓 하나여야 한다. 부모 명세 이슈는 닫기 대상이 아니다. 명세와 유일한 티켓이 한 이슈에 합쳐 적혀 있으면 그 이슈 자체가 티켓이므로 자격이 있다. 외부 공급 기록이 있는 호출은 게시하지 않으므로 닫기 참조를 쓰지 않는다.
  - **자격 있는 닫기.** 설정된 트래커 참고 문서에 적힌 자동 닫기 참조 규칙을 따른다. 그 규칙의 닫기 참조 구문으로 정확한 티켓 하나를 PR/MR 본문에 연결한다.

    게시 직후 같은 참고 문서에 적힌 대상 확인 명령을 그대로 실행한다. 이 명령으로 target 브랜치가 default 브랜치인지 확인한다. 닫기 대상 이슈가 그 티켓 하나인지도 확인한다. 서비스별 명령, 정확한 플래그, 확인할 필드는 그 참고 문서만을 기준으로 삼는다. 이 문서는 서비스 명령을 복제하지 않는다. 기억이나 추측으로 만든 명령을 쓰지 않는다.

    검증 결과가 기대와 다르거나 의도하지 않은 이슈가 닫기 대상에 포함되면 반환 전에 본문을 고쳐 다시 검증한다. 안전하게 멈추면 브랜치, 커밋, PR/MR을 보존하고 차단 요소를 보고한다. 검증하지 않은 상태로 반환하지 않는다.

    통과한 검토만으로는 닫기가 승인되지 않는다. 사람이 UI에서 Merge를 누르는 행위 자체가 닫기 승인이다. 머지 뒤에 별도 닫기 미리보기나 승인을 요구하지 않는다. 에이전트는 직접 머지하지 않고 이슈도 직접 닫지 않는다.

  - **자격 없을 때의 대체 절차.** target이 default 브랜치가 아니거나, 머지 뒤에도 운영·배포 게이트가 남았거나, 부모 이슈나 둘 이상의 목표가 섞여 대상을 정할 수 없으면 닫기 키워드 없는 참조만 넣는다. 이 경우 네이티브 닫기는 쓰지 않는다. 그런 티켓의 닫기는 머지 게이트가 아니다.

    검토한 커밋 SHA가 지정된 target 브랜치에 있다는 독립적인 증거를 먼저 얻는다. 예를 들어 `git merge-base --is-ancestor <commit> <target-branch>`가 성공해야 한다. 후속 또는 재개 직접 호출에서만 닫기, 상태, 코멘트의 정확한 미리보기를 보여준다. 작성 직전에 별도의 명시적 승인을 기다린다. 구현 요청, 완료된 검토, 거절, 무응답은 닫기 승인이 아니다. 승인 없이 이슈를 닫지 않는다.

어떤 트래커에서도 부모 명세 이슈를 제안하거나 수정하지 않는다. 호스티드 트래커에서 명세와 유일한 티켓이 같은 이슈이면 그것은 티켓이다. 인수 체크박스는 그 이슈에서 켠다.