| name | final-review |
| description | Use this skill before opening a PR to run final review, Fastlane CI verification, commit preparation, approved commit execution, and PR draft generation. |
final-review
목적
Twix iOS 저장소에서 PR 생성 전 또는 집중 구현/리팩터링 완료 후 사용하는 pre-PR finalization skill입니다.
이 skill은 구현 skill이 아닙니다. 기본적으로 scope 점검, 최종 리뷰, 검증, 실패 분석, 커밋 준비/실행, PR 초안 생성을 수행합니다. 명시 요청 없이는 코드를 수정하거나 리팩터링하지 않으며, PR을 열거나 push하지 않습니다.
기준 문서
항상 다음 기준을 따릅니다.
AGENTS.md
docs/Reference/Checklists.md
docs/Reference/ProjectRules.md
.pi/skills/review-twix/SKILL.md가 있으면 review standard로 사용
review-twix의 세부 규칙을 이 skill에 중복하지 않습니다. 최종 리뷰 단계에서는 review-twix 기준을 적용합니다.
금지 사항
- push 금지
- PR 생성/open 금지
- force push 금지
- 명시 요청 없는 amend / rebase / reset / stash 금지
- 명시 요청 없는 파일 수정 금지
- 명시 요청 없는 리팩터링 금지
- 명시 요청 없는 문서 수정 금지
- 테스트 생성 금지
- 구현 작업 생성 금지
- TypeScript extension 생성 금지
- 실패한 검증 숨김 금지
- secrets, env files, credentials, 예상하지 못한 generated files 커밋 금지
- tool 또는 generation source를 식별하는 commit metadata 추가 금지
검증 정책
우선 검증 명령:
bundle exec fastlane ios ci_pr
Bundler를 사용할 수 없는 경우에만 fallback:
fastlane ios ci_pr
tuist build는 표준 검증 명령으로 사용하지 않습니다.
- direct
xcodebuild scheme / destination / configuration을 invent하지 않습니다.
- direct
xcodebuild는 명시적으로 문서화되었거나 제공된 경우에만 사용합니다.
- Fastlane을 로컬에서 실행할 수 없으면 정확한 검증 한계를 보고하고, 검증이 통과했다고 말하지 않습니다.
커밋 정책
커밋 전 반드시 확인합니다.
git branch --show-current
git status --short
git diff --stat
git diff --cached --stat
- 관련 없는 파일을 커밋에 포함하지 않습니다.
- 파일을 blind stage하지 않습니다.
- unstaged changes가 있으면 staging 전에 요약합니다.
- 이미 staged changes가 있으면 사용자의 staging 의도를 보존합니다.
- staged/unstaged 변경이 여러 commit scope를 암시하면 중단하고 확인합니다.
- review에서 blocking issue가 있으면 커밋하지 않습니다.
- Fastlane 검증 실패 시 커밋하지 않습니다.
- 예상하지 못한 파일, secret, env, credential, generated file 변경이 있으면 커밋하지 않습니다.
- 사용자 승인이 없으면 커밋하지 않습니다. 단, 사용자가 요청에서 명시적으로 커밋까지 지시한 경우는 예외입니다.
커밋 메시지 정책
형식:
<type>: <Korean summary> - #<issue-number>
허용 type:
feat
fix
refactor
docs
test
chore
규칙:
- summary는 간결한 한국어로 작성합니다.
- 사용자가 명시적으로 요청하지 않으면 commit body를 추가하지 않습니다.
- footer, co-author metadata, tool attribution, generation/source marker를 추가하지 않습니다.
- issue number를 invent하지 않습니다.
- 현재 branch name에서 numeric issue suffix를 추출합니다.
- 예:
feat/#302/TWI-86 → commit suffix는 #302
TWI-86 같은 Linear issue key는 workflow/integration 용도로 존재할 수 있지만 commit suffix를 대체하지 않습니다.
- 여러 issue-like identifier가 있으면 numeric
#<number> segment를 우선합니다.
- numeric issue number가 없으면 커밋 전에 사용자에게 issue number를 요청합니다.
- 여러 unrelated changes가 있으면 commit split을 권장합니다.
Type 선택 기준:
feat: 사용자에게 보이는 새 기능
fix: 버그 수정
refactor: 동작 보존 구조 변경
docs: 문서만 변경
test: 테스트만 변경
chore: 유지보수/config/tooling 변경
Phase 1 — Scope and branch status
AGENTS.md를 읽습니다.
- 현재 branch name을 확인합니다.
git status --short로 상태를 확인합니다.
- changed files와 diff summary를 확인합니다.
- staged / unstaged / mixed 상태를 구분합니다.
- 다음 정보를 바탕으로 의도된 PR/change scope를 추론합니다.
- branch name
- changed files
- diff summary
- 필요한 경우 existing commit messages
- diff가 하나의 coherent PR scope인지 점검합니다.
- 여러 unrelated scope가 있으면 split commit 또는 split PR을 권장합니다.
- branch name에서 numeric issue suffix를 추출합니다.
- 예:
feat/#302/TWI-86이면 #302를 commit issue suffix로 사용합니다.
TWI-86 같은 Linear key는 workflow/integration metadata로 취급하며 commit suffix로 사용하지 않습니다.
- 다음 경우 중단하고 사용자에게 확인합니다.
- 관련 없거나 위험한 파일이 있음
- numeric issue number를 찾을 수 없음
- branch naming이 모호함
- staged/unstaged 변경이 여러 commit scope를 암시함
Phase 2 — Final review
review-twix 기준을 적용합니다.
- 사용자가 더 넓은 리뷰를 요청하지 않는 한 changed files / diff만 리뷰합니다.
- 다음 리스크를 확인합니다.
- architecture fit
- TCA / MFA boundaries
- Interface/Sources split
- navigation pattern
- network/client rules
- TokenManager / TokenStorage rules
- dependency direction
- public API growth
- docs impact
- unexpected generated / secrets / env files
- blocking / non-blocking issue를 구분해 보고합니다.
- 명시 요청 없이는 수정하지 않습니다.
Phase 3 — Verification
- 우선
bundle exec fastlane ios ci_pr를 실행합니다.
- Bundler를 사용할 수 없는 경우
fastlane ios ci_pr를 실행합니다.
- pass/fail을 보고합니다.
- 실행할 수 없으면 정확한 한계를 보고합니다.
- undocumented
xcodebuild 명령으로 대체하지 않습니다.
Phase 3B — Verification failure analysis
검증이 실패하면 자동으로 커밋 단계로 진행하지 않습니다.
- failure output을 분석합니다.
- 실패 유형을 분류합니다.
- compile
- lint
- test
- dependency
- signing/provisioning
- script/tooling
- unknown
- 관련 가능성이 높은 파일 또는 모듈을 식별합니다.
- 원인을 다음 중 하나로 구분합니다.
- current diff caused
- environment/tooling
- pre-existing failure
- unknown
- 최소 다음 조치를 제안합니다.
- 명시 요청 없이는 파일을 수정하지 않습니다.
- 실패한 검증을 숨기지 않습니다.
- 적절한 경우 retry command를 포함합니다.
Phase 4 — Commit preparation
- 다음을 확인합니다.
git status --short
git diff --stat
- staged file이 있으면
git diff --cached --stat
- 이미 staged files가 있으면 사용자의 staging 의도를 보존합니다.
- 파일을 blind stage하지 않습니다.
- 커밋 대상 파일을 요약합니다.
- 관련 없는 파일을 확인합니다.
- secrets, env files, credentials, 예상하지 못한 generated files를 확인합니다.
- 다음 형식으로 커밋 메시지를 제안합니다.
<type>: <Korean summary> - #<issue-number>
- 필요 시 split commit을 권장합니다.
- 이미 명시적으로 커밋 권한을 받은 경우가 아니면 커밋 전 승인을 요청합니다.
Phase 5 — Commit
- 승인된 파일만 stage합니다.
- 승인된 메시지로 commit합니다.
- 명시 요청이 없으면 commit body를 추가하지 않습니다.
- footer, 외부 authorship, tool metadata를 추가하지 않습니다.
- amend, rebase, reset, stash, force push, push, PR open은 명시 요청 없이는 수행하지 않습니다.
- 커밋 후 다음을 보고합니다.
- commit hash
- committed files
- verification status
- remaining uncommitted files
Phase 6 — PR draft
PR 제목과 설명 초안을 생성합니다. PR을 열거나 push하지 않습니다.
PR 초안은 다음을 바탕으로 작성합니다.
- branch name
- committed 또는 pending diff
- review result
- verification result
- known risks
PR 제목:
- 저장소 convention이 명확히 영어를 요구하지 않는 한 간결한 한국어로 작성합니다.
PR 설명에는 다음을 포함합니다.
- 요약
- 변경 사항
- 검증 결과
- 리뷰 포인트
- 리스크 / 후속 작업
- 관련 이슈
관련 이슈:
- numeric issue suffix가 있으면
#302처럼 사용합니다.
TWI-86 같은 Linear key는 branch/workflow 맥락상 유용할 때만 언급하며 numeric issue reference를 대체하지 않습니다.
최종 보고 형식
한국어로 작성합니다.
변경 범위:
-
브랜치 / 이슈 번호:
-
Scope 점검 결과:
-
최종 리뷰 결과:
-
검증 결과:
-
검증 실패 분석:
-
커밋 대상 파일:
-
제안 커밋 메시지:
-
커밋 여부:
-
PR 제목 초안:
-
PR 설명 초안:
- 요약:
- 변경 사항:
- 검증 결과:
- 리뷰 포인트:
- 리스크 / 후속 작업:
- 관련 이슈:
남은 리스크:
-
다음 PR 전 확인 사항:
-