brutal-pr-finding-fixer
Skill2 starsChanged 4 months agoMITView on GitHub
Fix generated pull-request finding occurrences through the BRUTAL.md code-host adapter, one focused change at a time, with complete queue scans for material-convergence passes.
In this repository25 other files it gives its agents.
- brutal-deepresearchSkill
- brutal-grillSkill
- brutal-idea-evalSkill
- brutal-inf-fix-loopSkill
- brutal-planSkill
- brutal-pr-fix-loopSkill
- brutal-project-reviewSkill
- brutal-pr-reviewSkill
- brutal-realitySkill
- brutal-reviewSkill
- brutal-specSkill
- brutal-swarmSkill
- brutal-ticketsSkill
- brutal-wayfinderSkill
- brutal-workerSkill
- codex-coopSkill
- design-jepa-modelsSkill
- factory-designSkill
- funcvec-dedupe-fixerSkill
- grill-meSkill
- handoffSkill
- opencode-delegateSkill
- rust-architecture-reviewSkill
- rust-pr-reviewSkill
- supply-chain-analyzerSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Read full conversation comments, review comments, and thread state before selecting work.
- Distinctive: line 22
Treat the code host as queue truth.
- Distinctive: line 25
Add or update a focused failing test when practical.
- Distinctive: line 28
Stop on verification failure, push rejection, stale/ambiguous PR identity, incomplete thread state, changed base identity, or inherited …
- Distinctive: line 56
Run focused verification and required checks.
≈ “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
Brutal PR Finding Fixer
Drain generated provider findings, not work-store issues.
Required Context
- Read
../brutal-shared/integration-resolver.md,../brutal-shared/support/contracts.md, and the selected code-host module. - Reuse a managed fix phase’s validated integrations, exact pull request,
review id, and base/head snapshot. Otherwise resolve the same open pull
request used by
brutal-pr-review. - Read full conversation comments, review comments, and thread state before selecting work. A cached count is not proof that the queue is drained.
Hard Rules
- Treat the code host as queue truth. Do not update the work store.
- Require a clean worktree unless compatible existing changes were explicitly allowed. Process one occurrence at a time.
- Add or update a focused failing test when practical.
- Make one focused commit per code-changing occurrence, push normally, and record its disposition. Never force-push.
- Stop on verification failure, push rejection, stale/ambiguous PR identity, incomplete thread state, changed base identity, or inherited safety guards.
- Mark invalid, stale, or already-fixed occurrences skipped without a commit.
Queue Identity
Select owned finding comments beginning with:
<!-- brutal-pr-review:v2:<fingerprint> -->
<!-- brutal-pr-review-occurrence:<review_id>:<reviewed_head_sha> -->Reject summaries, quoted markers, and disposition replies. The queue identity
is (fingerprint, review_id). A later occurrence for the same fingerprint is
new work. An occurrence is handled only when a provider comment starts with:
<!-- brutal-pr-finding-fixer:v2:<fingerprint>:<review_id> -->Recognize legacy generated/handled markers for compatibility. Sort unhandled occurrences CRITICAL, MAJOR, MINOR, NIT. In a material-convergence fix phase, scan and drain the full all-severity queue; do not stop after the material subset or after a cached count reaches zero.
Workflow
- Snapshot PR identity, base/head, fork state, checks, comments, and threads.
- Select and revalidate the next unhandled occurrence against the current implementation.
- Implement the smallest correct fix and focused test.
- Run focused verification and required checks.
- Inspect, commit, push, and re-read the PR head.
- Reply inline or post a top-level disposition beginning with the handled marker and recording source, reviewed/current heads, commit, verification, and concise notes.
- Re-read the complete queue and repeat until no unhandled occurrence for the review remains or a hard guard stops.
In managed mode, perform only the fix phase for the supplied review queue.
Exit without running the next review. Same-thread resume is only for an
interrupted fix attempt.
Redirect verbose test, diff, and provider output to run-local temporary logs. Return status and duration; on failure include no more than the last 200 lines or 16 KiB, whichever is smaller.
Final Response
Report provider, pull request, reviewed and final snapshots, occurrence totals and actions by severity, commits/pushes, verification, dispositions, a fresh remaining-queue scan, and any blocker.
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.

