Code review
Skill chipfighter/coding-discipline/plugins/coding-discipline/skills/code-review
Workflow-agnostic guardrails for AI coding agents: spec sync + risk-triggered engineering discipline for Claude Code and Codex.
npx -y skills add chipfighter/coding-discipline --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 6 stars6 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
Use when changes affect interactions across multiple modules, involve high-risk areas (authorization/authentication, payments/funds, data deletion/migration, public APIs/cross-service interfaces/security boundaries), or the user requests a review. Review in this order—correctness → requirements → security → simplicity → style. Verify feedback before acting; do not comply blindly or agree performatively. Unless the user asks, documentation-only changes, explicit config values, and mechanical renames do not trigger merely because of a PR or merge.
SKILL.md
2.9 KB, as published. Nobody here has run it
Performing a review (review it yourself; delegate when worthwhile and supported)
When an independent perspective is needed and the current client supports subagents, you may delegate a review. Give the reviewer carefully scoped context (what changed, which requirements it should meet, and the base..head diff range), not the entire session history. Review small changes yourself; do not add agent overhead for appearances.
Review in this priority order. Do not dwell on a lower priority while a higher one is unresolved:
- Correctness: is the logic sound; are edge cases, errors, or concurrency missing; can it crash?
- Requirements: check each requirement and design point. Does the change do what was requested, and is anything missing?
- Security: injection, unauthorized access, secret leakage, unvalidated input.
- Simplicity: overengineering, duplication, removable dead code, features that are not needed yet.
- Style: naming, consistency, readability—review these last, not first.
Use severity: fix blockers (crashes/security) immediately, fix important issues before proceeding, and note minor issues for later.
Receiving review feedback
- Verify before changing anything: does this feedback apply to this codebase? Could it break existing behavior? Is there a reason the code is written this way? If uncertain, say, "I cannot verify X. Should I investigate, ask, or leave it for now?"
- Do not comply blindly: if a suggestion is wrong, lacks context, asks for something not needed yet, or conflicts with an established architecture decision, push back with technical reasons rather than changing it because a reviewer said so. Stop and consult someone when the conflict concerns architecture.
- No performative agreement: do not say "You're right!", "Good suggestion!", or "Thanks for catching that!" If you make the change, state what changed and where. If your pushback was wrong, say only, "I checked and I was wrong because X; I changed it." Do not write a long apology.
- If anything is unclear, clarify every item before making changes. Do not act only on the items you understand; review items are often related, and partial understanding leads to wrong changes.
- Address one item at a time, test each change, and confirm that it introduced no regressions (see verify-before-done).