How do I install the Pr Author skill?

Run npx skillmds@latest add drmoisan/pr-author in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pr Author safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pr Author?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pr Author free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pr Author?

drmoisan (@drmoisan) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Author by drmoisan — Agent Skill

Name: Pr Author
Author: drmoisan

File contents

PR Author Skill

Produce a GitHub-ready Pull Request description from the standard PR context files. The pull request must be in a copy / paste block so that it can be copied easily to the PR extension.

Inputs

artifacts/pr_context.summary.txt — PR context summary (primary)
artifacts/pr_context.appendix.txt — PR context appendix (full baseline diff, commits, changed files)
Optional user directives

Only reference files that are listed under "Additional context files" in the context bundle. Do not cite or summarize files outside that enumeration.

Output Requirements

Output only the PR text body in GitHub-flavored Markdown.
Use clear headings, consistent structure, and concise bullets.
Do not invent tests or results; if not in context, state "Not verified in this PR."
If scope is large, include a Review Guide with suggested review order.
The output is a PR body artifact or PR-ready body text only.

PR Body Structure

Use these sections in this order:

Suggested title — crisp, prioritizing the primary outcome
Summary — 3–7 bullets, most important first; lead with the primary product/feature/architecture change
Why — motivation, constraints, root cause; rely on embedded feature-doc excerpts and PR Intent fields only
What Changed — grouped by theme (core feature, tooling/CI, tests, docs/templates)
Architecture / How It Fits Together — short wiring description with components, entry points, control flow
Verification — "Completed" (from context) and "Recommended" (commands to run)
Backward Compatibility / Migration Notes — breaking changes, removals, renamed paths
Risks and Mitigations — realistic risks with mitigations and rollback notes
Review Guide — suggested order, noisy mechanical moves, large diffs
Follow-ups — known TODOs, deferred cleanup, next PRs
GitHub Auto-close — - Closes #NNN only from verified autoclose lists; do not invent issue numbers

Issue/PR Reference Rules

Only mention an issue/PR number if it appears verbatim in the provided context.
Do not treat PR numbers as issues.
Auto-close bullets must use exactly - Closes #NNN format, sourced only from "Issues to autoclose" or "Author-asserted autoclose issues."
If GitHub validation is unavailable or unverified, do not emit Closes; use the None bullet.

---name: pr-authordescription: Write a GitHub-ready pull request body from the canonical PR-context bundle with strict verification and auto-close rules.---# PR Author SkillProduce a GitHub-ready Pull Request description from the standard PR context files. The pull request must be in a copy / paste block so that it can be copied easily to the PR extension.## Inputs- `artifacts/pr_context.summary.txt` — PR context summary (primary)- `artifacts/pr_context.appendix.txt` — PR context appendix (full baseline diff, commits, changed files)- Optional user directivesOnly reference files that are listed under "Additional context files" in the context bundle. Do not cite or summarize files outside that enumeration.## Output Requirements1. Output only the PR text body in GitHub-flavored Markdown.2. Use clear headings, consistent structure, and concise bullets.3. Do not invent tests or results; if not in context, state "Not verified in this PR."4. If scope is large, include a Review Guide with suggested review order.5. The output is a PR body artifact or PR-ready body text only.## PR Body StructureUse these sections in this order:1. **Suggested title** — crisp, prioritizing the primary outcome2. **Summary** — 3–7 bullets, most important first; lead with the primary product/feature/architecture change3. **Why** — motivation, constraints, root cause; rely on embedded feature-doc excerpts and PR Intent fields only4. **What Changed** — grouped by theme (core feature, tooling/CI, tests, docs/templates)5. **Architecture / How It Fits Together** — short wiring description with components, entry points, control flow6. **Verification** — "Completed" (from context) and "Recommended" (commands to run)7. **Backward Compatibility / Migration Notes** — breaking changes, removals, renamed paths8. **Risks and Mitigations** — realistic risks with mitigations and rollback notes9. **Review Guide** — suggested order, noisy mechanical moves, large diffs10. **Follow-ups** — known TODOs, deferred cleanup, next PRs11. **GitHub Auto-close** — `- Closes #NNN` only from verified autoclose lists; do not invent issue numbers## Issue/PR Reference Rules- Only mention an issue/PR number if it appears verbatim in the provided context.- Do not treat PR numbers as issues.- Auto-close bullets must use exactly `- Closes #NNN` format, sourced only from "Issues to autoclose" or "Author-asserted autoclose issues."- If GitHub validation is unavailable or unverified, do not emit `Closes`; use the `None` bullet.

Frequently asked questions

Pr Author