一键在 Manus 中运行任何 Skill

code-review-quality

星标25

分支3

更新时间2026年6月16日 08:16

Lightweight code-review checklist the agent runs before declaring a patch ready. Catches the obvious classes of issue (dead code, missing error handling, weakened tests) without a full security audit. Adapted from addyosmani's "Review" lifecycle phase.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Kkkirito-123

Kkkirito-123/ZLAgent

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

code-review-quality

Trigger

Activate after writing or editing code and BEFORE running the final verification step. Also activate when the user pastes code and asks for a review, or when the agent wants to gate a skill update.

Principle

Reviews catch what tests cannot see: intent drift, silent regressions, and code that technically works but will break the next editor.

Inputs

changed_files: the files / hunks to review.
purpose: one-line statement of what the change should achieve.
reference: original spec, issue, or plan the change maps to.

Steps

Intent check — does each edit map back to a line in purpose? Flag hunks that drift.
Scope creep — unrelated renames / formatting mixed into a focused fix? Split if non-trivial.
Error handling — new call sites to I/O / HTTP / subprocess have explicit error paths (not just except Exception: pass)?
Tests — did any existing assertion weaken (broader tolerance, deleted edge case)? Restore or justify.
Invariants — was a class invariant (e.g. "every tool row has a permission tier") maintained?
Dead paths — code added that is never reachable from the feature's entry point? Drop.
Logging / observability — significant state change logged? On the happy path only, or also on failure?
Names — any new symbol that will be misleading in 3 months? Rename if yes, keep if no.
Non-goal check — the change should NOT accidentally handle something out of scope (e.g. a skill refactor that changes memory policy).

Output Format

Grade each finding as:

🟥 must-fix: blocks merge.
🟧 should-fix: merge allowed but tracked.
🟩 nit: optional polish.

### code-review-quality findings

- 🟥 _<file>:<line>_  <one-line issue>  — _why it matters_
- 🟧 ...
- 🟩 ...

(零 must-fix 时写 "✅ no blocking issues found")

Verification

Every finding cites <file>:<line>.
Must-fix items are addressed before declaring done.
No finding is vague ("looks weird") — each has a concrete trigger.

Failure Signals

0 findings on a 300-line diff: review was rubber-stamped.
"nit" storm with no must-fix on a patch that later breaks: the gradient is wrong — recalibrate severity thresholds.
The same class of issue appears repeatedly across reviews: promote it to a guardrail (skill, hook, or lint rule).

同仓库更多 Skills

同仓库

arxiv

Kkkirito-123/ZLAgent

Fetch and summarise recent papers from arxiv.org. Use this skill when the user wants a digest of today's or this week's cs.AI / cs.LG / cs.CL listings, a focused per-topic roundup, or a quick look at a specific submission.

2026-06-1625

systematic-debugging

Kkkirito-123/ZLAgent

Root-cause-first debugging loop for code or runtime errors: understand the failure before proposing a fix. Adapted from Hermes' systematic- debugging — same iron law, smaller surface, ZLAgent-tool-aware.

2026-06-1625

verification-before-completion

Kkkirito-123/ZLAgent

Do not declare a task done without running verification. For code, that means running tests / smoke; for answers, that means checking the claim against a fresh source. Adapted from obra/superpowers and addyosmani's "Verify" lifecycle phase.

2026-06-1625

document-processing

Kkkirito-123/ZLAgent

Umbrella skill for user document workflows — PDF, Word, Excel, PowerPoint, text extraction, summarization. Dispatches to the right MCP / tool; proposes an install via mcp-discovery when no local capability fits. Adapted from Anthropic's docx/pdf/xlsx/pptx skills.

2026-06-1625

mcp-discovery

Kkkirito-123/ZLAgent

When the user wants something the agent doesn't have a tool for yet (travel planning, GitHub issues, Linear, weather, filesystem, ...), search the live MCP ecosystem for an existing server, propose installing it, and on confirm wire it up via mcp_manage. Adapted from Hermes' mcporter skill — same flow, ZLAgent-tool-aware.

2026-06-1625

auto-updater

Kkkirito-123/ZLAgent

定期检查 ZLAgent 的 skill、MCP 工具、记忆摘要的变化，生成一份变更摘要并通过 IM 发送给用户。

2026-06-1625

name	code-review-quality
description	Lightweight code-review checklist the agent runs before declaring a patch ready. Catches the obvious classes of issue (dead code, missing error handling, weakened tests) without a full security audit. Adapted from addyosmani's "Review" lifecycle phase.
version	0.1.0
tags	["coding","quality","review"]
metadata	{"hermes":{"created_by":"user"},"zlagent":{"category":"coding","triggers":["review 一下","检查一下代码","代码有没有问题","code review","look for issues"],"capabilities":["read_file","code_execution"],"related_skills":["verification-before-completion","systematic-debugging","documentation-and-decisions"]}}

code-review-quality

Trigger

Activate after writing or editing code and BEFORE running the final verification step. Also activate when the user pastes code and asks for a review, or when the agent wants to gate a skill update.

Principle

Reviews catch what tests cannot see: intent drift, silent regressions, and code that technically works but will break the next editor.

Inputs

changed_files: the files / hunks to review.
purpose: one-line statement of what the change should achieve.
reference: original spec, issue, or plan the change maps to.

Steps

Intent check — does each edit map back to a line in purpose? Flag hunks that drift.
Scope creep — unrelated renames / formatting mixed into a focused fix? Split if non-trivial.
Error handling — new call sites to I/O / HTTP / subprocess have explicit error paths (not just except Exception: pass)?
Tests — did any existing assertion weaken (broader tolerance, deleted edge case)? Restore or justify.
Invariants — was a class invariant (e.g. "every tool row has a permission tier") maintained?
Dead paths — code added that is never reachable from the feature's entry point? Drop.
Logging / observability — significant state change logged? On the happy path only, or also on failure?
Names — any new symbol that will be misleading in 3 months? Rename if yes, keep if no.
Non-goal check — the change should NOT accidentally handle something out of scope (e.g. a skill refactor that changes memory policy).

Output Format

Grade each finding as:

🟥 must-fix: blocks merge.
🟧 should-fix: merge allowed but tracked.
🟩 nit: optional polish.

### code-review-quality findings

- 🟥 _<file>:<line>_  <one-line issue>  — _why it matters_
- 🟧 ...
- 🟩 ...

(零 must-fix 时写 "✅ no blocking issues found")

Verification

Every finding cites <file>:<line>.
Must-fix items are addressed before declaring done.
No finding is vague ("looks weird") — each has a concrete trigger.

Failure Signals

0 findings on a 300-line diff: review was rubber-stamped.
"nit" storm with no must-fix on a patch that later breaks: the gradient is wrong — recalibrate severity thresholds.
The same class of issue appears repeatedly across reviews: promote it to a guardrail (skill, hook, or lint rule).