From peer-qa-review
Use when reviewing a teammate's completed work as Round-1 IT QA (before customer acceptance / QA2 / internal close). Triggers: tickets moved to QA, 'ready for QA' / 'ready for review' comments, or requests for 'IT QA review' / 'peer review' / 'internal QA' / 'quality gate'. Covers a 6-stage lifecycle, severity vocabulary, comment template, edge cases, anti-patterns. Generic for any IT/Ops team.
How this skill is triggered — by the user, by Claude, or both
Slash command
/peer-qa-review:peer-qa-reviewThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
A teammate marked work **ready for QA**. Verify before it reaches customer
A teammate marked work ready for QA. Verify before it reaches customer
acceptance, QA2, or internal close: re-run verification; check formal
correctness, inventory, docs; post a structured comment; transition. Not
rubber-stamping; detail in references/.
Triggers: see description. Skip if: still In Progress (transition first); already QA2 (different scope); already closed (post-mortem only); or you are the implementer (no self-review).
A ticket-system skill is required (Jira: jira-communication); Stage 0 uses it
for single-call discovery. Consult team IT/maintenance skills for overrides.
scripts/qa-gather.sh <KEY> (--json to parse).Reuse the Atlassian set. (/) passed; (x) MUST/blocking (bounce); (!)
SHOULD (document, follow-up if structural); (i) hint; (?) open question
(block); (off) n/a (never (-) or *n/a*).
One internal QA comment: header h3. IT Internal QA, h4 section per pillar,
severity icons, a verdict line.
On a QA2 verdict, post a second, separate comment: the customer handover. The internal QA comment is addressed to IT and never states the acceptance check, leaving the approver lost. The handover is plain (no jargon or icons): what was delivered, the one acceptance check, the next step.
(x) clear, IT-internal; QA to Closed/Done, then
clear your assignment — Resolve often leaves the assignee set; Close clears it.(x) clear, customer-affecting; post the QA comment and
a customer handover; QA to QA2, assign the product owner.(x); QA to In Progress, comment the blocker, reassign.When uncertain, default to QA2.
The cardinal one: no re-execution by the reviewer — copy-pasting the
implementer's output is not QA. Others (giant final comments, Jira Markdown
leakage, end-of-run inventory, tags without a green pipeline) in
references/anti-patterns.md.
references/lifecycle.md, references/checklist.md (checks by pillar);
references/severity.md; references/comment-template.md (template, examples,
customer handover); references/edge-cases.md (QA2 routing, bounce, won't-do,
self-review); references/anti-patterns.md; references/frameworks.md.
Whole-repo audit for over-engineering: finds dead code, unnecessary abstractions, stdlib-replaceable dependencies. Outputs ranked findings and net line/dep savings.
npx claudepluginhub netresearch/claude-code-marketplace --plugin peer-qa-review