mtk-agent-toolkit: Skill for Claude Code

Code Review And Quality

Model tier: the compliance-reviewer agent is pinned to opus (highest stakes); architecture-reviewer, test-reviewer, and silent-failure-hunter to sonnet. See .claude/references/model-routing.md.

Current Diff Context

echo "--- Branch ---"
git branch --show-current 2>/dev/null || echo "(detached)"
echo "--- Tech Stack ---"
cat .claude/tech-stack 2>/dev/null || echo "(not set)"
echo "--- Diff stat ---"
git diff --stat HEAD 2>/dev/null || git diff --stat --cached 2>/dev/null || echo "(no diff)"

Overview

Review changed code as an adversary, not a collaborator. The review must prioritize real risks over style and decide whether the change improves overall code health.

This skill is read-only except for workflow-artifact recording via scripts/workflow-artifact.sh — a deliberate exception to the S2.20 read-only guidance for review skills.

When To Use

• After implementation and verification
• For PR review or merge-safety checks
• When a change touches audited state, auth, data integrity, or infra
• After bug fixes, including review of the regression test

When NOT To Use

• Before the implementation has a coherent behavioral diff or verification story

Workflow

CI Context (if available)

If reviewing a PR or branch with CI runs, check CI status before starting the numbered steps:

1. Run bash hooks/ci-status.sh to get check run results
2. If CI failed, note which checks failed — the review should focus on those areas
3. If CI passed, note any warnings from the build output (.mtk/analyzer-output.json)
4. If hooks/ci-status.sh is not available or gh is not installed, proceed without CI context

Review Steps

1. Load standards:
   • CLAUDE.md
   • The active stack via bash scripts/resolve-tech-stack.sh --check <changed file paths> — polyglot-aware (subproject .claude/tech-stack → root .claude/tech-stack.map glob → root file), and --check warns when the resolved stack disagrees with the files under review, which would otherwise mean reviewing a subtree against the wrong guidelines. Then .claude/skills/tech-stack-{stack}/SKILL.md for stack-specific reference paths
   • The coding guidelines and other reference files listed in the tech stack's ## Reference Files section
   • .claude/references/security-checklist.md
   • .claude/references/testing-patterns.md
   • .claude/references/performance-checklist.md
   • .claude/references/ai-failure-modes.md — the catalogue of researched LLM-specific failure modes (F1–F16). When a finding matches one, cite its F-code in the finding's failure_mode field (see step 5) so failure-mode patterns aggregate across reviews.
   • If a domain supplement exists (e.g. .claude/references/domain-finance.md), load it for domain-specific rationalizations
2. Read the behavioral diff if provided.
3. Review across these axes:
   • correctness — including stub detection per .claude/references/stub-detection.md (empty bodies, NotImplementedException, suspect return null/[]/{}, mock data in production paths, unwired handlers)
   • readability and simplicity
   • architectural fit
   • security and compliance
   • performance and scaling risk
   • test quality and verification strength
4. Route specialized review when needed:
   • compliance-reviewer for security/compliance-sensitive work
   • test-reviewer for coverage and verification quality
   • architecture-reviewer for boundary and slice integrity concerns
   • silent-failure-hunter when the diff touches error handling — dispatch when git diff matches any of \b(catch|except|finally)\b, \.catch\(, \?\?, \|\|, or adds // eslint-disable, # noqa, @ts-ignore, @ts-expect-error, Skip =, it\.skip, xit\(. Run in parallel with compliance-reviewer; merge findings, dedupe by (file, line, rule). The hunter emits category: "error-handling" so dedupe is straightforward.
   • context-miner when the rigor level is HIGH or MAX (per implement Rigor Score). This is the organizational-memory lane: it mines git log / git blame of the touched paths, linked GitHub issues and PR-thread discussions (gh pr list/gh issue list/gh pr view), and prior lessons (scripts/learnings.sh query) for context the implementation may have missed — a prior revert of the same code, a related open issue, a decision recorded in a PR thread, a lesson that applies. Read-only. Dispatch it in parallel with the other Stage 2 reviewers (single message, multiple Agent calls). It emits source: "context" findings per the review-finding schema; merge and dedupe like the others. At LIGHT/STANDARD rigor it is skipped (the diff is small enough that organizational context rarely changes the verdict). 4b. Account for every dispatched lane before reading any findings. Build the roster first — one row per reviewer you dispatched in step 4, with its outcome: PASS, NEEDS_CHANGES, ABSTAINED, or NO_RESPONSE. See Lane Accounting in .claude/references/review-finding-schema.md.