agentsclimarketplace

Code review and quality

Skill LazyIsEfficient/agentic-os/.claude/skills/code-review-and-quality

Agentic Framework for Modern Development

Install
npx -y skills add LazyIsEfficient/agentic-os --skill code-review-and-quality

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 13 stars13 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

Conducts multi-axis code review across correctness, readability, architecture, security, and performance. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Triggers on "review my PR", "review this diff", "code review", "review this changeset", "is this ready to merge", "pre-merge review".

SKILL.md

5.4 KB, as published. Nobody here has run it

Code Review and Quality

Overview

Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.

The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it.

Universal Rules

  1. Review every change before merge. No exceptions. "It's small" is not an exemption.
  2. Review tests first. Tests reveal intent and coverage before you read a line of implementation.
  3. Label every finding. Use Critical / Nit / Optional / FYI prefixes so the author knows what's required.
  4. Approve improvements, not perfection. If the change improves overall code health, approve it.
  5. Don't rubber-stamp. "LGTM" without evidence of review helps no one. Quantify problems when possible.
  6. Split large changes. Ask the author to split anything over ~300 lines rather than reviewing one massive changeset.
  7. Require cleanup before merge. Don't accept "I'll fix it later" — later never comes.
  8. Treat dependency additions as changes. Every new dependency needs justification: size, maintenance status, license, known vulnerabilities.
  9. Quote before flagging. Every finding must include the specific lines that support it. "This function looks risky" without a quote is an opinion, not a finding. If you can't quote the evidence, you don't have a finding yet.

Red Flags

  • PRs merged without any review
  • Review that only checks if tests pass (ignoring other axes)
  • "LGTM" without evidence of actual review
  • Security-sensitive changes without security-focused review
  • Large PRs that are "too big to review properly" (split them)
  • No regression tests with bug fix PRs
  • Review comments without severity labels
  • Accepting "I'll fix it later"

Verification

After review is complete:

  • All Critical issues are resolved
  • All Important issues are resolved or explicitly deferred with justification
  • Every finding is backed by a specific quoted passage from the actual code
  • No findings were generated from assumed code structure — only from what was read
  • Tests pass
  • Build succeeds
  • The verification story is documented (what changed, how it was verified)

Tier discipline

Tier definitions: review-tiers (.claude/rules/review-tiers.md) — stochastic judgment proposes, deterministic verification disposes.

  • Tier 0: the CI gates themselves (tests, build, linters, validators). These hard-block on their own authority; cite them instead of re-finding what they catch.
  • Tier 1 (may gate, evidence attached): correctness and security findings demonstrated by a failing test, failing command, or concrete counterexample input — the artifact is the gate, the review only chose which artifact to produce. The missing-regression-test blocker is Tier 1: the evidence is the absent test.
  • Tier 2 (advisory, never gates): readability, architecture taste, "could be simpler", unevidenced performance concerns. Severity labels (Critical, blocking) on unevidenced findings are proposals to the operator, not gates — log them to findings-ledger rather than writing blocking language.

References

Related skills

  • skill-library-review — applies the same review discipline to agent and skill definitions rather than source code
  • adversarial-claims-reviewer — applies the same adversarial discipline to formal/technical claims in documents rather than source code
  • findings-ledger — where this skill's Tier 2 (unevidenced) findings get recorded and tallied for recurrence

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.