Code Review Skill
Orchestrate a comprehensive code review using three specialist agents in parallel, then synthesize their findings.
Inputs
This Skill reads $ARGUMENTS. Accept these patterns:
- A file path, directory path, or glob pattern to review
- A PR number (e.g.,
#42 or 42)
--diff to review staged/unstaged git changes- No arguments defaults to reviewing uncommitted changes (
git diff)
If the user didn't supply arguments, ask what they want reviewed.
Step-by-step procedure
Step 1: Determine review scope
Identify what code to review:
- PR: Run
git diff <base>...<head> to get changed files
- Files/directories: Use the provided paths
- Staged changes: Run
git diff --cached
- Uncommitted changes: Run
git diff
Collect the list of changed/target files and their contents.
Step 2: Delegate to three agents in parallel
Launch all three agents simultaneously using the Task tool:
code reviewer (tactical)
- Pattern compliance, linting, best practices
- Prompt: Provide the file paths and ask it to review against Cognee patterns, run linters, and return structured findings
solution architect (strategic)
- Architectural concerns, design coherence
- Prompt: Provide the file paths and ask it to evaluate architectural consistency, separation of concerns, and design coherence
go software architect (Go-specific)
- Go coding conventions, naming conventions, implementation conventions
- Prompt: Provide the Go file paths and ask it to check for idiomatic Go (stuttering, interface design, error wrapping, context propagation, package structure, naming)
Step 3: Synthesize findings
When all three agents return:
- Identify agreements — Issues flagged by multiple agents
- Identify unique findings — Issues only one agent caught
- Identify disagreements — Conflicting recommendations
Step 4: Reconcile disagreements
If disagreements exist:
- Present the conflicting views back to each disagreeing agent
- Ask each to provide reasoning
- Request they reach consensus
- If no consensus, present both perspectives to the user
Step 5: Compile unified findings
IMPORTANT: Read the template at skills/code-review/templates/code-review-template.md BEFORE delegating. When delegating to the documentation agent:
- Provide the template path so the agent reads it and follows its section order exactly
- Provide a prior review from
docs/code-reviews/ as a style reference (e.g., the most recent one)
- Provide the review content only (findings, metadata, compliance checks) — do NOT dictate document structure in the prompt
- The agent must use the template's sections, not invent its own
Create a new file under docs/code-reviews/ named for the scope, for example docs/code-reviews/phase-09-routing-engine.md. Keep the template section order intact.
If you must show a summary to the user, include only a short synopsis plus a linkable file reference to the completed review document.
Step 6: Collaborate with user on resolution
- Discuss trade-offs for architectural decisions
- Get user approval before delegating fixes
- Do NOT auto-fix without user consent
Step 7: Delegate approved fixes
After user approves specific fixes, delegate to appropriate specialists:
- Go issues →
go-software-agent
- Shell issues →
shell-script-agent
- DevOps issues →
go-devops-agent
- Documentation →
documentation-agent
Key principles
- Three perspectives: tactical (code-review) + Go-specific (go-architect) + strategic (solution-architect)
- Agents reconcile disagreements BEFORE presenting to user
- User is involved in resolution decisions, not just notified
- Documentation updated to capture learnings from review
- Pattern compliance checked against Cognee knowledge base
Finding categories
- Pattern Violation: Deviates from documented Cognee pattern
- Go Idiom: Non-idiomatic Go (stuttering, interface placement, error handling)
- Architecture: Structural or design concern
- Security: Potential security issue
- Error Handling: Missing or inadequate error handling
- Testing: Missing tests or edge cases
- Performance: Inefficient implementation
- Style: Naming, formatting, organization issues
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: code-review-2973description: Orchestrates a 3-agent parallel code review combining pattern compliance, Go conventions, and architectural analysis. Use when this capability is needed.4---56# Code Review Skill78Orchestrate a comprehensive code review using three specialist agents in parallel, then synthesize their findings.910## Inputs1112This Skill reads `$ARGUMENTS`. Accept these patterns:1314- A file path, directory path, or glob pattern to review15- A PR number (e.g., `#42` or `42`)16- `--diff` to review staged/unstaged git changes17- No arguments defaults to reviewing uncommitted changes (`git diff`)1819If the user didn't supply arguments, ask what they want reviewed.2021## Step-by-step procedure2223### Step 1: Determine review scope2425Identify what code to review:2627- **PR**: Run `git diff <base>...<head>` to get changed files28- **Files/directories**: Use the provided paths29- **Staged changes**: Run `git diff --cached`30- **Uncommitted changes**: Run `git diff`3132Collect the list of changed/target files and their contents.3334### Step 2: Delegate to three agents in parallel3536Launch all three agents simultaneously using the Task tool:37381. **`code reviewer`** (tactical)39 - Pattern compliance, linting, best practices40 - Prompt: Provide the file paths and ask it to review against Cognee patterns, run linters, and return structured findings41422. **`solution architect`** (strategic)43 - Architectural concerns, design coherence44 - Prompt: Provide the file paths and ask it to evaluate architectural consistency, separation of concerns, and design coherence45463. **`go software architect`** (Go-specific)47 - Go coding conventions, naming conventions, implementation conventions48 - Prompt: Provide the Go file paths and ask it to check for idiomatic Go (stuttering, interface design, error wrapping, context propagation, package structure, naming)4950### Step 3: Synthesize findings5152When all three agents return:53541. **Identify agreements** — Issues flagged by multiple agents552. **Identify unique findings** — Issues only one agent caught563. **Identify disagreements** — Conflicting recommendations5758### Step 4: Reconcile disagreements5960If disagreements exist:61621. Present the conflicting views back to each disagreeing agent632. Ask each to provide reasoning643. Request they reach consensus654. If no consensus, present both perspectives to the user6667### Step 5: Compile unified findings6869**IMPORTANT**: Read the template at `skills/code-review/templates/code-review-template.md` BEFORE delegating. When delegating to the documentation agent:70711. Provide the **template path** so the agent reads it and follows its section order exactly722. Provide a **prior review** from `docs/code-reviews/` as a style reference (e.g., the most recent one)733. Provide the **review content** only (findings, metadata, compliance checks) — do NOT dictate document structure in the prompt744. The agent must use the template's sections, not invent its own7576Create a new file under `docs/code-reviews/` named for the scope, for example `docs/code-reviews/phase-09-routing-engine.md`. Keep the template section order intact.7778If you must show a summary to the user, include only a short synopsis plus a linkable file reference to the completed review document.7980### Step 6: Collaborate with user on resolution8182- Discuss trade-offs for architectural decisions83- Get user approval before delegating fixes84- Do NOT auto-fix without user consent8586### Step 7: Delegate approved fixes8788After user approves specific fixes, delegate to appropriate specialists:8990- Go issues → `go-software-agent`91- Shell issues → `shell-script-agent`92- DevOps issues → `go-devops-agent`93- Documentation → `documentation-agent`9495## Key principles9697- Three perspectives: tactical (code-review) + Go-specific (go-architect) + strategic (solution-architect)98- Agents reconcile disagreements BEFORE presenting to user99- User is involved in resolution decisions, not just notified100- Documentation updated to capture learnings from review101- Pattern compliance checked against Cognee knowledge base102103## Finding categories104105- **Pattern Violation**: Deviates from documented Cognee pattern106- **Go Idiom**: Non-idiomatic Go (stuttering, interface placement, error handling)107- **Architecture**: Structural or design concern108- **Security**: Potential security issue109- **Error Handling**: Missing or inadequate error handling110- **Testing**: Missing tests or edge cases111- **Performance**: Inefficient implementation112- **Style**: Naming, formatting, organization issues113114---115> Converted and distributed by [TomeVault](https://tomevault.io/claim/twistingmercury) — claim your Tome and manage your conversions.116<!-- tomevault:4.0:skill_md:2026-04-14 -->
tomevault-io