SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstk-code-review

tk-code-review

Testing & quality

View repository

Updated 10-15 21:37

About this skill

Code review

Use it when the user requests an independent review of changes after a branch, PR, or specific commit, compliance with a spec, or implementation results, or when the current changes need a review separate from modifications. Do not use it for code modifications, diagnosis of defects of unknown cause, or requests for a full architecture redesign.

Contract

Do not edit code or automatically re-review; instead, fixed point 확정 → diff 규모 분류 → 전체 diff bounded inspection → Standards 근거 확인 → Spec 근거 확인 → 축별 finding → verdict follow the order. If you cannot access the fixed point, the diff, or the required evidence, Unverifiable, and if you cannot proceed because there is no user decision or authority, Blocked, and if there is an actual violation, Changes requested.

Every finding requires severity, title, file:line evidence, basis, and impact. Do not report the entire review as passing after reading only some files or axes. PassUse it only when the entire fixed diff and all applicable axes have been inspected and there is no unverified scope.

Workflow

  1. fixed point: The input is the user's review scope and repository ref, and the output is the verified base commit and review-head commit.
  2. diff inventory: The input is the base commit and review-head, and the output is the changed files, change volume, scope log, small | large | size_unknown classification, and inspection path.
  3. standards evidence: The input is the result of checking all files and hunks along the selected path and the repository guidelines, and the output is the applicable Standards basis, conditional high-risk signals, and per-axis findings.
  4. spec evidence: The input is the result of checking all files and hunks along the selected path and the spec/ticket sources according to priority, and the output is the status, omissions, and violation findings for each applicable Spec ID, or spec 없음 determination.
  5. axis verdict: The input is the Standards and Spec results, and the output is a per-status verdict that does not merge the two axes.
  6. receipt: The input is the fixed point, inspection scope, findings, and unverified items, and the output is the Fixed point / Standards / Spec / Verdict report.

If the ref does not resolve, the diff is empty, or the diff or the entire applicable Standards source cannot be read, stop with Unverifiable. If a base point decision or authority is needed, it is Blocked, and if the Spec source itself is absent, omit only the Spec axis as spec 없음, but do not state that the axis passed.

🔴 CHECKPOINT · 🛑 STOP review start boundary

Do not write findings or verdicts before confirming the fixed point, diff inventory, full diff coverage of the selected path, and applicable Standards/Spec basis. If you cannot access the fixed point or diff, or if the user needs a base point or decision, Unverifiable or Blocked stop the review at the receipt.

Fixed point

Before reviewing, confirm the commit, branch, tag, main, merge-base expression, or HEAD~N form of fixed point. If the user did not provide a base point, ask.

git rev-parse <fixed-point>
git rev-parse HEAD
git diff --stat <fixed-point>...<review-head>
git diff --numstat <fixed-point>...<review-head>
git log <fixed-point>..<review-head> --oneline

Before the Diff body, --numstatCheck the number of rows and the sum of additions+deletions. If the changed files exceed 15 or the sum exceeds 800 lines, large, if the sum cannot be trusted due to binary, rename, etc., or the inventory is incomplete, size_unknown. For those confirmed to be at or below both thresholds, small only the diff can be read directly as a raw full diff in the current agent context.

large | size_unknown, do not output the raw full diff directly into the current agent context. Use the available context-indexed/execute-and-summarize non-agent tools, redirect to a temporary file and then do targeted/paged reads per file and hunk, or use the bounded axis reviewer below. In any path, track the full changed-file and hunk coverage and the remaining scope, and if there is unverified scope, Pass instead of Unverifiable leave a receipt.

At the start of the review, HEAD pin the SHA as review-head and check it again right before the verdict. If the review-head has changed, do not merge the line evidence or findings of the previous diff with the new state or finalize as Pass, and record the previous and current SHA and the stale scope in the Blocked | Unverifiable receipt. The review of the new scope does not start automatically.

Evidence

Spec source priority:

  1. User-provided spec or ticket
  2. Issue reference in commit/branch
  3. Related .tigerkit/spec.md
  4. Related .tigerkit/tickets.md
  5. Repository documentation
  6. No spec

If there is no spec, omit the Spec axis and state so.

Standards source는 AGENTS.md, CLAUDE.md, CONTRIBUTING.md, repository coding standards, related module guidelines, and rules not checked by the formatter/linter/typechecker.

Review 축

Distinguish Standards from Spec and do not merge them into a single ranking.

In Standards, based on the current diff, check for repository rule violations, duplication, scope creep, ownership confusion, shotgun-style changes, unnecessary pass-through, leakage of the boundary between public interface and implementation, public seams that are hard to test, concentration of different reasons for change, side-effect/error boundaries, and speculative abstraction. Do not propose a full rewrite or architecture outside the requested scope.

Only when the diff changes authentication, authorization, privacy, payments, dependencies, migration, data loss, concurrency, or public API, high-risk reviewselect the corresponding lane in. If there is no signal, do not load references or create a full N/A checklist; just record the reason for omission in the receipt. This is not a repository-wide vulnerability scan or a full compliance determination.

In Spec, check for missing or partial implementation, unrequested behavior, unmet acceptance criteria, incorrectly implemented behavior, missing tests/verification, and out-of-scope changes. If the source has requirement/acceptance IDs, judge each ID as implemented | missing | partial | unverified | not-applicableand link file:line evidence. If even one is missing | partial | unverified, do not mark the entire Spec axis as Pass. If the source has no IDs, do not create them arbitrarily.

Sequential review by the current agent is the default. Only when the value of context isolation is clear in a large diff may you use 1 Standards reviewer and 1 Spec reviewer, up to a maximum of 2. Reviewers do not redelegate, edit code, fan out along the same axis, or automatically re-review. If there is no Spec, do not create a Spec reviewer.

Findings and output

Format for each finding:

Severity: Critical | Important | Minor
Title
Evidence: file:line
Basis: 저장소 규칙 또는 spec 근거
Impact

If there are no findings, state that there are none on that axis. Output:

## Fixed point
## Standards
## Spec
## Verdict

Verdict는 Pass | Changes requested | Blocked | Unverifiable is one of the following. Leave a receipt with the axis and scope performed, key evidence, unverified items, and verdict.

DO NOT / ANTI-PATTERNS

  • Do not estimate the baseline or pass an empty diff or partial diff as a full review.
  • large | size_unknown Do not put the raw full output of the diff directly into the current agent context.
  • Do not directly modify the code under review or automatically re-review it.
  • Do not add unfounded architecture rewrites and out-of-scope changes as findings.
  • Do not run the full security checklist without a high-risk signal or present a limited diff review as a repository-wide audit.