用途：该技能负责一份 PR 的“写稿”——PR 正文，或对 PR 评论的回复，输出简短、一次即可读懂并行动的要点。它只管撰写，找问题、溯源与拆分 PR 分别由 /review、/prepare-for-review、/split-prs 负责。可在任意仓库运行；存在 docs/agents/ 和 breadcrumbs 时输出更精确，但不作强制要求。
行文约定：采用变更日志口吻，直接说明做了什么、带来什么结果。每点一个想法、一行、至多 20 词；句中出现分号即应拆为两点。只使用项目词汇（来自 CONTEXT.md 的领域术语，符号和路径按 diff 原样拼写），不造标签。diff 无法支持且无来源佐证的论断不写入页面；推断出的理由须标明是推断。能用代码更短表达的修复直接用代码块，不加说明句。禁止赞美、开场白、结尾总结和下一步建议。避免 This PR adds、great、clean、crucial、comprehensive、refactored for better maintainability、leverage、ensure、emoji 与感叹号等词。
正文模式：触发方式为在分支或 PR 上使用 /concise，或 /concise <pr>。先锁定目标（比较基线或默认分支，如默认分支可取自 gh repo view --json defaultBranchRef -q .defaultBranchRef.name；已有 PR 则编辑而非新建），再查找仓库的 PR 模板（优先 .github/PULL_REQUEST_TEMPLATE.md 等，找不到则用 ../prepare-for-review/TEMPLATE.md，仍无则用内置形状）。保留模板所有标题、顺序与复选框，去掉指导性注释，空的可选段落直接省略，把模板的散文要求改成要点。正文整体不超过 250 词；Problem 至多 3 点，Solution 至多 6 点且每点需点名 diff 中的符号或路径，超过 6 点即建议拆分；Tests 每点对应 diff 中的测试文件。完成后逐行审计，再展示草稿与推送计划，等待明确批准后用 git push -u origin <branch> 与 gh pr create --title "<title>" --body-file <tmp> 创建，或用 gh pr edit <n> --body-file <tmp> 更新。
回复模式：触发方式为 /concise reply，或在参数中指定含未回复评论的 PR。先用 gh pr view 和 gh api repos/{owner}/{repo}/pulls/{n}/comments 拉取线程，按 in_reply_to_id 分组并定位到文件与行，跳过已由本人回复或已标记解决的线程。每个线程给出一种处置（Fixed、Already handled、Won't do、Disagree、Question back），首点写处置，其余为证据；每线程至多 4 点，须引用 commit SHA 或 file:line，绝不承诺未做的修改。审计通过并获批准后，行内线程用 gh api repos/{owner}/{repo}/pulls/{n}/comments/{comment_id}/replies --method POST -f body=@<tmp> 回复，顶层评论用 gh pr comment <n> --body-file <tmp>；不要把行内答复发成 PR 底部评论。已关闭、已合并或草稿状态的 PR 跳过。
限制：官方未提供该技能的收费、价格、平台或效果信息；具体要求与命令应以其所在仓库资料为准。