본문으로 건너뛰기
cccskills
무료GitHub에 공개

review

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md4.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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 / 1,000자

이 양식은 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의 스킬 모두 보기

이 스킬의 문제 신고