用途：为不了解该 issue、diff 或开发讨论的评审者撰写或更新 GitHub PR 描述，先讲清改动为何存在，再说明如何实现。
调用方式：/pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]。PR_NUMBER 为必填的 PR 编号；--fixes 为可选，逗号分隔要关闭的 issue 编号，如 123,456。示例：/pr-description 3534、/pr-description 3534 --fixes 123,456。若用户只要草稿，则只返回文本、不更新 GitHub；否则更新指定 PR 的描述。
主要能力：读取 PR 标题、现有描述、基线分支与头分支，读取 PR 提交与 diff（使用 PR 实际分支，不假设当前检出即 PR 分支或基线为 main），并读取相关 issue、代码注释与可用对话上下文，理解问题与改动原因。从 --fixes 及提交信息中明确的关闭引用收集 issue 编号，不臆测应关闭关联 issue。若现有描述已准确、无需外部上下文即可理解且符合格式，则保持不变；否则围绕最终实现重写，而非追加更新。
写作要求：先确立核心解释——受影响组件做什么、是什么限制或需求促成改动、改动后行为有何不同，只用理解本 PR 所需的上下文，不编造问题。选出评审者需评估的不同关注点，通常为 3 至 6 条带标签的要点，小改动可更少，按行为或系统职责分组，而非按文件、辅助函数或实现步骤。格式为开头段落加带标签要点，不设 Summary、Context 或 Testing 标题；仅在适用时包含 Breaking Changes 与 Fixes。要点以加粗名词标签开头，命名类、模块、界面或行为，不用 Motivation、Rationale、Background、Context、Tests 等论文式标签。先讲行为或问题，机制仅在有助于评审时说明。已从 issue、对话、提交信息或代码中得知的原因，随相关改动一并说明。技术术语使用前先引入。解析、排序或流式改动可给简短输入/输出示例。Breaking Changes 用于现有行为、签名或默认值变更，需描述具体影响与迁移方式；Fixes 用 Fixes #X，每条一个 issue。目标篇幅 200 词以内，优先删重复与次要实现细节。不写正确性断言、开发时间线、方案权衡、测试数量/覆盖率/通过状态、测试命令、文件清单、格言、推广语或收尾复述。以平实词汇、缩略形式和简短连贯句子，像向不熟悉此工作的同事解释。
限制：仅在用户请求时更新 GitHub；数据未提供该技能的安装方式、依赖、平台、收费与价格信息。