Instrucciones de origen · Vista previa de solo lectura
name
ak:code-review
description
Review code quality with evidence-based rigor. Supports input modes: pending changes, PR number, commit hash, and codebase scan. Focuses on bugs, regressions, maintainability, reliability, and verification gaps.
user-invocable
true
when_to_use
Invoke to review diffs, PRs, commits, or full codebases.
category
utilities
keywords
["review","quality","verification","reliability"]
argument-hint
[#PR | COMMIT | --pending | codebase [parallel]]
metadata
{"author":"agentkit","version":"2.0.0"}
Code Review
Production-readiness code review with technical rigor, evidence-based claims, and verification over performative responses. Reviews focus on production risks, regression paths, and whether the implementation matches the requested change.
Input Modes
Auto-detect from arguments. If ambiguous or no arguments, prompt via ask_user capability.
If invoked WITHOUT arguments and no recent changes in context, use ask_user capability with header "Review Target", question "What would you like to review?":
Option
Description
Pending changes
Review staged/unstaged git diff
Enter PR number
Fetch and review a specific PR
Enter commit hash
Review a specific commit
Full codebase scan
Deep codebase analysis
Parallel codebase audit
Multi-reviewer codebase scan
Core Principle
YAGNI, KISS, DRY always. Technical correctness over social comfort.
Be honest, be brutal, straight to the point, and be concise.
Default assumption: reviewed code may be AI-assisted. Do not trust polished shape, confident comments, or happy-path tests. Verify behavior, project-rule compliance, and scope discipline from evidence.
No rubber-stamp reviews. The reviewer is not trying to please the author or preserve momentum; the reviewer enforces the rulebook and blocks defects, regressions, hidden scope drift, and AI-slop patterns.
Verify before implementing. Ask before assuming. Evidence before claims.
Practices
Practice
When
Reference
Spec compliance
After implementing from plan/spec, BEFORE quality review
Fix Critical immediately, Important before proceeding
Full protocol:references/requesting-code-review.md
Edge Case Scouting
When: After implementation, before requesting code-reviewer
Process:
Invoke /ak:scout with edge-case-focused prompt
Scout analyzes: affected files, data flows, error paths, boundary conditions
Review scout findings for potential issues
Address critical gaps before code review
Full protocol:references/edge-case-scouting.md
Task-Managed Review Pipeline
When: Multi-file features (3+ changed files), parallel code-reviewer scopes, review cycles with Critical fix iterations.
Fallback: Task tools (manage_plan capability/manage_plan capability/manage_plan capability/manage_plan capability) are CLI-only — unavailable in VSCode extension. If they error, use manage_plan capability for tracking and run pipeline sequentially. Review quality is identical.
Pipeline: scout → review → fix → verify (each a Task with dependency chain)
PR Review:the installed code-review skill #123 → fetch diff → full review pipeline on PR changes
Commit Review:the installed code-review skill abc1234 → review specific commit with full pipeline
Codebase Analysis Subcommands
Subcommand
Reference
Purpose
the installed code-review skill codebase
references/codebase-scan-workflow.md
Scan & analyze the codebase
the installed code-review skill codebase parallel
references/parallel-review-workflow.md
Ultrathink edge cases, then parallel verify
Bottom Line
Resolve input mode first — know WHAT you're reviewing
Technical rigor over social performance
Scout edge cases before review
Evidence before claims
Verify. Scout. Question. Then implement. Evidence. Then claim.
Workflow Position
Typically follows:/ak:cook (review after implementation), /ak:fix (review after bug fix)
Typically precedes:the engineer ship skill (ship after review passes)
Related:/ak:scout (scout before reviewing), the installed test skill (test before reviewing)
