agentleFS
MTGVimMTGVim/tiger-kit/skills/tk-pr-open/SKILL.md

tk-pr-open

Skill1 starsChanged 4 days agoMITView on GitHub

[user/auto] 검증된 현재 브랜치 `commit`을 하나의 GitHub `pull request` 또는 필요한 경우 reviewable `stacked PR`로 준비·발행하며, 원격 발행은 정확한 작업 범위·대상에 대한 명시적 승인을 확인합니다.

The file

Files
SKILL.md

<a id="open-pr-publication"></a>

PR 발행

<a id="shared-references"></a>

공통 참조

현재 설치된 담당 스킬에서 해당 분기의 조건에 따라 기준을 읽습니다. 소유자나 자원이 없거나 일치하지 않으면 해당 작업을 중단합니다. 기억, 다른 설치본이나 승인되지 않은 설치 대신 tk-setup-skills를 사용합니다. 참조 읽기는 워크플로 실행이나 변경 권한을 부여하지 않습니다.

  • 사용자 소유 결정·누락된 승인·미충족 선행 조건을 질문이나 질문 도구 입력으로 제시하기 직전에 질문 라운드를 이번 작업에서 읽었는지 확인하고 누락했으면 먼저 읽습니다. 독립적인 결정과 승인은 각각 별도 질문으로 두며, 승인 선택지를 결정 질문에 섞지 않습니다.
  • 사용자에게 완료 보고, 산출물 경로 인계나 여러 속성을 비교하는 대화 응답을 전달하기 전에 대화 전달을 읽습니다. 작업별 구체적인 출력 계약이 우선합니다.

<a id="ui-evidence"></a>

UI 근거

기존 UI 문구는 언어·대소문자·문장부호·공백을 보존하고 제안 문구와 구분합니다. 근거 없는 탐색 경로를 안내하지 않습니다. UI 문구·경로를 인용·검증·전달할 때 UI 근거를 읽고, 대상에 맞는 근거와 충돌·미확인 사항을 보존합니다. 전달만 하는 분기는 새 조사를 시작하지 않으며, 수집은 담당자의 기존 조사 권한 안에서만 수행합니다. UI와 무관하면 이 참조를 읽지 않습니다.

<a id="approval-continuity"></a>

승인 연속성

같은 작업에 대한 유효한 승인을 턴과 자식 단계(baseline/after 포함) 전반에 재사용하고, 기존 담당자를 통해 승인된 작업만 계속합니다. 자식·baseline 근거를 반환하고 승인된 담당 작업을 재개합니다. 단계 상태는 완료를 뜻하지 않습니다. 새로운 중대한 결정, 범위·권한 변경이나 사용자만 제공할 수 있는 입력이 누락된 경우에만 질문합니다. 호출과 복구된 산출물은 권한을 부여하지 않습니다. 원격 작업과 파괴적 작업에는 행동·대상에 대한 명시적 승인이 필요하며, 로컬 승인에서 추론하지 않습니다.

/tk-pr-open, $tk-pr-open, 호스트 스킬 선택기를 통한 선택, 현재 브랜치로 PR 열어줘 또는 이미 구현된 현재 브랜치를 리뷰 가능한 stacked PR로 나누라는 요청처럼 PR 발행을 생성하거나 업데이트하려는 의도가 명시적일 때 시작합니다.

입력은 이미 구현·검증된 현재 브랜치의 commit 또는 같은 세션에서 구현·검증을 마친 관련 미커밋 변경과 현재 상호작용에서 제공된 발행 입력입니다. 미커밋 변경은 아래의 승인된 로컬 커밋 분기를 먼저 완료하여 실제 head/tree로 고정합니다. 검토 대상 head/tree와 검토 범위·예외, 적용되는 리뷰 요구도 이 입력으로 받으며, 아래의 발행 대상 대조에만 사용합니다. .tigerkit/seed.md를 읽거나, 별도 리뷰 상태나 구현 회고를 찾아보거나, tk-prep이나 tk-review를 호출하거나, 수정 작업으로 연결하지 않습니다. 발행은 구현 리뷰가 수렴했는지 결정하지 않습니다.

구현을 반복하거나 worker를 만들거나 새 제품 변경을 추가하지 않습니다. 승인된 로컬 커밋은 기존 검증 내용을 기록하는 행동만 허용하며 구현·검증을 대신하지 않습니다. 승인된 구현 후 스택 분할에서는 이미 검증된 제품 트리를 정확히 재구성하는 발행 전용 브랜치와 커밋을 만들 수 있습니다. 해당 커밋은 제품 동작을 추가·누락·복구해서는 안 됩니다.

<a id="current-state"></a>

현재 상태

먼저 다음을 확인합니다.

  • 저장소와 인증된 GitHub 계정을 확인합니다.
  • 현재 브랜치와 HEAD를 확인합니다.
  • base 브랜치를 확인합니다.
  • 대상 commit, 트리, 커밋 범위와 변경된 경로를 확인합니다.
  • 같은 head의 PR이 이미 있는지와 그 observed draft | ready 상태를 확인합니다.
  • 무관한 dirty·staged 경로를 확인합니다.
  • 관련 미커밋 변경이 있으면 정확한 전체 경로·diff와 검증 범위, 기존 로컬 커밋 승인 여부를 확인합니다.
  • 대상 저장소의 PR template을 확인합니다.
  • 현재 규범적인 제목 지침을 확인합니다. 지침이 없을 때만 관례를 파악하기에 충분한 수의 최근 merge PR 제목을 확인합니다.

정확한 현재 commit을 입증할 수 없거나 무관한 변경이 섞였다면 범위를 넓히지 말고 Blocked/Unverifiable을 반환합니다. 현재 HEAD는 입증되지만 같은 세션에서 검증한 관련 변경만 미커밋 상태이면 발행 전 로컬 커밋을 읽고 그 행동을 승인 자료에 넣습니다. 필요한 로컬 승인과 커밋 후 검증을 마친 뒤에만 아래 사전 점검과 최종 원격 발행 자료를 준비합니다. 검증되지 않았거나 작업 소유권이 불명확한 변경은 구현 담당자에게 반환하며, 무관한 dirty·staged 변경을 정리하거나 함께 커밋하지 않습니다.

<a id="reviewability-preflight"></a>

리뷰 가능성 사전 점검

단일 PR을 선택하기 전에 base...HEAD를 살펴보고 발행 형태를 선택합니다.

single | stacked

엄격한 LOC 기준을 사용하지 않습니다. 큰 diff는 신호일 뿐입니다. 이미 검증된 브랜치에 하나의 일관된 선형 의존 관계를 이루는 독립적으로 리뷰 가능한 관심사가 둘 이상 있다면 stacked를 우선합니다. 특히 관심사마다 리뷰어 집단이 다르거나 기반 → 구현 → 통합 경계가 분명한 경우에 해당합니다.

인계에 여러 PR 그룹이 이미 계획되어 있다면 발행 형태를 선택하기 전에 다중 PR 전달의 안전을 읽습니다. 해당 그룹 구성과 중간 상태 안전 검사를 보존합니다. 대응 관계가 없거나 바뀌었다고 새 분할을 만들거나 하나로 합친 PR을 발행할 권한이 생기는 것은 아닙니다.

생성 출력, lockfile, 스냅샷, vendoring된 산출물이나 기계적 대량 변경만으로 스택이 정당화되지는 않습니다. 원시 diff가 크더라도 일관된 변경 하나는 single로 유지합니다.

구현 후 분할은 같은 head의 PR이 생기기 전 새 발행에만 적격입니다. 리뷰 댓글이나 원격 상태가 있는 기존 PR을 알리지 않고 대체하거나 재구성하지 않습니다. 스택이 타당한 후보이거나 사용자가 명시적으로 요청했다면 발행 계획을 준비하기 전에 구현 후 스택 분할을 읽습니다.

한 번의 호출은 하나의 일관된 발행 이야기를 담당합니다. PR 하나 또는 선형 스택 하나입니다. 무관한 작업에 별도 스택이나 독립 PR이 필요하다면 그 범위 확대를 하나의 발행 안에 숨기지 말고 중단합니다.

저장소 동작이나 도메인 의미를 해석하기 전에 관련된 저장소 소유 도메인 맥락이 있다면 읽습니다.

<a id="pr-title-and-body"></a>

PR 제목과 본문

PR 제목·본문을 작성하거나 업데이트하기 전에 PR 본문 준비를 읽습니다. 적용되는 기본 브랜치 템플릿과 규범적인 제목 지침을 보존하고, 현재 리뷰 가능한 관심사를 설명하며, 검증된 UI와 위험·복구 근거를 대조하여 반영합니다. 필요한 근거가 해결되지 않았다면 발행을 중단합니다. 발행만 담당하는 이 단계는 새 제품 조사나 변경 권한을 부여하지 않습니다.

<a id="evidence"></a>

근거

현재 발행 입력에 근거 manifest, 이미지·GIF·MP4 또는 미디어 요구가 있으면 승인 자료를 준비하기 전에 PR 미디어 근거를 읽습니다. 해당 입력·요구가 모두 없으면 N/A로 두며 manifest를 만들지 않습니다. undecided를 원격 쓰기 전에 해소하고, 필수 근거가 누락·미검사·불완전하거나 Pass가 아니면 발행을 중단합니다. 실제 비밀이나 검증되지 않은 캡처는 업로드하지 않습니다. 생성 동의는 업로드 승인이 아니며, 선택·검사한 정확한 미디어만 담당 PR이 존재한 뒤 tk-pr-media로 전달합니다.

<a id="publication-approval-packet"></a>

발행 승인 자료

발행 점검 지점 전에 승인 자료를 읽습니다. 정확한 저장소, single/stacked 형태, 원격 행동별 대상·승인, draft/ready 상태, base/head/tree, 검토 대상, refspec, 제목·본문, 템플릿 체크 상태, 근거와 제외 사항을 연결합니다. 최종 확인 전에 해당 참조의 검토 대상 대조를 완료하고 구체적으로 렌더링된 미리보기를 보여주며 전체 자료를 유지합니다. .tigerkit/pr-open.md는 해당 참조의 저장 조건을 충족할 때만 사용합니다. 새 PR은 ready가 기본값이며, 변경 요청이 없으면 기존 PR 상태를 보존합니다.

<a id="-checkpoint---stop--publication-boundary"></a>

🔴 점검 지점 · 🛑 중단 · 발행 경계

스택 재구성이나 원격 쓰기 전에 활성 자료와 필수 산출물을 다시 읽습니다. 먼저 미결 선택을 해결한 뒤, 확정된 자료에 대한 최종 발행 확인을 한 번 받습니다. 같은 정확한 자료와 원격 행동별 대상·범위를 이미 명시적으로 승인받았다면 재사용하며 반복하지 않습니다. 단순한 단일 PR 발행 요청은 준비 의도를 확정하지만, 아직 제시하지 않은 최종 자료 내용까지 승인한 것으로 취급하지 않습니다. 스택 재구성에는 정확한 계층 계획도 필요합니다. 단일 PR 요청에서 추론하지 않습니다.

해결되지 않은 undecided 근거 상태는 중대한 모호함입니다. 직접적인 단일 PR 요청이라도 이 점검 지점에서 질문합니다. 기존 결정과 승인 범위는 보존하되, 근거 선택의 답변만으로 발행하지 않습니다.

미결 답변을 반영한 뒤 첫 원격 쓰기 전에 바뀐 항목과 최종 원격 행동·체크 상태·검토 대상·제외 사항을 다시 보여주고 명시적 발행 확인을 받습니다. 전체 자료를 반복할 필요는 없지만 사용자가 현재 자료를 확인할 수 있어야 합니다. 결정 답변으로 자료가 바뀌면 그 답변과 최종 승인을 같은 것으로 취급하지 않습니다. 최종 확인 뒤 자료가 다시 바뀌면 영향받은 항목을 갱신하여 확인받습니다. 질문은 공통 질문 계약에 따라 결정과 승인을 구분합니다. 미리보기는 대화에 렌더링하고, 최종 발행 확인 질문은 질문 라운드의 도구 우선순위에 따라 현재 확인·승인 용도로 허용된 네이티브 질문 도구로 보냅니다. 질문이 하나여도 같습니다. 미리보기가 채팅에 있다는 사실은 채팅 대체 형식을 선택할 이유가 아니며, 도구가 없거나 현재 용도로 허용되지 않을 때만 공통 계약의 승인 경로·채팅 대체 형식을 사용합니다.

stacked에서는 같은 승인이 승인된 계층 계획의 정확한 로컬 발행 이력 재구성만 추가로 허용합니다. 제품 수정, 소스 브랜치 재작성, 추가 계층이나 무관한 브랜치 정리는 허용하지 않습니다. 계획, 승인된 commit, 템플릿·근거 상태, 스택 도구 출처나 현재 저장소 상태를 재검증할 수 없으면 중단합니다.

<a id="publication"></a>

발행

승인 후 저장소, 계정, 소스 브랜치, HEAD, base, 기존 PR, 템플릿 출처와 스택 브랜치 이름 충돌 여부를 다시 확인합니다. 승인 자료의 검토 대상 대조에 따라 현재 head/tree와 diff 기준을 다시 읽고 승인한 비교 결과가 여전히 유효한지 확인합니다. 최종 승인한 후보에서 추가 변경이 생겼거나 승인한 비교 결과를 입증할 근거가 없으면 원격 쓰기를 보류하고 해당 선택·확인 단계로 돌아갑니다. 테스트·정적 검사를 필수 독립 리뷰 대신 사용하지 않습니다. 기존 PR의 actual state가 승인된 plan과 중대하게 다르면 승인을 무효화합니다. 중대한 drift가 있으면 승인을 무효화합니다.

원격 상태 변경(push, PR 생성·업데이트, gh pr ready, gh pr edit)은 로컬 정리와 별도의 도구 호출에서 실행합니다. 정리 거부가 발행 결과를 차단하거나 가리지 않도록 원격 결과를 독립적으로 기록하고 재확인합니다. PR 외 원격 행동은 PR 승인에서 추론하지 않습니다. 연결된 티켓의 상태 전이 선택지·추천과 조회 불가 시의 생략은 승인 자료의 부가 원격 행동을 따릅니다. 사용자가 선택하여 승인 자료에 포함하고 명시적으로 승인한 행동만 PR 발행 성공을 검증한 뒤 수행합니다. draft PR의 전이도 같은 선택지와 승인 절차를 따릅니다. 승인 없이는 어느 상태의 PR에서도 전이를 실행하지 않습니다.

single에서는 정확히 승인된 refspec만 push하고 지정된 PR만 생성하거나 업데이트합니다. create에서는 승인된 PR state를 적용하고, update에서는 명시적으로 승인된 경우에만 상태를 바꿉니다.

stacked에서는 구현 후 스택 분할을 따릅니다. 소스 브랜치를 보존하고 그 옆에 승인된 계층만 재구성하며, 모든 계층과 최종 트리 불변 조건을 검증한 뒤 검증된 github/gh-stack으로 정확한 사슬을 제출합니다. 새로 생성한 모든 계층에 승인된 상태를 사용하고, 제출 후 자동 생성된 PR 메타데이터를 정확히 승인된 제목·본문으로 수정합니다.

merge, close, tag, release를 수행하거나 보존된 소스 브랜치를 삭제하거나 무관한 ref를 정리하지 않습니다.

발행을 생성하거나 업데이트한 뒤 원격 상태를 다시 읽습니다. single에서는 URL, head SHA, 실제 draft | ready 상태, 템플릿 준수와 근거 상태를 검증합니다. stacked에서는 기계 판독 스택 상태를 사용하고 모든 PR의 URL, head/base 관계, 상태, 정확한 제목·본문, 템플릿 준수와 근거 상태를 다시 읽습니다. 근거가 필수이거나 업로드를 명시적으로 선택했다면 담당 PR이 존재한 뒤 이미지 업로더를 사용합니다. PR이 하나라도 생성되었지만 필수 메타데이터·근거나 선택된 이미지 발행이 실패했다면 실제 원격 상태를 보존하고 부분 발행을 숨기지 말고 완료 상태를 Blocked로 보고합니다. 승인된 트래커 전이가 실패하거나 차단되면 성공한 PR과 실패한 부가 행동을 나누어 보고하고, PR을 자동으로 되돌리거나 다른 전이를 시도하지 않습니다.

<a id="completion"></a>

완료

사용자에게 중요한 결과만 보여줍니다.

  • PR URL이나 하위→상위 스택 PR URL을 보여줍니다.
  • 발행을 생성했는지 업데이트했는지 보여줍니다.
  • 현재 소스 head를 보여줍니다. 스택이라면 보존된 소스 브랜치와 스택 tip을 보여줍니다.
  • 현재 PR state를 보여줍니다.
  • 검증·근거 결과를 보여줍니다.
  • 스택이라면 stack-tip 트리가 원본 트리와 같은지 보여줍니다.
  • 남은 차단 요인이나 부분 원격 상태를 보여줍니다.

출처 전체 덤프나 제품 구현 receipt는 보여주지 않습니다.

<a id="artifact-paths"></a>

산출물 경로

승인된 산출물 쓰기, checkout·전송·Git 제외 설정이나 임시 입력 소비 전에 산출물 경로를 읽습니다. 저장소 임시 파일에는 안전하고 소유권이 확인된 심볼릭 링크가 아닌 경로와 입증된 Git 제외를 사용합니다. 검사에 실패하면 해당 파일 분기를 중단합니다. 명시적인 최종 목적지와 담당자별 기본값을 보존합니다. 미리 채워진 입력은 완료된 입력이 아닙니다. 정리는 기록된 리터럴 형태의 해석 완료된 실행 소유 절대 경로만 대상으로 하며, cwd 상대 경로나 glob을 사용하지 않습니다.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.