사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/gjkim42/kanon-repo --skill finish-pr시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Finish PR
Repeat the following loop until a Kelos review approves, then complete that iteration before breaking. An approving verdict must still go through findings, squashing, pushing, and PR updates. Use gh for GitHub operations. This workflow updates the PR; it does not merge it.
Establish the target
Resolve the requested PR, or the current branch's PR when none is specified. Identify its repository, number, base branch, head branch, and head SHA. Work on that head branch and preserve unrelated local changes. Publish any intended pending changes before requesting a review so the reviewer sees them.
Review loop
- Request a review. Record the current remote head SHA, existing review
check IDs, and review comment timestamps. Post exactly /kelos review with gh pr comment <number> --repo <owner/repo> --body '/kelos review'.
- Wait for this review. Discover the Kelos review check created for this
request on the recorded SHA, and poll that check until it completes. Wait for it to appear even if older checks have already passed; do not post duplicate requests while waiting. Keep the user informed during the wait. If the head changes during the review, reconcile it before starting another iteration; that result cannot approve a different head.
- Read and address the findings. Read the fresh Kelos result and all PR
reviews, inline threads, and review comments. Kelos may publish an APPROVE verdict in an updated sticky comment rather than a GitHub APPROVED review. A successful check means the review task completed, not that it approved the PR. Require a result attributable to this request and recorded head. Use address-pr-review to verify findings and fix only those that are valid, current, and required. Check each finding's author, timestamp, head, and thread resolution; explicitly triage findings that do not warrant a change. Run the project's appropriate validation for any fixes.
- Squash and update the PR. Squash the PR branch's commits into one commit
above its merge base with the PR base, including any fixes. If it is already one commit and there are no changes, leave the commit intact. Preserve the complete intended diff and push to the PR's head branch, using an explicit --force-with-lease=<head-ref>:<expected-remote-sha> when rewriting history. If the lease fails, reconcile the remote changes before retrying. Update the PR title and description to describe the final implementation and validation, following the repository's PR template when present.
- Decide whether to repeat. Break only if this iteration's Kelos verdict
approves the recorded review head, steps 3 and 4 are complete, and no valid required findings remain. Break even if addressing findings or squashing in this iteration changed the pushed SHA; do not request another review solely to approve the resulting commit. Otherwise continue the loop.
Stop and report the blocker if the review check fails, is cancelled, cannot run, or completes without a usable verdict, or if repeated iterations cannot make progress on the same unresolved finding. Do not spin on failed tooling or silently treat a blocked review as approval.
On success, report the PR link, final commit, approval result, and validation. If finalization changed the SHA, identify the reviewed commit separately from the final pushed commit.
