$ loading_
为 microsoft/apm 的拉取请求自动撰写结构完整、证据充分的 PR 描述。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "pr-description-skill" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/apm/main/packages/pr-description-skill/SKILL.md 2. 保存为 ~/.claude/skills/pr-description-skill/SKILL.md 3. 装好后重载技能，告诉我可以用了
请根据这个分支的改动为 microsoft/apm 写一份 PR description，输出完整的 GitHub Flavored Markdown，包含 TL;DR、Problem、Approach、Implementation、trade-offs、validation evidence、How-to-test，并用 1-2 个 mermaid 图说明流程。
一份可直接粘贴到 GitHub PR 正文的完整 Markdown 描述，结构清晰且包含测试说明。
我已经有代码 diff 和相关设计说明，请帮我填完整个 PR 模板。要求每个 WHY 论点都引用原始 PROSE 或 Agent Skills 的逐字内容，并明确列出实现权衡与验证证据。
一份带有可追溯依据的 PR 正文草稿，便于评审快速理解动机、方案和验证结果。
请为这次重构提交起草 PR body，重点说明为什么要重构、改动了哪些模块、实现细节、风险与取舍，并补充 How-to-test。若合适，请加入 1-3 个经过校验的 mermaid 图。
一份面向代码评审的高质量 PR 描述，帮助团队快速审阅复杂重构改动。
Trigger this skill on any of the following intents:
Reusable for any PR against microsoft/apm. The output is one
markdown file that the orchestrator pastes into
gh pr create --body-file or surfaces to the maintainer.
The repo-wide encoding rule at
.github/instructions/encoding.instructions.md constrains
source files and CLI output to printable ASCII because Windows
cp1252 terminals raise UnicodeEncodeError on anything else. PR
comments are NOT source code and NOT CLI output -- they are rendered
by GitHub's Primer engine, which expects UTF-8 GitHub-Flavored
Markdown.
Two distinct rules therefore apply:
SKILL.md, assets/*) MUST
stay ASCII. They live in the repo and are subject to
.github/instructions/encoding.instructions.md.A previous version of this skill incorrectly required ASCII in the PR body. That made the output unreadable: no alerts, no collapsibles for long evidence, no em dashes, no smart quotes. Reviewers had to scroll through hundreds of flat lines instead of scanning a body shaped by GFM features.
The skill aims for 150-220 lines for a typical PR body. 300+ lines is a smell, not a virtue. If your draft exceeds 250 lines, run a tightening pass: every sentence that does not change the reviewer's understanding must be cut.
Per-section ceilings (enforced by assets/section-rubric.md):
| Section | Ceiling |
|---|---|
| TL;DR | 2-4 sentences |
| Problem (WHY) | max 6 bullets, max 3 quoted anchors total |
| Approach (WHAT) | a table OR 3-7 bullets; may be skipped if PR is purely additive (say "additive: see Implementation") |
| Implementation (HOW) | one short paragraph per file, OR a table; no prose walls |
| Diagrams | 1-3 mermaid blocks; every diagram preceded by a one-sentence legend |
| Trade-offs | 3-5 bullets; mechanical PRs may be 1-2 |
| Benefits | 3-5 numbered items, each measurable |
| Validation | copy-paste real command output; do not narrate |
| How to test | max 5 numbered steps |
Long verbatim quote blocks, full file listings, and full validation
transcripts SHOULD live inside <details> so the body stays
scannable.
Each rule the skill enforces is backed by a verbatim quote from one of the two reference docs. If a rule below cannot be backed by a quote, it is downgraded to a "should" with the reason given.
Self-sufficient body. A reviewer must be able to read the PR body and form an opinion without opening any other doc, issue, or chat. Every WHY-claim cites the source doc inline; every named file is qualified with what changed in it; every diagram has a one-sentence legend.
Anchor: Agent Skills, "agents pattern-match well against concrete structures".
Anchored: every WHY-claim cites its source. Every claim of the form "this violates X" or "this satisfies Y" is followed by a verbatim quoted phrase wrapped in a hyperlink to the source page. Reproduce quotes character-for-character; do not paraphrase inside link text.
Anchor: PROSE,
…
优化 APM 代码库中的 CLI 输出、日志提示与诊断信息体验
帮助团队为 microsoft/apm 新问题完成分诊并生成统一处理意见。