review
starsforks
How to install review?
rune-kit/rune/review
$npx -y skills add Rune-kit/rune --skill reviewCode quality review — patterns, security, performance, correctness. Finds bugs, suggests improvements, triggers fix for issues found. Escalates to opus for security-critical code.
SKILL.md
| 1 | # review |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Code quality analysis. Review finds bugs, bad patterns, security issues, and untested code. It does NOT fix anything — it reports findings and delegates: bugs go to rune:fix, untested code goes to rune:test, security-critical code goes to rune:sentinel. |
| 6 | |
| 7 | <HARD-GATE> |
| 8 | A review that says "LGTM" or "code looks good" without specific file:line references is NOT a review. |
| 9 | Every review MUST cite at least one specific concern, suggestion, or explicit approval per file changed. |
| 10 | </HARD-GATE> |
| 11 | |
| 12 | ## Triggers |
| 13 | |
| 14 | - Called by `cook` Phase 5 REVIEW — after implementation complete |
| 15 | - Called by `fix` for self-review on complex fixes |
| 16 | - `/rune review` — manual code review |
| 17 | - Auto-trigger: when PR is created or significant code changes committed |
| 18 | |
| 19 | ## Calls (outbound) |
| 20 | |
| 21 | - `scout` (L2): find related code for fuller context during review |
| 22 | - `test` (L2): when untested edge cases found — write tests for them |
| 23 | - `fix` (L2): when bugs found during review — trigger fix |
| 24 | - `sentinel` (L2): when security-critical code detected (auth, input, crypto) |
| 25 | - `docs-seeker` (L3): verify API usage is current and correct |
| 26 | - `hallucination-guard` (L3): verify imports and API calls in reviewed code |
| 27 | - `design` (L2): when UI anti-patterns suggest missing design system — recommend design skill invocation |
| 28 | - `perf` (L2): when performance patterns detected in frontend diff |
| 29 | - `review-intake` (L2): structured intake for complex multi-file reviews |
| 30 | - `sast` (L3): static analysis security scan on reviewed code |
| 31 | - L4 extension packs: domain-specific review patterns when context matches (e.g., @rune/ui for frontend, @rune/security for auth code) |
| 32 | - `neural-memory` | After review complete | Capture code quality insight |
| 33 | - `council` (L3): Step 1.6 — decorrelated bug-finding on the diff when blast radius is 50+ callers with a HIGH-severity change, mode=review |
| 34 | |
| 35 | ## Called By (inbound) |
| 36 | |
| 37 | - `cook` (L1): Phase 5 REVIEW — post-implementation quality check |
| 38 | - `fix` (L2): complex fix requests self-review |
| 39 | - User: `/rune review` direct invocation |
| 40 | - `surgeon` (L2): review refactored code quality |
| 41 | - `rescue` (L1): review refactored code quality |
| 42 | - `design` (L2): review UI/design implementation quality |
| 43 | - `graft` (L2): review grafted code integration |
| 44 | |
| 45 | ## Cross-Hub Connections |
| 46 | |
| 47 | - `review` → `test` — untested edge case found → test writes it |
| 48 | - `review` → `fix` — bug found during review → fix applies correction |
| 49 | - `review` → `scout` — needs more context → scout finds related code |
| 50 | - `review` → `improve-architecture` — when reviewer flag mentions "shallow", "wrapper", "indirection", or pass-through pattern |
| 51 | - `review` ← `fix` — complex fix requests self-review |
| 52 | - `review` → `sentinel` — security-critical code → sentinel deep scan |
| 53 | - `review` → `council` — blast radius 50+ callers with HIGH-severity change → decorrelated bug-finding on the diff |
| 54 | |
| 55 | ## Execution |
| 56 | |
| 57 | ### Step 1: Scope |
| 58 | |
| 59 | Determine what to review. |
| 60 | |
| 61 | - If triggered by a commit or PR: use `Bash` with `git diff main...HEAD` or `git diff HEAD~1` to see exactly what changed |
| 62 | - If triggered by a specific file or feature: use `Read` on each named file |
| 63 | - If context is unclear: use `rune:scout` to identify all files touched by the change |
| 64 | - List every file in scope before proceeding — do not review files outside the stated scope |
| 65 | |
| 66 | ### Step 1.5: Blast Radius Assessment |
| 67 | |
| 68 | For each modified function/class, estimate its blast radius before reviewing. |
| 69 | |
| 70 | ``` |
| 71 | Use Grep to count direct callers/importers of each modified symbol: |
| 72 | blast_radius = count(files importing or calling this symbol) |
| 73 | ``` |
| 74 | |
| 75 | | Blast Radius | Risk | Review Depth | |
| 76 | |-------------|------|-------------| |
| 77 | | 1-5 callers | Low | Standard review | |
| 78 | | 6-20 callers | Medium | Check all callers for compatibility | |
| 79 | | 21-50 callers | High | Thorough review + regression test check | |
| 80 | | 50+ callers | Critical | MUST escalate to adversarial analysis (rune:adversary) even in quick triage | |
| 81 | |
| 82 | <HARD-GATE> |
| 83 | Modifying a symbol with 50+ callers + HIGH severity change (logic, types, behavior) → adversarial analysis REQUIRED. Quick review is NOT sufficient for high-blast-radius changes. |
| 84 | </HARD-GATE> |
| 85 | |
| 86 | ### Step 1.6: Decorrelated Bug-Finding (council, high-blast-radius only) |
| 87 | |
| 88 | review's own pass is one model reading the diff once. For the same 50+ caller / HIGH-severity |
| 89 | symbols that trigger the Step 1.5 HARD-GATE, call `rune:council` (mode=review) on the diff |
| 90 | itself BEFORE writing up Step 2's findings — a second architecture reading the same code |
| 91 | independently catches bugs a single pass rationalizes past. |
| 92 | |
| 93 | This is complementary to (not a replacement for) the existing adversary escalation: coun |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
