본문으로 건너뛰기
cccskills
무료GitHub에 공개

modernize

For getting old prs up to date. Use when asked to rebase a pr or "modernize".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack스타 543(GitHub 543 + cccskills 0)

실행 점수 미검증

설치 방법 보기

포함된 파일(2)

  • SKILL.md4.4 KB
  • agents/openai.yaml263 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Modernize

Modernize the idea, not just the branch. A clean rebase does not prove that the PR still belongs in the product.

Guardrails

  • Always check to make sure you have pulled latest origin for your branch, main branch, and any other branch related to your work before starting.
  • Treat existing worktree changes as user-owned. Use a disposable worktree when the active worktree is dirty or is being used for other work.
  • Modernizing authorizes rebasing and updating the PR branch. It does not authorize merging, closing, changing the base branch, or expanding scope.
  • Never use an unqualified force push. Update a rebased branch with --force-with-lease against the head SHA observed before the rebase.
  • Do not post a PR comment unless the user asked for one. Use the leaving-pr-comments skill for every comment posted on the user's behalf.

Establish the PR's intent

Resolve the PR and record its URL, state, base, head repository and branch, current head SHA, author, checks, and review state. Read the title, body, linked issues, commits, review threads, and complete diff. State the smallest coherent goal the PR was trying to accomplish before judging its implementation.

Fetch the latest remote base and PR head. Use the PR's actual base branch, usually main, rather than assuming the local branch is current. Record the merge base so the original PR and subsequent base-branch changes can be compared separately.

Check what changed around it

Inspect commits and diffs added to the base branch since the PR diverged. Search merged and open PRs when titles, code paths, or behavior suggest a replacement or competing implementation.

Look beyond overlapping lines:

  • Has the same user-facing problem already been solved?
  • Did APIs, types, schemas, dependencies, or architectural boundaries change?
  • Do both sides now claim ownership of the same behavior or invariant?
  • Was the code being changed deleted, moved, or intentionally simplified?
  • Would landing the PR restore an old behavior or create two ways to do the same thing?
  • Is the original benefit still large enough to justify the maintenance cost?

Do not describe a PR as current merely because Git reports no conflicts.

Choose a disposition before pushing

Use one of these recommendations:

  • MODERNIZE: the goal is still useful and the implementation remains the right shape. Rebase, resolve conflicts, test, and update the branch.
  • REWORK: the goal is still useful, but a mechanical rebase would preserve the wrong implementation. Explain the smallest credible rewrite and stop before pushing unless the user also asked for that rework.
  • CLOSE: the PR is superseded, obsolete, directionally wrong, or no longer worth its cost. Cite concrete evidence and stop. Do not spend time rebasing an obsolete branch, and do not close it without explicit permission.

Be willing to recommend CLOSE. Age alone is not evidence, and sunk effort is not a reason to keep a PR alive.

Rebase without losing intent

For a MODERNIZE disposition:

  1. Create a safe local branch or disposable worktree at the recorded PR head.
  2. Rebase its commits onto the freshly fetched base branch.
  3. Resolve each conflict according to the PR's current intent and the base branch's newer invariants. If a conflict reveals a product or architecture disagreement, stop and reconsider the disposition instead of guessing.
  4. Compare the pre-rebase and post-rebase commit series with git range-diff and inspect the final diff. Confirm that no intentional behavior disappeared and no already-landed behavior was reintroduced.
  5. Run the repository's focused checks for the touched area. Distinguish real failures from pre-existing or infrastructure failures.
  6. Push with --force-with-lease tied to the previously observed remote head. If the lease fails, fetch and reassess rather than overwriting new work.

Do not merge the PR.

Report

Lead with MODERNIZE, REWORK, or CLOSE and the reason. Then summarize:

  • meaningful changes on the base branch;
  • conceptual conflicts or confirmation that none were found;
  • the rebase and push result, if performed;
  • checks run and their results;
  • the remaining decision or work, with a link to the PR.

Separate observed facts from judgment. Say what could not be verified instead of manufacturing confidence.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Monitor a pull request through review and CI. Use when the user asks to monitor, watch, or babysit a PR.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

council

무료

Trigger this if the user says 'council'.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

file-pr

무료

File a concise pull request. Use when the user asks to file, open, or create a PR.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

full-send

무료

Trigger this if the user says 'full send'.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

full-stop

무료

Trigger this if the user says 'full stop'.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

Use whenever leaving comments on GitHub.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

t3dotgg/tstack5432026년 10월 25일 업데이트

t3dotgg의 스킬 모두 보기

이 스킬의 문제 신고