跳到正文
cccskills
免费在 GitHub 公开

code-review-and-quality

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".

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(5)

  • SKILL.md5.4 KB
  • references/performance-checklist.md957 B
  • references/review-axes.md2.7 KB
  • references/review-process.md8.6 KB
  • references/security-checklist.md1.1 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Use when adversarially reviewing a document that makes formal or technical claims — math derivations, physics papers, statistical analyses, benchmark reports, whitepapers. Inventories every equation and quantitative claim, verifies each AS NAMED in the text (never a paraphrase or a neighboring statement), and classifies VERIFIED / REFUTED / UNVERIFIABLE / VACUOUS. Triggers on "check this paper", "verify these claims", "is this derivation right", "review this proof", "audit this benchmark", "does the math hold up". For source-code review see code-review-and-quality; for skill/agent library audits see skill-library-review; for content quality scoring see content-ops.

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

Run Karpathy-style autoresearch optimization on any content. Generates 50+ variants, scores with a 5-expert simulated panel, evolves winners through multiple rounds, outputs optimized version + full experiment log. Use when optimizing landing pages, email sequences, ad copy, headlines, form pages, CTA text, or any conversion-focused content. Triggers on "optimize this page", "run autoresearch", "score these variants", "A/B test this copy".

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

Tests in real browsers. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data via Chrome DevTools MCP.

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

Estimate the full development cost of an existing codebase from lines of code, architectural complexity, and team-composition overhead. Use for 'how much would this cost to build', 'what did this codebase cost', development-cost or build-cost estimates, calendar-time estimates, and Claude/AI ROI on a delivered codebase. Estimates by measured LOC and complexity, not by ticket volume.

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

Auto-assembles a domain-specific expert panel (7–10 experts), scores any content or strategy artifact against a typed rubric, and iterates until the aggregate hits 90+ (max 3 rounds). Use as a quality gate on copy, email sequences, landing-page drafts, strategy docs, charts, titles, or recruiting evaluations — or when another skill needs a final review gate on its output. Triggers on "expert panel this", "score this", "rate these variants", "quality check this", "panel review", "expert score", "evaluate this copy/strategy/page". For variant generation and multi-round conversion optimization see autoresearch; for live-URL CRO auditing see conversion-ops; for the scripted content-production pipeline see content-pipeline.

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

Non-interactive content-production toolkit: mine quotable moments from podcast RSS feeds and meeting notes, discover clip-worthy moments in video transcripts, repurpose long-form source into platform-native drafts (X, LinkedIn, YouTube Shorts, newsletter), and batch-score/gate those drafts before publish. Use when asked to "mine quotes from this podcast", "find clips in this video", "repurpose this into a thread / LinkedIn post / Short", "turn this transcript into posts", "extract viral moments", or "gate this batch of drafts". Runs Python scripts end to end. For interactive expert-panel scoring of a single artifact see content-ops.

中文简介正在准备中。当前显示原文说明。

LazyIsEfficient/agentic-os172026年10月20日 更新

查看 LazyIsEfficient 的全部技能

报告此技能的问题