/pr-quality-report

name: pr-quality-report
description: Write the Quality Report that closes a pull request description — changes summary, security analysis, tests written, checks deferred to CI, performance, and accessibility, each section only when the diff touched its subject — and attach it as the last section of the PR body, or regenerate it safely on an existing PR. Also covers passing any multiline body to gh with --body-file and a quoted heredoc. Invoke when the user asks for a "quality report", to "add" or "update the quality report on the PR", to "regenerate the PR report", or when project instructions require a Quality Report before a task is done.

PR Quality Report

Write the Quality Report for a pull request and attach it as the last section of the PR body. The main session runs this skill directly; no orchestrator agent is involved.

⚠️ Side Effect Warning

**On an existing PR, this skill rewrites the PR description** — public, and visible to everyone on the repository.

**Confirmation required.** Show the report and wait for explicit approval before `gh pr edit`. When `pr-create` calls this skill before its own approval gate, that gate covers the report and no second confirmation is needed.

Usage

• "Write the quality report for this PR"
• "Update the quality report on PR 347"
• "Regenerate the quality report after the last push"

Definitions

• **Custom code** — code the repository owns: custom modules, themes, plugins,

application code, templates, build config, tests.

• **Dependency-only change** — version bumps and lockfile churn with no custom code

edited: Composer and npm bumps, Drupal module updates, WordPress plugin updates, package metadata, and core patch or security releases (Drupal 11.3.19 → 11.3.20). A dependency that is patched, forked, or overridden counts as custom code.

• **Core, framework, or PHP upgrade beyond a patch release** (Drupal 11.3 → 11.4,

WordPress 6.7 → 6.8, PHP 8.3 → 8.4) is **not** dependency-only: it runs update hooks, changes config, and deprecates APIs the custom code uses. Security Analysis applies, and Snyk runs on the custom code it touches.

What goes in the report

**Report only on what changed.** Omission is the default. A section whose subject the diff never touched is left out entirely — no heading, no placeholder, no row of `N/A`. `N/A` across a section you could have deleted adds length without information and trains readers to skim past the sections that matter.

| Section | Include when | |---|---| | Changes Summary | Always | | Security Analysis | Custom code changed | | Tests Written | Logic, services, utilities, or user-facing behaviour changed | | Deferred to CI | Something was written this session but not run locally | | Performance | Queries, caching, or asset loading touched | | Accessibility | Markup, templates, or UI components touched |

• **Never omit a section to shorten the report.** Omit it because its subject did not

change. If an applicable section runs long, shorten its content.

• **Never add a file list** — no "Files Modified" section, no table of paths, no

per-file summary. GitHub's Files changed tab already has them, with diffs, and a hand-written copy goes stale on the next commit. Say what changed in Changes Summary; let the diff show where.

• **Never restate what CI reports** — no "Static Checks" section, no pass/fail table

for linters, static analysis, type checks, or test runs CI also performs. The checks UI is the live record. Record a local check only when it has **no CI equivalent**, and then in the section that covers it, never a table of its own.

• **Steps to Validate lives in the PR template.** Do not duplicate it here.
• **It is a deliverable, not a summary.** Style rules that suppress end-of-task

summaries do not apply to it.

• **No hard wrapping.** Every bullet and table cell is one unbroken line; GitHub renders

a newline inside a paragraph as a line break.

## Quality Report

### Changes Summary
- What changed and why

### Security Analysis
- [ ] Snyk SAST: [Pass / Fail] — findings
- [ ] No hardcoded secrets or credentials
- [ ] Input validation on system boundaries
- [ ] No SQL injection, XSS, or command injection vectors

### Tests Written
- [ ] Unit: [Created / Updated / Existing] — list test files
- [ ] Functional / E2E: [Created / Updated / Existing] — list test files
- [ ] Edge cases considered: [list]

### Deferred to CI
- Environment-dependent checks written but not run locally, e.g. functional tests, E2E

### Performance
- [ ] No N+1 query patterns introduced
- [ ] Caching strategy: [described if relevant]
- [ ] Frontend impact: [Lighthouse-relevant notes if applicable]

### Accessibility
- [ ] WCAG 2 AA for new UI elements
- [ ] Semantic HTML used

The Snyk line

When Security Analysis applies, run `snyk code test <path>` on every changed custom directory and report Pass or Fail with its findings. **Never mark it N/A** — if custom code changed, the scan is applicable. On a dependency-only change the whole section is omitted, so there is no line to write.

If Snyk reports no supported files (`SNYK-CODE-0006` — Markdown, YAML, and other files it cannot analyze), say so and leave the box unchecked. No supported files is a result, not a Pass.

Honesty

State only what this session produced. A test file that was written is not a test that passed; tests run in CI are reported by the checks UI, not here. Unknown is never Pass.

Attaching it to the PR

The report is the last section of the PR body. That makes regenerating it safe: strip the previous report, then append the new one. Only org attribution may follow it — anything else placed after the report is destroyed on the next regeneration. A `Delivery Record:` link belongs above the report.

**Org attribution.** Claude Code's `attribution.pr`, often pushed through org managed settings, ends PR descriptions with a fixed line — Kanopi's is `- [x] Was AI used in this pull reque