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

codex-pr-body

Update pull request titles and descriptions to explain why a change matters and what it changes. Preserve existing images and important details, summarize relevant verification, and describe the correct scope for linked, dependent pull requests.

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

원문원문 설명 보기

Update the title and body of one or more pull requests.

설치 방법 보기

이럴 때 유용합니다

  • Rewrite a pull request description before review
  • Add the motivation discussed during development
  • Remove descriptions of changes that were later undone
  • Describe each dependent pull request within its own scope

포함된 파일(1)

  • SKILL.md4.3 KB

SKILL.md(원문)

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

Determining the PR(s)

When this skill is invoked, the PR(s) to update may be specified explicitly, but in the common case, the PR(s) to update will be inferred from the branch / commit that the user is currently working on. For ordinary Git usage (i.e., not Sapling as discussed below), you may have to use a combination of git branch and gh pr view <branch> --repo openai/codex --json number --jq '.number' to determine the PR associated with the current branch / commit.

PR Body Contents

When invoked, use gh to edit the pull request body and title to reflect the contents of the specified PR. Make sure to check the existing pull request body to see if there is key information that should be preserved. For example, NEVER remove an image in the existing pull request body, as the author may have no way to recover it if you remove it.

It is critically important to explain why the change is being made. If the current conversation in which this skill is invoked has discussed the motivation, be sure to capture this in the pull request body.

The body should also explain what changed, but this should appear after the why.

Limit discussion to the net change of the commit. It is generally frowned upon to discuss changes that were attempted but later undone in the course of the development of the pull request. When rewriting the pull request body, you may need to eliminate details such as these when they are no longer appropriate / of interest to future readers.

Avoid references to absolute paths on my local disk. When talking about a path that is within the repository, simply use the repo-relative path.

Avoid references to confidential information including but not limited to codenames or OpenAI-internal URLs.

It is generally helpful to discuss how the change was verified. That said, it is unnecessary to mention things that CI checks automatically, e.g., do not include "ran just fmt" as part of the test plan. Though identifying the new tests that were purposely introduced to verify the new behavior introduced by the pull request is often appropriate.

Make use of Markdown to format the pull request professionally. Ensure "code things" appear in single backticks when referenced inline. Fenced code blocks are useful when referencing code or showing a shell transcript. Also, make use of GitHub permalinks when citing existing pieces of code that are relevant to the change.

Make sure to reference any relevant pull requests or issues, though there should be no need to reference the pull request in its own PR body.

If there is documentation that should be updated on https://developers.openai.com/codex as a result of this change, please note that in a separate section near the end of the pull request. Omit this section if there is no documentation that needs to be updated.

Working with Stacks

Sometimes a pull request is composed of a stack of commits that build on one another. In these cases, the PR body should reflect the net change introduced by the stack as a whole, rather than the individual commits that make up the stack.

Similarly, sometimes a user may be using a tool like Sapling to leverage stacked pull requests, in which case the base of the PR may be the a branch that is the head of another PR in the stack rather than main. In this case, be sure to discuss only the net change between the base and head of the PR that is being opened against that stacked base, rather than the changes relative to main.

Sapling

If .git/sl/store is present, then this Git repository is governed by Sapling SCM (https://sapling-scm.com).

In Sapling, run the following to see if there is a GitHub pull request associated with the current revision:

sl log --template '{github_pull_request_url}' -r .

Alternatively, you can run sl sl to see the current development branch and whether there is a GitHub pull request associated with the current commit. For example, if the output were:

  @  cb032b31cf  72 minutes ago  mbolin  #11412
╭─╯  tui: show non-file layer content in /debug-config
│
o  fdd0cd1de9  Today at 20:09  origin/main
│
~
  • @ indicates the current commit is cb032b31cf
  • it is a development branch containing a single commit branched off of origin/main
  • it is associated with GitHub pull request #11412

리뷰

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

댓글

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

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

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

0 / 1,000자

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

같은 저장소의 스킬

Monitor a GitHub pull request for review feedback, automated check failures, and merge readiness. Diagnose failures, fix problems caused by the branch, and retry likely temporary failures while continuing to watch for updates.

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

  • Monitor automated checks after opening a pull request
  • Address actionable review feedback
  • Distinguish code failures from temporary service problems
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

Review external integration points for breaking changes that could disrupt existing use. Examine app-server APIs, command-line parameters, configuration loading, and session resumption from saved records, continuing beyond the first issue to cover possible failure paths.

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

  • Check app-server API compatibility
  • Review changes to command-line parameters
  • Check compatibility of configuration loading
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

Run a final pull request review using separate agents for each available review skill. Collect all reported issues into a numbered Markdown list, with a specific file path and line number for every finding.

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

  • Run a final review of a pull request
  • Combine findings from multiple review skills
  • Locate issues by file path and line number
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

Assess whether a code change is small enough to review using line-count guidance. For larger changes, examine the actual differences, dependencies, and calling code to suggest reviewable stages and the smallest coherent first step.

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

  • Check the size of a change before requesting review
  • Assess the scope of a complex logic change
  • Plan reviewable stages for a large change
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

Review code that manages the conversation history and extra information sent to Codex models. Apply rules for incremental history, size limits, cache stability, manual review of large additions, and required implementation structures.

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

  • Review changes to conversation history handling
  • Check size limits on information sent to the model
  • Identify large additions requiring manual review
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

Plan and write tests for changes to agent behavior, favoring integration tests that check components together. Identify key logic changes and user-visible behavior to cover, reuse existing helpers, and keep unit tests in dedicated files.

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

  • Identify test coverage for changes to agent logic
  • Add integration tests for user-visible behavior
  • Organize unit tests in dedicated files
openinterpreter/openinterpreter6.9만2026년 10월 11일 업데이트

openinterpreter의 스킬 모두 보기

이 스킬의 문제 신고