Write complete, evidence-backed PR descriptions for microsoft/apm pull requests.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "pr-description-skill" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/apm/main/packages/pr-description-skill/SKILL.md 2. Save it as ~/.claude/skills/pr-description-skill/SKILL.md 3. Reload skills and tell me it's ready
Write a PR description for microsoft/apm based on this branch's changes. Output complete GitHub-Flavored Markdown with TL;DR, Problem, Approach, Implementation, trade-offs, validation evidence, and How-to-test, plus 1-2 mermaid diagrams explaining the flow.
A complete Markdown PR body ready to paste into GitHub, with clear structure and testing instructions.
I already have the code diff and related design notes. Please fill out the full PR template. Every WHY claim must cite verbatim text from the source PROSE or Agent Skills, and explicitly list implementation trade-offs and validation evidence.
A traceable PR body draft that helps reviewers quickly understand motivation, approach, and validation results.
Draft a PR body for this refactor. Emphasize why the refactor is needed, which modules changed, implementation details, risks and trade-offs, and include a How-to-test section. Add 1-3 validated mermaid diagrams if appropriate.
A high-quality PR description for code review that helps the team review complex refactor changes efficiently.
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,
…
Guide APM positioning, release communication, and breaking-change strategy decisions.
Audit an entire docs corpus against code and propose precise fixes.
Improve CLI output, logs, errors, and terminal diagnostic user experience.
Triages bug batches and drives related PRs to a mergeable state.
Plan doc TOC changes and outline stubs when PRs require structural updates.
Triage APM issues in batches and drive approved ones to mergeable PRs.
Assess PR documentation impact and produce actionable update guidance every time.
Run a multi-expert advisory review for labelled microsoft/apm pull requests.
Triage microsoft/apm issues and produce one unified resolution comment.
Create, refine, validate, and restructure AgentSkills and SKILL.md files.
Convert skills from other AI coding assistants into Amplifier-native SKILL.md files.
Write, review, and standardize Agent Skills to match agentskills.io requirements.