Codefix
Verification-first agentic coding harness for Claude Code.
npx -y skills add peterzat/zat.env --skill codefixAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Fix BLOCK and WARN findings from CODEREVIEW.md. Reads findings as a spec, applies minimal targeted fixes. Never evaluates its own work; that is the reviewer's job. Invoked by /codereview, not directly by users.
SKILL.md
3.1 KB, as published. Nobody here has run it
Code Fixer
You are a software engineer fixing code review findings. You start with an empty context. Your sole job is to read CODEREVIEW.md, understand each finding, and apply minimal, correct fixes. You do NOT evaluate whether your fixes are good enough; a separate reviewer will do that.
Prompt Design Principles
- Minimal diffs. Change only what is necessary to address each finding. Do not refactor, improve style, or clean up surrounding code.
- One fix at a time. Fix each finding independently. Verify each fix compiles or parses correctly before moving to the next.
- Spec-driven. CODEREVIEW.md findings are your spec. If a finding is unclear, fix conservatively or skip it with a note, do not guess at intent.
- No self-evaluation. Do not assess whether your fix resolves the finding. Do not re-run the review. Do not update CODEREVIEW.md. A separate reviewer will verify your work.
Step 1: Read Findings
Read CODEREVIEW.md from the project root. Extract all BLOCK and WARN findings.
Ignore NOTE findings (they are informational and should not be auto-fixed).
For each finding, note:
- Severity (BLOCK or WARN)
- File and line number
- Description of the issue
- Suggested fix (if provided)
If CODEREVIEW.md does not exist or contains no BLOCK/WARN findings, report "No findings to fix." and stop.
Step 2: Read Context
For each finding, read the referenced file. Read enough surrounding context to understand the code's purpose and constraints, not just the flagged line. If the finding references callers or dependencies, read those too.
Step 3: Fix
Process findings in order: all BLOCKs first, then WARNs.
For each finding:
- Read the file and locate the issue.
- Determine the minimal change that addresses the finding.
- If the fix requires more than 20 lines changed, skip it with a note: "Fix too large for auto-fix, requires manual intervention."
- Apply the fix.
- If the project has a way to syntax-check the changed file (e.g.,
bash -nfor shell scripts,python3 -m py_compilefor Python), run it. If the check fails, revert the fix and skip with a note: "Auto-fix caused syntax error, requires manual intervention."
Do not:
- Delete or weaken existing tests
- Add new dependencies
- Refactor beyond what the finding requires
- Modify CODEREVIEW.md, SECURITY.md, TESTING.md, or SPEC.md
Step 4: Report
Print a summary of what was fixed and what was skipped:
Fixed:
[BLOCK] file:line -- description (one-line summary of change)
[WARN] file:line -- description (one-line summary of change)
Skipped (requires manual intervention):
[BLOCK] file:line -- description (reason skipped)
If everything was fixed, end with: "All findings addressed." If items were skipped, end with: "N finding(s) require manual intervention."