progressive-harsh-review
Skill8 starsChanged 6 months agoMITView on GitHub
Adversarial review for plans, specs, and other non-code deliverables. One persona for reversible work, three for irreversible (ADRs, contracts, migrations). Route code to code-review-battery and skill files to llm-skill-review.
In this repository129 other files it gives its agents.
- AGENTS.mdAGENTS.md
- guidance/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- guidance/CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- blast-radius-checkSkill
- brainstormingSkill
- branch-flow-gateSkill
- branch-sync-gateSkill
- codebase-reconSkill
- codeowners-drift-auditSkill
- code-review-batterySkill
- cognitive-complexity-refactoringSkill
- debateSkill
- debug-conductorSkill
- dispatching-parallel-agentsSkill
- domain-buildSkill
- evidence-adjudicatorSkill
- executing-plansSkill
- external-cli-auditSkill
- feature-developmentSkill
- field-rename-verificationSkill
- finishing-a-development-branchSkill
- git-branch-conventionsSkill
- gitlab-cliSkill
- hotfix-charterSkill
- implementation-trackerSkill
- incident-revert-reviewSkill
- infra-config-investigatorSkill
- investigation-stateSkill
- kernel-splitSkill
- llm-behavior-investigatorSkill
- llm-skill-reviewSkill
- merge-authorization-gateSkill
- micro-harsh-reviewSkill
- output-verificationSkill
- pre-commit-gateSkill
- progressive-code-review-gateSkill
- providing-code-reviewSkill
- pr-triage-gateSkill
- push-authorization-gateSkill
- receiving-code-reviewSkill
- reproduction-experiment-investigatorSkill
- requesting-code-reviewSkill
- requirements-validation-pmSkill
- requirements-validationSkill
- scope-tripwireSkill
- session-handoffSkill
- skills-hierarchy-tuningSkill
- sp-bughuntSkill
- state-consistency-investigatorSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- timeline-trace-investigatorSkill
- token-estimationSkill
- unified-commit-gateSkill
- using-git-worktreesSkill
- using-superpowersSkill
- verification-before-completionSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 63
Use before presenting non-code work or on a hostile-review request.
- Distinctive: line 67
Persona count: all three for irreversible artifacts (ADRs, API/contract specs, migrations, security policy, author-marked).
- Very specific: line 85
Verdict: Use the table. A repository floor raises the PASS bar only.
- Distinctive: line 109
Only PASS clears the gate.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reference index
| Need | Reference section |
| Repository sets a score floor | Project-min override |
| Final report needs a template | Scoring output format |
| Review behavior looks weak | Anti-Patterns |
| A neighboring workflow is needed | Companion skills |
Progressive Harsh Review
Mechanical routing: Run
tools/review.sh route <path> [<path> ...]first. Obey its result; stop on error or an unclassified artifact.Wrong skill? Code ->
code-review-battery; skills/tooling ->llm-skill-review; design comparison ->debate.
Announce at start: "I'm using the progressive-harsh-review skill to red-team this work."
When to use
Use before presenting non-code work or on a hostile-review request. Exclude code, skills, brainstorming, and design-option selection.
Persona dimension table
Persona count: all three for irreversible artifacts (ADRs, API/contract specs, migrations, security policy, author-marked); otherwise SeniorArchCritic alone; unsure -> three. Each persona reads independently. Send only its row, the common dimension questions, and artifact/repository access.
| Persona | Start point | C | S | V | B | OR |
| JuniorDevNitpicker | Line-by-line prose | 35 | 25 | 15 | 20 | 5 |
| SeniorArchCritic | Promises vs. evidence | 25 | 15 | 25 | 15 | 20 |
| OpsRealist | Failures and state changes | 25 | 10 | 10 | 25 | 30 |
Dimensions: Correctness (holds?), Simplicity (needless complexity?), Verifiability (checkable?), Blind Spots (omissions?), Operational Risk (adverse failures?). Each row totals 100.
For user-visible functionality, missing named metrics and trace/span strategy caps OpsRealist's Operational Risk at 4; cite the omission.
Review process
- Fresh-reader check. Flag local paths, undefined identifiers, process commentary, and inaccessible references. Remove this author noise before shipping; do not lower scores for it alone.
- Independent review. Author != Reviewer. Dispatch the personas chosen above from artifact paths with only their row, five questions, and repository access. Persona reviewers must not invoke PHR, debate, code-review-battery, or other reviewers; each returns one scorecard. Remediate only after aggregation.
- Score. Score each dimension 1-10 with the persona's weights; with three, take the equal-weight average of the weighted scores.
- Apply veto. Correctness or Operational Risk <=4 is a hard veto only with a specific defect. Unrecoverable failures must affect Operational Risk, not Blind Spots alone.
- Verdict. Use the table. A repository floor raises the PASS bar only; load
Project-min override. - Remediate. Fix and verify every material finding. After round one, continue the same reviewer on the delta (a fresh one needs the full prior findings). REJECT requires root-cause analysis and full re-review.
- Check correlation. Any flag below or unsupported clean sweep requires a new persona starting point.
- Converge. Require the active floor, no veto/flag, and no new material issues. Escalate after 3 rounds without convergence; never auto-ship.
Verdicts
| Weighted mean | Verdict | Action |
| >=8 | PASS | Ship after all gates clear |
| 7 to <8 | PASS_WITH_FIXES | Fix and rescore changed areas |
| <7 | REJECT | Root-cause, remediate, full re-review |
| Any with veto | REJECT | Clear the cited defect, full re-review |
PASS_WITH_FIXES never clears the gate. Limit the entire remediation cycle to 3 review rounds.
Correlated-failure checks
CORRELATED EVIDENCE: shared evidence; one persona restarts from its lens.ECHO REASONING: materially identical reasoning; require an independent restatement.- Clean sweep: each persona shows evidence from its distinct start point or re-examines.
Sentinel after PASS
Only PASS clears the gate. Run PHR AFTER git commit once the floor is met with no veto or correlation flag:
tools/run-phr.sh --verdict PASS --min-score "<weighted-mean>"Clearance holds only while the reviewed docs are byte-identical (tools/lib/sentinel-scope.sh).
Reference loading
Load only the needed section: Project-min override, Anti-Patterns, or Scoring output format (see the routing table above for exact heading names -- the loader below requires an exact match). When an installed copy is found (any of .claude/.codex/.agents), loading requires the separately-provisioned ~/.codex/superpowers-plus checkout -- an install missing that shared dependency gets a loud section-loader missing failure, not silent wrong content.
<!-- kernel-split-reference-loader:start -->_ks_ref=""
_ks_loader=""
for _candidate in \
"$HOME/.claude/skills/sp-phr/reference.md" \
"$HOME/.codex/skills/sp-phr/reference.md" \
"$HOME/.agents/skills/sp-phr/reference.md"
do
if [ -r "$_candidate" ]; then _ks_ref="$_candidate"; break; fi
done
if [ -n "$_ks_ref" ]; then
_ks_loader="$HOME/.codex/superpowers-plus/tools/section-loader.sh"
else
_project_root="$(git rev-parse --show-toplevel 2>/dev/null || true)"
_source_dir="$_project_root/skills/engineering/progressive-harsh-review"
if [ -n "$_project_root" ] && [ -r "$_source_dir/skill.md" ] && \
[ -r "$_source_dir/reference.md" ] && \
[ -r "$_project_root/tools/section-loader.sh" ]; then
_ks_ref="$_source_dir/reference.md"
_ks_loader="$_project_root/tools/section-loader.sh"
fi
fi
[ -r "$_ks_ref" ] || { printf 'reference missing\n' >&2; exit 1; }
[ -r "$_ks_loader" ] || { printf 'section-loader missing\n' >&2; exit 1; }
# Replace <section heading> below with one of the exact strings from
# the Reference index table above before running.
_section='<section heading>'
bash "$_ks_loader" "$_ks_ref" "$_section" \
|| { printf 'section not found: %s\n' "$_section" >&2; exit 1; }<!-- kernel-split-reference-loader:end -->Failure Modes
| Failure | Fix |
| Self-reviewed in same thinking pass | Use sub-agent (preferred) — in-process role switch with no context isolation is significantly less reliable; if used, explicitly discard the author's reasoning and start fresh from the artifact text |
| All personas gave same feedback | Each persona must name ≥1 plausible failure mode unique to their lens, or cite a specific property of the change explaining why none exists (generic dismissal = rubber-stamp) — identical findings means the lenses aren't distinct |
| Score inflated to avoid re-work | Findings with concrete issues MUST score ≤7 on that dimension |
| Only reviewed happy path | OpsRealist must consider failure, rollback, 3am scenarios, and OE telemetry for new behavior |
| Round N mean lower than Round N-1 | Remediation introduced new issues — flag REGRESSION, root-cause before Round N+1 |
| No output summary before presenting | Always emit PHR SUMMARY block (rounds, mean, verdict, project-min, vetoes) |
| Unrecoverable finding scored only on Blind Spots | Must ALSO score Operational Risk to be veto-eligible — Blind Spots alone bypasses the veto gate |
| Skipped sentinel write after PASS | Pre-push Gate 5 refuses the push with "PHR sentinel missing." Run tools/run-phr.sh --verdict PASS --min-score <N> and retry. |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

