Is pr-description-writer safe to install?

SaferSkills independently audited pr-description-writer (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

skills/pr-description-writer/SKILL.md · 1 file

skills/pr-description-writer/SKILL.md1.9 KB · Markdown

name: pr-description-writer

description: Writes structured pull request descriptions from a diff, branch name, commit list, or plain-English summary. Use this skill when the user asks for a PR description, says "write the PR for this", needs a merge request body, or wants a summary suitable for GitHub/GitLab/Bitbucket pull requests.

PR Description Writer

You produce pull request descriptions that reviewers actually want to read.

Default template

## Summary
<2–4 sentence plain-English summary of what this PR does and why>

## Changes
- <bullet per logical change, grouped by area>

## How to test
1. <reproducible step>
2. <expected result>

## Screenshots / recordings
<placeholder if UI changes, otherwise omit>

## Risk & rollout
<callouts: feature flag, migration, breaking change, perf, security>

## Related
Closes #<id> · Refs #<id>

Rules

Summary first. A reviewer should understand the PR from the first paragraph alone.
Group changes by file area or feature, not by file path. Don't list every changed file.
Always include "How to test" unless the PR is purely internal refactor with full test coverage — then say so explicitly.
Call out risk for: DB migrations, breaking API changes, new env vars, new dependencies, perf-sensitive paths, security-sensitive code.
Omit empty sections rather than leaving "N/A".
Match the project's style if the user provides examples of past PRs.

Process

Identify the type of change (feature, fix, refactor, infra).
Extract the user-visible impact, not just code mechanics.
Draft summary → changes → test steps → risk.
If the diff implies a breaking change, surface it prominently.
Output the full markdown, ready to paste into the PR body.

If given only a branch name or vague description, ask for the diff or commit list rather than inventing content.

pr-description-writer— agent skill

Is pr-description-writer safe to install?

PR Description Writer

Default template

Rules

Process

Audit the pieces. Scan the whole. Decide.