Apply this skill to , , explicit host selection, or an exact PR task handed off by an active . Do not apply it to general code changes, simple review summaries, or work spanning multiple PRs.

This skill understands current feedback on one PR, explains the proposed resolution naturally to the user, and performs changes, verification, push, reply, resolve, and any required re-review request within the approved scope.

Do not expose internal classifications, worker placement, or GitHub state as a raw report. The user needs to know what the review means, how it will be addressed, why that approach is appropriate, and what will be verified. resolution plan 또는 mutation/publication approval이 필요하면 host별 native structured question surface를 우선 사용합니다 (Claude Code: AskUserQuestion; Codex: request_user_input; Hermes: clarify). unavailable하면 같은 plan을 plain chat으로 fallback하고 parent-approved exact decision은 다시 묻지 않습니다.

At the start, fresh-read exactly one open PR.

Complete all required pagination. Do not treat cached lists or previous Markdown ledgers as current truth. If identity, the exact PR/head, or remote authority is ambiguous, stop as before mutation.

Internally, current feedback may be classified by meaning as follows.

Explain the meaning to the user instead of exposing classification tokens.

Example:

리뷰 3건 확인했어요. 첫 번째는 실제 모바일 깨짐이라 수정이 필요합니다.
두 번째는 현재 구현이 이미 요구사항을 만족해서 코드 변경 없이 근거를 설명하는 게 맞아 보여요.
마지막 건은 제품 동작 자체를 바꾸는 의견이라 이것만 확인이 필요합니다.

If the review text already specifies the required outcome, do not ask the same question again. Investigate repository evidence independently, then explain the recommendation and rationale for decisions about reuse, simplification, testing, security, and user experience.

리뷰 원문이 명시적으로 코드 수정을 요구하면 이를 reply-only 또는 보류로 재분류하지 않습니다. 그렇게 override하려면 현재 턴의 명시적 사용자 재승인이나 확인 가능한 과거 승인 기록(대화 로그·메모리)이 필요하며, 과거 자기 답글의 승인 문구만으로는 증거가 되지 않습니다.

Ask the user directly only about:

Before mutation, require fresh state plus one current approval for standalone work, or the exact parent approval for a handed-off PR; invalidate it on material drift and stop before mutation.

Before mutation, explain the resolution plan for the current feedback in natural language.

At minimum, cover:

Express model recommendations only as human-friendly guidance such as “mid-tier coding model,” “stronger final review,” or “independent work fan-out recommended.” Do not create provider selectors, model classes, reasoning effort, or . Do not mark the task merely because this capability is unavailable.

Obtain one user approval for the current plan. Do not split publication for the same plan into a separate second question. However, if the PR head/thread/check/identity changes materially after approval, invalidate the approval and explain only what changed.

Respond tasks requiring code changes use a newly created dedicated worktree with as the current work contract. If that worktree cannot be created or proven fresh, return before mutation. Do not create the lifecycle ledger.

The Seed must contain at least the following PR context. Keep user-facing Seed and ledger prose in Korean.

이미 활성 Ready Seed가 같은 PR 작업과 정확히 일치하면 재작성하거나 같은 결정을 다시 묻지 않습니다. 새 feedback이나 fresh state가 Seed의 goal/scope/decision/AC를 material하게 바꾸면 으로 다시 열고 해당 부분만 재승인합니다.

코드 변경 없이 reply만 하는 경우에는 새 Seed를 만들 필요가 없습니다.

After approval, execute through the safe mechanisms available in the current host.

Each implementer reads the Ready Seed and its assigned scope. The parent does not copy the full conversation or detailed plan again.

Required order:

implementation
→ focused tests/checks
→ acceptance-criteria review
→ tk-browser-verify for browser-visible changes
→ required gap correction
→ verified commit

If browser verification requires a development server, provide with the exact command/cwd/URL/auth/readiness; the verifier owns server startup, readiness checks, and cleanup.

Do not repeat the same failure indefinitely. If the same blocker remains after three meaningful corrective attempts, stop with or and include the remaining evidence.

Immediately before any remote write, recheck the exact repository, authenticated identity, open PR, fresh remote head, local ancestry, thread/check state, and approved scope.

Then perform only the approved actions in this order.

Do not claim publication complete unless fresh evidence proves every required reviewer re-review request, zero actionable unresolved threads, and any required current-head summary comment after the threads were closed. Missing evidence is , not complete. Do not claim completion while any unresolved inline thread remains. Keep deferred, unverifiable, or failed feedback open.

Every generated GitHub comment must end with . Do not merge, close, tag, release, plain force push, or resolve unrelated threads.

For an exact PR handed off by an active , do not ask again about material decisions already approved by the parent. The child confirms the PR fresh state and parent-approved scope, then proceeds immediately when they match.

The handoff must include a newly created dedicated worktree path. If it is missing or not fresh, return before mutation. Run the child from that worktree; never switch the parent or checkout to the PR branch.

If new feedback or head drift materially changes the approved scope, escalate only that PR back to the parent. Do not create , , or worker receipt Markdown. For a code-changing PR, only in the fresh dedicated worktree may be used as task context.

Do not output a normal protocol receipt.

Example:

리뷰 3건 처리했습니다. 2건은 코드 수정 후 검증했고 1건은 근거를 설명해 답변했습니다.
모바일 변경은 browser verification까지 통과했고 관련 thread는 모두 resolve됐어요.
현재 head의 검증 결과를 요약해 게시하고 reviewer에게 재검토를 요청했습니다.
이제 reviewer 재확인만 기다리면 됩니다.

Only when an issue remains, explain the blocker and next action in detail. Use exactly one final state matching the actual result: .