# Human Review Pack

> Assemble a concise, evidence-backed PR/release review pack — what changed and why, impact, the verify proof, reviewer findings (fixed and deferred), and the exact decision needed. Read-only; writes the pack. Front door for /human-review-pack.

- Skill: `keyvaluesoftwaresystems/human-review-pack` (Agent Skill)
- Install (CLI): `npx skillmds@latest add keyvaluesoftwaresystems/human-review-pack`
- Raw SKILL.md: https://api.skillmd.com/api/skills/keyvaluesoftwaresystems/human-review-pack/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: keyvaluesoftwaresystems (https://skillmd.com/u/keyvaluesoftwaresystems)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/keyvaluesoftwaresystems/human-review-pack

---


# human-review-pack

Assemble everything a human needs to approve a PR or release — **with evidence, not
claims.** Read-only. The pack must let a reviewer decide in minutes and must not overstate
readiness.

## Steps
1. **Collect the diff summary** — changed files/areas per stack; new endpoints/migrations/UI.
2. **Pull the proof** — the `/verify` reports and per-stack verify markers; the QA suite
   result. Read the inputs your instructions point to. If proof is missing or `status:"fail"`,
   say so — do not claim green.
3. **Pull the reviewer findings** — from the architecture review and each stack's review;
   separate what was **fixed** from what is **deferred/accepted**.
4. **Assess risk & release readiness** — migrations, flags, rollout/backout, data impact.
5. **Write** the pack and state the exact decision required.

## The pack must include (with evidence/links)
1. **What changed** — feature summary + per-stack change list.
2. **Why** — link the requirement/HLD; the problem solved.
3. **Files changed** — grouped by area; call out anything security/auth/data-sensitive.
4. **API / DB / UI impact** — contract changes (breaking?), migrations (+ rollback), new UI states.
5. **Tests & proof** — commands run and pass/fail (from `/verify`); coverage vs the
   coverage bar (80% on changed code); QA journeys covered;
   screenshots / Playwright traces for frontend.
6. **Review findings fixed** — with the reviewer + severity.
7. **Findings intentionally NOT fixed** — each with a reason and risk acceptance.
8. **Risks & limitations** — known issues, perf/scale caveats, follow-ups.
9. **Rollout & backout** — flag state, phased plan, metrics to watch, how to revert.
10. **Decision needed** — approve / changes requested / reject, and exactly what to approve
    (e.g. merge order backend → frontend).

## Edge cases to represent honestly
- **Partial green** — some checks pass, one is flaky/red → say it plainly; don't average it away.
- **Deferred blockers** — a major finding accepted for later needs explicit sign-off and a ticket.
- **Missing proof** — no verify marker, or `status:"fail"` → the pack recommends "not ready".
- **Breaking contract change** — surface prominently with the consumer migration plan.
- **Risky migration / irreversible step** — flag as requiring extra human attention.

## Output
Write the pack to the artifact path your instructions specify (the orchestrator passes it).
Running standalone? write to a sensible path you choose and tell the user where. Never claim readiness
without the proof to back it — the review pack is a decision aid, not a rubber stamp.

## Output contract
Return `pack_path`, `recommendation` (`ready` | `changes-requested` | `not-ready`,
mirroring the pack's "Decision needed" section), and `summary` (one line the human reads
at the release gate).