菜单
Use when the user wants to write or draft a pull request title and description, summarize a branch's changes for review, or prepare to open a PR.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pr-description |
| description | Use when the user wants to write or draft a pull request title and description, summarize a branch's changes for review, or prepare to open a PR. |
Drafts a PR title and description from the diff against the base branch.
Determine the base branch (usually main or master):
git merge-base --fork-point main HEAD || git merge-base main HEAD
Gather the change summary:
git log main..HEAD --oneline
git diff main...HEAD --stat
Read the full diff (git diff main...HEAD) only for files whose purpose
isn't clear from the stat — don't paste the whole diff into the description.
Draft using this template:
## Summary
- <bullet: what changed and why, not a file-by-file list>
- <bullet: 1-3 max>
## Test plan
- [ ] <how to verify this change — be specific: commands, manual steps>
Title: short imperative, under 70 chars, e.g. Add retry logic to upload client.
Show the draft to the user — don't open the PR yourself unless explicitly asked.
If asked to open it, use gh pr create --title ... --body "$(cat <<'EOF' ... EOF)".
Use when preparing notes for a 1:1 with a report, drafting written feedback, or summarizing a person's recent work/contributions ahead of a conversation or review cycle.
Use when asked to generate or update architecture diagrams or ER (entity-relationship) diagrams from the codebase — the code is the source of truth, not existing docs.
Use when the user asks how to reduce Claude Code costs, manage token usage, choose the right model for a task, or wants a review of whether a session/workflow is running efficiently.
Use when the user asks for a standup update, daily summary, "what did I work on yesterday", or wants to recap recent commits before a team sync.
Use when investigating a bug, test failure, or unexpected behavior and proposing a fix — always runs investigation in Plan Mode so no code changes happen until the root cause and approach are confirmed.
Use when writing or reviewing code that crosses a trust boundary (user input, external APIs, file/network/DB I/O) — guards against invalid input, injection, unsafe failure modes, and missing validation at the edges without over-defending internal code.