codex-pr-body

作者: openai

更新一個或多個拉取請求的標題與內容。

npx skills add https://github.com/openai/codex --skill codex-pr-body

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

來自 openai 的更多技能

user-context
openai
載入或管理資料分析插件的持久性來源路由偏好設定、入門邏輯、設定進度以及語義層註冊表。
official
notion-research-documentation
openai
研究Notion內容,並將其整合為結構化的簡報、報告或附有引用的比較分析。透過精準查詢搜尋並擷取Notion頁面,然後按主題組織發現,並附上內文來源引用及參考文獻章節。根據範圍與使用者目標,從四種輸出格式(快速簡報、研究摘要、比較分析、綜合報告)中選擇。使用內建範本建立與更新Notion頁面;直接連結來源,並在新資訊到來時追蹤變更。
official
rcsb-pdb-skill
openai
提交精簡的RCSB PDB請求以獲取核心元數據、Search API查詢及FASTA下載。當用戶需要簡潔的RCSB摘要時使用;保存原始JSON或…
official
pdf
openai
PDF 讀取、建立與驗證,支援視覺化渲染與程式化生成。使用 Poppler(pdftoppm)將 PDF 頁面渲染為 PNG,以便在交付前檢查版面、間距與排版。透過 reportlab 程式化生成 PDF,確保格式可靠;使用 pdfplumber 或 pypdf 提取文字與元資料。執行品質標準:無文字裁切、元素重疊、表格破損或渲染瑕疵;僅使用 ASCII 連字號,引用格式需具可讀性。使用...
official
test-coverage-improver
openai
Improve test coverage in the OpenAI Agents JS monorepo: run `pnpm test:coverage`, inspect coverage artifacts, identify low-coverage files and branches, propose…
official
playwright
openai
終端驅動的瀏覽器自動化,具備元素快照與互動式UI工作流程。透過playwright-cli包裝腳本運作(需npx),支援無頭模式與有頭模式以進行視覺化除錯。核心流程:開啟頁面、擷取快照以取得穩定元素參照、使用參照進行互動、在導航或DOM變更後重新擷取快照。包含表單填寫、點擊、輸入、多分頁管理、螢幕截圖/PDF擷取,以及流程除錯的軌跡記錄。元素參照(例如e3、e15)...
official
ukb-topmed-phewas-skill
openai
接受rsID、GRCh37或GRCh38輸入,解析為所需的GRCh38查詢,以獲取單一變異的簡潔UKB-TOPMed PheWAS摘要。當需要…時使用。
official
code-review-context
openai
模型可見上下文
official