Skip to content
Back to skills

Tw Review Fold

ASecurity

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.

  • 8 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 9, 2026
code-qualitygonoderailsapibackend

Works with

  • api

Security analysis

A100/100

Scanned September 9, 2026

npx -y skills add SDiamante13/dotfiles --skill tw-review-fold --agent claude-code

Installs 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 with every re-scan.

Security grade badge for Tw Review Fold
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/sdiamante13-tw-review-fold/badge)](https://www.skillsdirectory.com/skills/sdiamante13-tw-review-fold)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.