菜单
Write or update a GitHub PR description for this repo. Use when the user asks to create, update, or improve a pull request's description/body.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | write-pr-description |
| description | Write or update a GitHub PR description for this repo. Use when the user asks to create, update, or improve a pull request's description/body. |
When updating a PR description, base it on the entire branch, not just the change currently being discussed:
git log <base>..HEAD) and the full diff (git diff <base>...HEAD), not only the latest commit or the current conversation topic.Structure the body with two sections separated by ---:
Label both explicitly even if everything is primary work (still include an "Auxiliary Work" section, e.g. "None").
When asked to just show the description (not post it), output raw markdown in a fenced ```markdown block. When posting/updating it on GitHub, use gh pr edit --body-file on a temp file rather than --body with an inline string, to avoid shell-escaping issues.
Always link the PR to its tracking ticket. Include a closing keyword (Fixes #NNNN, or Refs #NNNN if it shouldn't auto-close the issue) directly in the PR body/title — a closing keyword buried only in a commit message on the branch does not reliably create the tracked link (verify with gh api graphql querying pullRequest.closingIssuesReferences if in doubt). If no ticket exists yet for the work, create one first (see file-github-issue / pickup-github-ticket) rather than opening an unlinked PR.
If gh pr edit --body-file fails with an unrelated GraphQL error (e.g. a "Projects (classic)" deprecation error), the edit did not apply — fall back to gh api repos/<owner>/<repo>/pulls/<number> -X PATCH --input <json-file> with a {"body": "..."} payload, and re-verify the body actually changed.
Address code review comments (e.g. from Copilot's automated PR review) on an open PR, then mark each resolved conversation. Use after a reviewer leaves inline comments and you've fixed and pushed the corresponding changes.
Tick off completed acceptance-criteria checkboxes in a linked issue/ticket or PR body after finishing and pushing the corresponding work. Use right after pushing commits to a PR, before reporting the task as done.
Prepare a versioned release notes document for the Firely CQL SDK. Use when the user asks to write, draft, or cut release notes for a new version.
Create or edit a GitHub issue for this repo. Use when the user asks to file a bug, write up an issue, or edit an existing issue's body.
Regenerate ELM JSON files after adding or changing CQL input files in a test/library-set project (e.g. CoreTests/Input/ELM/HL7). Use when the user adds CQL files and needs the corresponding ELM generated.
Pick up a GitHub issue/ticket by number or URL — find or create its branch and check it out. Use when the user says to pick up, start, or work on a specific ticket/issue number.