跳到正文
cccskills
免费在 GitHub 公开

review

Three-phase code review. Investigates internally, verifies findings, then reports only confirmed issues.

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

查看安装方法

包含的文件(1)

  • SKILL.md4.5 KB

SKILL.md(原文)

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

Code Review

Review code changes in three phases:

  1. Investigate the change and find candidate issues.
  2. Verify each finding against actual source and dismiss false positives.
  3. Generate a report of confirmed issues.

Step 1: Investigate (internal — do NOT include in output)

Input: The context for the diff provided in $ARGUMENTS.

Process:

  1. Run /diff $ARGUMENTS to get the diff report.
  2. Infer what changed, why it changed, the impact, and the risks.
  3. Use Read to examine the surrounding code of each changed file—reviewing a diff without context leads to short-sighted findings.
  4. Use Grep or Glob to check for cross-file impacts or project rule violations.

Note on Autonomy: The areas below are a non-exhaustive starting point. Use your full reasoning to identify any architectural, logical, or stylistic flaws not explicitly listed.

Note on External Comments: PR comments from other agents or reviewers (Gemini, Copilot, etc.) break idempotency — the same diff reviewed with different comments produces different results. Minimize their influence: treat them as optional leads to investigate, not as findings. Do not adopt their severity or framing. Evaluate each concern from scratch using your own analysis in Steps 1-2, and assign severity independently in Step 3. If a comment doesn't survive your own verification, drop it silently.

Areas to check: code quality, bugs, performance, security, test coverage, integration, non-determinism, project conventions.

Output (Internal): A list of Candidate Findings (file, line, concern).

Step 2: Verify (internal — do NOT include in output)

Input: The Candidate Findings list from Step 1.

Process:

  1. MANDATORY: For every finding, you MUST use the Read tool to verify it against the full file in the specific branch/commit. Diffs omit context, so never infer errors (e.g., deleted blocks, missing imports) solely from a diff snippet.
  2. For complex or independent concerns, spawn a sub-agent (using Agent) to verify the logic holds.
  3. Filter out false positives (e.g., missing handling that actually exists in a caller or middleware not shown in the diff).

Output (Internal): - Confirmed Issues: Verified bugs or improvements with concrete fix instructions.

  • Needs Verification: Suspicions that cannot be ruled out but lack definitive proof.
  • Coverage Gaps: List of any files/paths that couldn't be fully reviewed due to context limits.

Step 3: Report (this is your output)

Input: The Confirmed Issues, Needs Verification, and Coverage Gaps from Step 2.

Reporting Principles:

  • Be Constructive & Concrete: Every issue must include a specific fix.
  • No Self-Contradiction: Never report a concern and then dismiss it in the same breath.
  • Be Idempotent: Avoid subjective style preferences. If no issues were found, say so—do not invent marginal suggestions to fill space.
  • Independent Assessment: When PR comments from other agents or reviewers exist in the context, treat them as leads to investigate — not as authoritative findings. Determine severity from your own analysis. Never inherit another reviewer's severity classification; if you investigate their concern and find it invalid, drop it silently (like if it was dismissed in Step 2). If valid, assign your own severity.

Output format

🏷️ Verdict: ✅ LGTM [size], ⚠️ Needs work [size], or ❌ Do not merge [size] on the first line, followed by a 1-2 sentence summary of the verdict.

✂️ Split suggestion: (Only if beneficial) List 2-4 concrete PRs to split the change into smaller pieces. Skip if cohesive.

📋 Report: Omit any section entirely if it has no items. If coverage was incomplete, note it here.

🔴 Criticals: Bugs, logic errors, security vulnerabilities, auth bypass, race conditions. 🟠 Warnings: Missing error handling, incomplete validation, missing tests, performance issues. 🟡 Suggestions: Naming, structural simplifications, better patterns available. 🟣 Needs verification: State what's suspicious, what you checked, and what the author should verify. 🔵 Existing issues: Surrounding technical debt NOT introduced by this diff (one line each). 🟢 Checks passed: A short bullet list of areas investigated that had no issues.

评价

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

评论

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

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

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

0 / 1000 字

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

同一仓库的技能

amend

免费

Amend the last commit with current changes and/or an updated message.

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

simonepri/ifttt-lint292026年9月29日 更新

commit

免费

Stage changes and create a commit with a conventional commit message.

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

simonepri/ifttt-lint292026年9月29日 更新

cook

免费

Full autopilot — plan, implement, and polish a task end-to-end.

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

simonepri/ifttt-lint292026年9月29日 更新

diff

免费

Fetch and display diffs for various scopes (PR, commit, branch, staged, working tree). Used by other skills that need to analyze changes.

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

simonepri/ifttt-lint292026年9月29日 更新

execute

免费

Execute a plan file — parse phases, spawn parallel subagents, handle failures.

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

simonepri/ifttt-lint292026年9月29日 更新

fork

免费

Start or end a forked session for exploring rabbit holes without losing the main conversation's context.

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

simonepri/ifttt-lint292026年9月29日 更新

查看 simonepri 的全部技能

报告此技能的问题