Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/wade-devcode/awesome-coding-skills-cn/pr-descriptionnpx skills add Wade-DevCode/awesome-coding-skills-cn --skill pr-descriptiongit clone --depth 1 https://github.com/Wade-DevCode/awesome-coding-skills-cnWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00020 | $0.02051 |
| Opus 5 | $0.00010 | $0.01026 |
| Sonnet 5 | $0.00004 | $0.00410 |
| Haiku 4.5 | $0.00002 | $0.00205 |
Grade A, and why
pr-description scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR 描述
何时用
- 创建 Pull Request 之前,需要填写描述。
- 更新已有 PR,需要补充说明测试方法或设计变更。
- 接到 reviewer 反馈"看不懂这个 PR 在做什么"时,说明描述不够。
- AI 辅助完成了实现,需要人工补充上下文和验证步骤。
核心规则
1. 讲清"做了什么、为什么、怎么验证",不让 reviewer 猜
规则： PR 描述必须包含三部分:改了什么(变更摘要)、为什么改(背景/动机)、怎么验证(测试方法)——缺一不可。
为什么： AI 辅助写代码时,描述最常见的问题是只写"做了什么"而完全不写"为什么"和"怎么验证"。reviewer 看到一堆代码改动不知道背景是什么、这个方案是否是最优选择,也不知道怎么本地复现来验证。结果要么盲目通过,要么来回追问浪费时间。典型事故:PR 描述写"修复 bug",reviewer 花 20 分钟读代码才弄清楚是哪个 bug、怎么触发、为什么这样修。
怎么做：
- 用固定结构写描述:背景→改动摘要→验证步骤,三段清晰分隔。
- 背景可以一两句话说清楚:是 issue 触发、是需求变更、还是性能优化?
- 验证步骤要具体到"执行什么命令/点击什么按钮/看到什么输出"。
2. 关联 issue/需求;破坏性变更与迁移步骤显著标注
规则： 关联对应的 issue 编号或需求单;如果有 breaking change,必须在描述顶部显著标注,并附上迁移步骤。
为什么： AI 生成的 PR 里经常找不到任何 issue 关联,也没有 breaking change 警告。前者让项目管理失去可追溯性,半年后不知道某个改动是为了什么;后者让接入方在升级后莫名跑挂,只能自己去 git log 里找原因。破坏性变更不显著标注是最容易被忽视的 PR 问题,影响范围往往远超当前 repo。
怎么做：
- 描述开头加
Closes #123或Related to #456自动关联 issue。 - 有 breaking change 时在描述最顶部加醒目标注:
⚠️ Breaking Change+ 影响范围 + 迁移方法。 - API 签名变更、配置格式变化、依赖版本升级等都算潜在 breaking change,不确定就标注。
3. 给测试计划/验证步骤,reviewer 能复现
规则： 描述中的"测试计划"要具体到可操作的步骤:运行什么命令、访问什么 URL、输入什么数据、期望看到什么结果。
为什么： AI 写的 PR 描述里"测试方法"常是一行:已通过单元测试。reviewer 无法判断:单元测试覆盖了哪些场景?有没有集成测试?手动测了哪些场景?UI 改动有没有截图?结果只能靠"信任 CI 绿了就行"通过 PR,这是生产事故的温床。特别是 UI 改动或涉及第三方服务的改动,仅靠 CI 无法验证。
怎么做：
- 给出本地复现步骤:
1. 拉取分支 2. 执行 XXX 3. 访问 /endpoint 4. 预期返回 200 + {…}。 - UI 改动附截图或录屏(before/after)。
- 说明哪些场景有自动化测试覆盖,哪些靠手动验证。
4. PR 聚焦一件事,过大就拆;说明取舍与已知遗留
规则： 单个 PR 只做一件事;超过 400 行 diff 或涉及多个不相关改动时主动拆分;对无法当前解决的遗留问题,在描述中明确说明。
为什么： AI 辅助开发时容易在一个 PR 里顺手做了重构+功能+修 bug,产生千行 diff。reviewer 面对大 PR 的选择往往是:浅看后盲目通过,或者拖着不审导致 PR 堆积。两者都有风险。同时 AI 有时为了"让代码跑起来"引入了临时方案却不说明,reviewer 不知道这是临时的还是正式的,后续也没人跟进清理。
怎么做：
- 拆分原则:功能改动、重构、修 bug 各一个 PR;相互独立的功能各一个 PR。
- 描述里说明已知的取舍:
当前方案为临时修复,完整方案见 #789。 - 已知 TODO 或已知限制显式列出,加 issue 链接跟踪,不要藏在代码注释里。
5. 自检清单(测试过、文档更新、无残留)随 PR 附上
规则： PR 描述末尾附一个可勾选的自检清单,提交前自己过一遍打勾,让 reviewer 看到你已自查过什么。
为什么： AI 完成实现后很容易忽略收尾工作:console.log 没删、CHANGELOG 没更新、文档没同步。自检清单是一种强制提醒机制——不是给 reviewer 看的形式主义,而是给自己设的最后一道门。有了清单,reviewer 也能快速判断"作者已确认过测试通过",减少重复问题。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 165 lines · 20 tokens per session scan A 6aebd2692b27
pr-description is a skill published in the GitHub repository Wade-DevCode/awesome-coding-skills-cn (6 stars, last pushed 2mo ago), licensed MIT. It adds 20 tokens to every session and 2,051 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
chinese-documentation
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用，不要根据上下文自动触发。.
chinese-git-workflow
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用，不要根据上下文自动触发。.
brainstorming
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。.
chinese-code-review
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。.
chinese-commit-conventions
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。.
mcp-builder
MCP 服务器构建方法论 — 系统化构建生产级 MCP 工具，让 AI 助手连接外部能力.