write-pr-description

Write PR titles and descriptions the way a staff engineer would. Use when drafting or editing a pull request title and body, before running `gh pr create`, or any time the user asks for a PR description, summary, or release-notes-style writeup of a change. Apply this skill from the start, not as a cleanup pass after a generic first draft.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an excellent, lean instruction set with concrete formats, good/bad contrasts, a full worked example, and a final self-validation checklist. Its weaknesses are the absence of an explicit step-by-step workflow and the lack of any progressive disclosure, with the worked example and long contrast examples inlining material that would fit a references file.

Suggestions

Move the worked example (section 9) and possibly the extended good/bad examples (sections 3 and 7) into a references/ file (e.g., references/examples.md) linked from the body, keeping SKILL.md as a lean overview.

Add a short numbered procedure near the top (gather the change context, write the title, draft the body, run the section 8 check) so the workflow sequence is explicit rather than implied by section numbering.

Fix the typo "obeservation" in section 2 ("the obeservation (symptom or user-visible change first or intent)") to keep the prose rules credible.

Dimension	Reasoning	Score
Conciseness	Every section earns its place: it never explains what a PR is or how git works, uses short directives ("No padding, no checkbox theater", "Keep it under ~70 characters"), and puts its length into examples rather than explanation. This matches the 5 anchor (lean, assumes competence, every token earns its place).	5 / 5
Actionability	Guidance is fully concrete and executable: exact title formats ("[fix] Resolve broken evaluation links", "[fix] <Title> [AGE-1234]"), a copy-paste body skeleton in a code block, good/bad title and body examples, and a full worked before/after PR. For an instruction-only skill this matches the 5 anchor's specific-examples-cover-common-cases standard.	5 / 5
Workflow Clarity	Sections 0-9 give a clear implicit sequence (template -> title -> body -> style -> sections -> final check), and section 8 is an explicit validation checkpoint with a corrective loop ("If any answer is no, edit before you push"). It falls short of the 5 anchor because the overall procedure is never laid out as an explicit ordered workflow, and mid-process checkpoints between drafting steps are absent.	4 / 5
Progressive Disclosure	Sections are well organized and navigable, but the single 180-line file inlines content that belongs in a reference file: the ~35-line worked example (section 9) and the extended good/bad examples in sections 3 and 7. With no references/ directory at all, this matches the 3 anchor (good structure, but content that should be separate is inline) rather than the 4 anchor's mostly-appropriate placement.	3 / 5
	Total	17 / 20 Passed

Description

91%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete capability statement, an explicit and multi-scenario "Use when" clause, and natural trigger terms including the tool-level hook of `gh pr create`. The only weakness is slight breadth from the release-notes/summary phrasing, which blurs the boundary with adjacent writing skills.

Suggestions

Consider dropping or narrowing "release-notes-style writeup of a change" if a separate commit-message or release-notes skill exists, to reduce trigger overlap.

Optionally name one or two more concrete capabilities (e.g., structuring the body with Context/Changes/Tests sections) to push specificity from several actions toward comprehensive coverage.

Dimension	Reasoning	Score
Specificity	"Write PR titles and descriptions" plus "drafting or editing a pull request title and body" names the domain and several concrete actions (write, draft, edit titles and bodies). It falls just short of the 5 anchor because it does not enumerate the fuller capability set (e.g., structuring the body, QA sections) that the skill actually covers.	4 / 5
Completeness	Both what and when are explicit: what is "Write PR titles and descriptions the way a staff engineer would", and when is a full "Use when" clause listing three concrete trigger scenarios. This matches the 5 anchor exactly.	5 / 5
Trigger Term Quality	Natural user phrasing is comprehensively covered: "PR description", "pull request title and body", "summary", "release-notes-style writeup", and the tool trigger "before running `gh pr create`". These match what a user would actually say when they need this skill, matching the 5 anchor's synonym-level coverage.	5 / 5
Distinctiveness Conflict Risk	The PR/`gh pr create` niche is distinct and clear, but "release-notes-style writeup of a change" and "summary of a change" create minor overlap risk with commit-message and release-notes skills, fitting the 4 anchor (mostly distinct, minor overlap with closely related skills) rather than the 5 anchor.	4 / 5
	Total	18 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning

	Total	15 / 16 Passed

Repository: Agenta-AI/agenta
Path: .agents/skills/write-pr-description/SKILL.md
Commit: 7a975fb

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.