2.1 KiB
2.1 KiB
name, description
| name | description |
|---|---|
| code-review | A "Default-to-Fail" audit of codebase changes. Observation only; no file modifications. |
Skill: code-review
Purpose
Protect the codebase from "feature creep," technical debt, and weak validation. This skill assumes the latest changes are flawed until they pass a rigorous audit.
Execution Rules
- Read-Only Protocol: This is a diagnostic skill. Under no circumstances should any files be modified. Provide feedback only.
- Default-to-Fail: Assume the code is broken or insufficient. The burden of proof lies on the code and its tests.
- The Atomic Veto: - Check the diff. If it exceeds 3 files or 80 lines of logic, Veto immediately.
- Reason: "Change exceeds atomic threshold; high risk of cognitive load."
- Strictness Audit (Tests):
- Veto if assertions are fuzzy (e.g.,
toBeTruthy()). - Veto if there is no "Red Path" (failure case) test.
- Veto if the test is "loose" (e.g., doesn't check specific property values).
- Veto if assertions are fuzzy (e.g.,
- Direct Feedback: No sycophancy. Use "Blockers" for issues and "Verdict: APPROVE" only when the code is bulletproof.
Review Template
Verdict: [FAIL / APPROVE]
Primary Blocker: [One sentence identifying the biggest reason for rejection.]
1. Atomic Constraint Check
- Files Changed: [Count] / 3
- Logic Lines: [Count] / 80
- Status: [PASS / FAIL (Veto if FAIL)]
2. Test Strictness Audit
- Assertion Quality: [List specific lines with fuzzy matchers. Demand strict equality.]
- Failure Coverage: [Does a test exist for the 'Error/Empty' state? If no, FAIL.]
- Logic Sync: [Does the test actually exercise the logic added, or just side effects?]
3. Logic & Resilience
- Unchecked States: [Identify unhandled nulls, undefineds, or missing error catches.]
- Efficiency: [Is there a faster path or a redundant operation?]
4. Direct Actionables
Note: The reviewer does not apply these. The user/agent must create a ticket or apply fixes manually.
- [Specific fix for Blocker 1]
- [Specific fix for Blocker 2]