pull-request — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pull-request (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.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Authoring PR communication that respects busy reviewers. All bodies and comments are drafted to .scratch/pr-bodies/ for human review before posting. Anti-patterns (metrics, diff-noise, H1 headings) are avoided. Manual edits are detected before overwriting.
| Operation | Typical phrasing | gh command at end |
|---|---|---|
| Create | "create/draft/open/file a PR", "push and PR it" | gh pr create --body-file |
| Update body | "update the PR body", "rewrite the PR description" | gh pr edit --body-file |
| Comment | "comment on the PR", "reply to review feedback" | gh pr comment --body-file |
"update the PR" is ambiguous:
Prefer body update when there are no reviews yet, the user says "update the description", or scope changed. Prefer comment when reviews are in, the user is responding to feedback, or they want to notify watchers (comments generate notifications, body updates do not).
Check for a PR template (.github/pull_request_template.md, .github/PULL_REQUEST_TEMPLATE.md, .github/PULL_REQUEST_TEMPLATE/*.md) and CONTRIBUTING.md (also .github/CONTRIBUTING.md, docs/CONTRIBUTING.md). If a template exists, follow it exactly.
## Summary
- Material impact point 1
- Material impact point 2 (2-4 bullets total)
## Test plan
- How to verify (only if non-obvious)Optional sections based on context: ## Breaking changes, ## Migration notes, ## Follow-up work.
Imperative mood (Add, Fix, Update, Refactor), under 72 characters, capitalize first word, no trailing period. Derive from the branch name when semantic, otherwise from the first commit.
Metrics (unless the PR is about them): "Added 15 tests", "Modified 8 files", "Added 250 lines", "Coverage to 85%", "Runtime 2.5s to 1.2s".
Diff-visible details: "Created new Foo class", "Refactored into smaller functions", "Used async/await", "Added error handling" (unless that is the PR's focus).
Over-explaining: "After careful consideration of multiple approaches...", "significantly improves the developer experience by implementing a novel approach...".
Structural noise: H1 heading (GitHub shows the title separately), listing technologies unless a new dependency, file structure changes unless architectural, "following best practices" (assumed), "easy to" / "simple to" (condescending).
The rule: If a reviewer can see it in the diff or CI output, do not put it in the body unless it is the central focus.
Three to five sentences, conversational, professional. Acknowledge reviewer input. Explain reasoning when non-obvious. A common opening pattern: "I've updated the PR to address the feedback: ..."
gh pr view --json number 2>/dev/null. If one exists, error or route to update.git log <base>..HEAD, PR template, CONTRIBUTING.md..scratch/pr-bodies/drafts/<slug>.md. Show the draft to the user and allow edits.gh pr create --title "..." --body-file <draft-path> (add --draft if the user asked for a draft)..scratch/pr-bodies/<number>/<timestamp>-body.md and write metadata.json with the body hash.gh pr view --json number,body,title,state. Load metadata.json if present. Warn if closed or merged.shasum -a 256) and compare to last_generated_hash. If different and the diff is more than whitespace, ask: overwrite, merge, or cancel.<base>..HEAD. If scope is unchanged from last generation, skip the update and say "description still accurate"..scratch/pr-bodies/<number>/<timestamp>-body.md. Show the diff (current vs proposed) and confirm.gh pr edit <number> --body-file <file>. Update metadata.json (new hash, timestamp).gh pr view --json number,title,reviews,comments..scratch/pr-bodies/<number>/<timestamp>-comment.md. Show the draft and confirm.gh pr comment <number> --body-file <file>.Always: current branch is not main/master; gh is installed and authenticated; the user has seen and approved the draft.
Create: branch has commits ahead of base. Update: PR exists and is open. Comment: comment is not empty.
If gh is missing, fall back with brew install gh. If not authenticated, gh auth login.
.scratch/pr-bodies/
drafts/
<slug>.md # Pre-creation drafts
<pr-number>/
metadata.json # See schema below
<timestamp>-body.md # Timestamped body versions
<timestamp>-comment.md # Timestamped commentsmetadata.json:
{
"pr_number": 123,
"branch": "feature/foo",
"base": "main",
"title": "Add foo",
"created_at": "2025-11-07T10:30:00Z",
"last_generated_hash": "abc123...",
"last_updated_at": "2025-11-07T16:45:30Z",
"manual_edits_detected": false
}Timestamps use ISO 8601 with hyphens (2025-11-07T10-30-00). Slugs are lowercase with hyphens and special chars stripped.
Keep: metadata.json, the last five timestamped files, any in-progress draft. Clean up after PR creation: the draft file. Optional: timestamped files older than 30 days.
base=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null)
if [ -z "$base" ]; then
git show-ref --verify --quiet refs/heads/main && base=main || base=master
figh pr list --head <branch> --state open. If exactly one open, use it. If zero, check --state all and offer to create new. If more than one (rare), ask which.
gh pr create/edit/comment.gh pr create without --body-file. Shell-escaping issues and no draft review step.main/master. Stop and ask the user to branch first.gh pr list --head <branch>.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.