Unikit Review

{{engine_name}} Code Reviewer

Analyze {{engine_code_language}} code against the project's coding rules and produce a structured review report.

Language Awareness — BLOCKING PRE-REQUISITE

BEFORE producing ANY output, silently read .unikit/system/LANGUAGE_RULES.md and apply its rules to ALL subsequent output. If the file is missing or unreadable, fall back to English. Do not produce any user-facing output until language rules are loaded. Do not announce, confirm, or mention the language setting.

Step 1: Load rules

Read (they always apply):

• .unikit/ARCHITECTURE.md — module boundaries, dependency rules
• .unikit/ROADMAP.md (if present) — milestone alignment

Read .unikit/memory/RULES_INDEX.md. Load rules:

• RULES.md: ALWAYS read .unikit/RULES.md first (highest priority)
• Core: read the Core table. For EACH row where Required By = all or contains {{self_name}} — read that file from .unikit/memory/core/ using the Read tool. Do NOT skip any matching row. Always re-read at skill start, never rely on prior conversation cache
• Stack: load dynamically when the current task or context matches "Load When" column, or when a need arises during work

Read .unikit/skill-context/{{self_name}}/SKILL.md if it exists — project-level overrides that win over this SKILL.md when conflicting.

Step 2: Route argument and get code

Routing chain

1. Empty → Staged mode
2. Digits / #N / PR URL (e.g. 123, #42, https://github.com/.../pull/123) → PR mode. Extract number from URL if needed
3. Starts with @ → File mode (folder). Strip @, glob <path>/**/*.cs
4. Contains .cs → File mode (explicit files)
5. Other → git rev-parse --verify <arg>:
   • Valid → Commits mode
   • Invalid → AskUserQuestion (staged / cancel / corrected ref)

@ disambiguates folder paths from git refs with /.

Staged mode

1. git diff --cached → if empty, git diff → if empty, inform and stop
2. Extract changed .cs files, read full content for stack rule detection

PR mode

1. gh pr view <N> --json title,body,baseRefName,headRefName,files
2. gh pr diff <N>
3. Extract changed .cs files, read full content for stack rule detection

Commits mode

1. Validate ref via git rev-parse --verify. Invalid → ask user
2. git log --oneline --reverse <ref>..HEAD → if empty, inform and stop
3. If >20 commits → AskUserQuestion (all / last 20 / cancel)
4. git diff --name-only <ref>..HEAD -- '*.cs' → read full content for stack rule detection
5. For each commit: git show <hash> --stat and git show <hash>

File mode

• .cs args: locate via Glob/find. Name without path → search entire project
• @folder args: Glob <folder>/**/*.cs. No results → report error, continue with others
• Read full content of all found files for stack rule detection

Step 3: Load stack rules

Now that target code is available, scan it for framework markers from the Stack section of RULES_INDEX.md. Each entry lists which keywords/types indicate relevance ("Load When" column). Load only matching rule files. If no markers match — skip stack rules entirely.

Step 4: Analyze

Apply all loaded rules (core + stack + project + ARCHITECTURE.md) uniformly, regardless of mode.

For each file or diff hunk, check:

• Rule violations — every loaded rule against the code
• Architecture alignment — boundary/dependency violations (e.g. Modules/ → Game/ forbidden)
• Roadmap linkage — for feat/fix/perf work, missing ROADMAP.md milestone link (suggestion only)
• Removed code (diff modes) — broken contracts, dangling references

Commits mode only — additionally per commit:

• Message accuracy — does the message match the actual changes?
• Atomicity — single logical unit, or mixed concerns?

Severity scale

• 🔴 Critical — must fix (crashes, silent failures, memory leaks, data corruption)
• 🟡 Warning — likely to cause bugs under specific conditions
• 🟠 Medium — performance, code smell, maintainability
• 🟢 Suggestion — quality improvement

Record exact line numbers (or commit hash + file:line for diff modes) and relevant code snippets.

General checklist

Always run these checks in addition to project rules. If a finding from the checklist contradicts a loaded project/core/stack rule or ARCHITECTURE.md (i.e. the code follows project conventions) — suppress the finding, it is not an issue.

Correctness:

• Logic errors or bugs
• Edge cases handling
• Null/undefined checks
• Error handling completeness
• Type safety

Performance:

• Memory leaks
• Inefficient algorithms
• N+1 query problems

Best Practices:

• Code duplication
• Dead code
• Magic numbers/strings
• Proper naming conventions
• SOLID principles
• DRY principle

Testing:

• Test coverage for new code
• Edge cases tested
• Mocking appropriateness

Step 5: Output

All modes use the same report structure. Mode-specific sections are marked below.

## Code Review Summary

<!-- PR mode only: -->
**PR:** #[number] — [title]
**Base:** [baseRefName] ← **Head:** [headRefName]
<!-- Commits mode only: -->
**Range:** `<ref>..HEAD`
**Commits Reviewed:** [count]

**Files Reviewed:** [count]
**Risk Level:** 🟢 Low / 🟡 Medium / 🔴 High
**Stack rules loaded:** [list or "none"]

<!-- Commits mode only: -->
### Per-Commit Notes
#### `<short-hash>` — <commit message>
- **Atomicity:** ✅ Good / ⚠️ Mixed concerns
- **Message accuracy:** ✅ Matches / ⚠️ Misleading
- **Issues:** [findings with severity markers, or "None"]

### Findings

| # | Severity | Location | Rule | Issue | Fix |
|---|----------|----------|------|-------|-----|
| 1 | 🔴/🟡/🟠/🟢 | file:L42 | Rule ref | What's wrong | How to fix |

### Code Fixes

<!-- For 🔴 and 🟡 findings, show: -->
**#1 — [issue title]** (`file:L42`)
​```csharp
// ❌ Current
<problematic code>

// ✅ Fixed
<corrected code>
​```

### Questions
[Ambiguous code or design decisions that need clarification from the author]

### Summary

- **Critical:** [count] | **Warning:** [count] | **Medium:** [count] | **Suggestion:** [count]
- **Top issues:** 3 most impactful to fix first
- **Positive notes:** Good patterns observed

Guidelines

• Be precise: exact line numbers and code references
• Be actionable: every finding includes a concrete fix
• Be complete: check ALL loaded rules
• No false positives: if uncertain, mark "Potential — verify manually"
• Clean code → say so, don't invent issues
• Read-only: do NOT modify any files
• Be constructive: explain "why", acknowledge good code

Examples

/unikit-review — review staged changes /unikit-review PlayerController.cs — review specific file /unikit-review @Assets/Scripts/Player — review folder recursively /unikit-review @Assets/Scripts/Player @Assets/Modules/Wallets — review multiple folders /unikit-review 123 or /unikit-review #42 — review PR by number /unikit-review https://github.com/org/repo/pull/123 — review PR by URL /unikit-review master — review commits vs master /unikit-review v1.0.0 — review commits vs tag /unikit-review feature/day-loop — review commits vs branch

Tip: Context is heavy after review. Consider /clear or /compact before continuing.