Compress review pressure into the right next action instead of more code by default. Classify findings, reject non-liabilities, and choose proof-only vs minimal-fix vs refactor-kernel, preventing one-patch-per-comment churn. Use after a code review — PR comments, reviewer suggestions, or audit findings — and especially when you are about to reflexively patch every comment.
Scanned 9/9/2026
Install to Claude Code
npx -y skills add SDiamante13/dotfiles --skill tw-review-fold --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Tw Review Fold?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sdiamante13-tw-review-fold)More formats (shields.io, HTML) on the badges page.
---
name: tw-review-fold
description: Compress review pressure into the right next action instead of more code by default. Classify findings, reject non-liabilities, and choose proof-only vs minimal-fix vs refactor-kernel, preventing one-patch-per-comment churn. Use after a code review — PR comments, reviewer suggestions, or audit findings — and especially when you are about to reflexively patch every comment.
---
# Review Fold
## Mission
Turn review pressure into the right next action, not more code by default.
```text
review comments + original goal + current diff
-> review fold
-> reject | proof-only | minimal-fix | refactor-kernel | ask-human | follow-up
```
This is a *finding classifier*. It does not perform the review and it does not, by itself, decide that review work stops — it picks the smallest correct response to each finding and exposes when many findings share one root cause.
## Review fold schema
```yaml
review_fold:
source:
pr:
review_backend: pr-comments | review-session | human-review | prior-artifact
intent_anchor:
original_goal:
accepted_scope:
non_goals: []
changed_paths: []
findings:
- id:
claim:
observed_fact:
validity: valid | invalid | unproven | needs-owner
liability: blocks-goal | regression-risk | style | new-requirement | out-of-scope | proof-gap
intent_relation: core | adjacent | unrelated | expands-scope
novelty: duplicate | same-class | new-class
disposition: reject | proof-only | minimal-fix | refactor-kernel | ask-human | follow-up
minimal_response:
proof_needed:
code_change_allowed: yes | no
compression:
equivalence_classes: []
repeated_kernel:
reabstraction_candidate: yes | no
one_patch_per_comment_risk: low | medium | high
action_plan:
mode: classify-only | proof-only | minimal-fix | refactor-kernel | branch-race
work_nodes: []
do_not_fix: []
reviewer_response_draft: []
```
## Disposition law
- `reject`: claim is false, outside accepted scope, already handled, or incompatible with the goal.
- `proof-only`: code is likely correct; run or expose proof instead of editing.
- `minimal-fix`: a valid liability with a single owner-correct local repair.
- `refactor-kernel`: multiple findings share one missing abstraction, boundary, state transition, or proof surface — fix the kernel, not each symptom.
- `ask-human`: the review introduces a product, compatibility, or API decision.
- `follow-up`: valid but not part of the intended change.
## Modes
- `classify-only`: classify findings and stop; no mutation.
- `proof-only`: run checks, inspect current artifacts, or draft a response; no code unless proof fails.
- `minimal-fix`: make the smallest owner-correct change for accepted liabilities.
- `refactor-kernel`: replace many local fixes with one normal-form correction.
- `branch-race`: compare two or more plausible fix/refactor strategies under the same verifier.
## Procedure
1. Bind reviews to the original goal and the current diff.
2. Classify each finding *before* any implementation.
3. Collapse duplicates and same-family comments into equivalence classes.
4. Detect the refactor-kernel: when many comments share one owner boundary, prefer one structural fix over N local patches.
5. Decide each finding's proper response: no-code, proof, local fix, refactor, branch-race, ask, or follow-up.
6. Produce a small work plan only for accepted liabilities.
7. Preserve reviewer-response drafts as drafts; do not post public comments or resolve PR threads unless explicitly asked.
## Guardrails
- Raw review text is not executable — never send findings straight to implementation.
- Do not add code to satisfy style or speculation when proof or rejection is correct.
- Do not accept scope expansion without user authority.
- Do not miss the refactor when many comments share one boundary.
- When a fresh, adversarial, or exhaustive review is what's actually being asked for, run that review first — this skill folds *findings*, it does not replace the review itself.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!