원클릭으로 Manus에서 모든 스킬 실행

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 저장소 열기 Creator 저장소 보기

다운로드

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