review-intake
starsforks
How to install review-intake?
rune-kit/rune/review-intake
$npx -y skills add Rune-kit/rune --skill review-intakeUse when receiving external input that needs structured intake before action — PR review feedback, code review comments, OR issue tracker items (bug reports, feature requests). PR Review Mode (default) verifies suggestions before implementing. Issue Triage Mode classifies issues
SKILL.md
| 1 | # review-intake |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | The counterpart to `review`. While `review` finds issues in code, `review-intake` handles the response when someone finds issues in YOUR code. Enforces a verification-first discipline: understand fully, verify against codebase reality, then act. Prevents the common failure mode of blindly implementing suggestions that break things or don't apply. |
| 6 | |
| 7 | ## Modes |
| 8 | |
| 9 | | Mode | When | Workflow | |
| 10 | |------|------|----------| |
| 11 | | **PR Review Mode** (default) | Input is PR comments / code review feedback / external suggestions | Phases 1-6 below — absorb, comprehend, verify, evaluate, respond, implement | |
| 12 | | **Issue Triage Mode** | Input is issue tracker item (`gh-42`, URL, pasted issue body), or user says "triage" / "process the inbox" | See `references/issue-triage.md` — state machine (needs-triage → ready-for-agent / ready-for-human / needs-info / wontfix) + repro-first for bugs + AGENT-BRIEF emission | |
| 13 | |
| 14 | Both modes share Phase 4.5 (Rejection KB Write) — `wontfix-enhancement` from Issue Triage and OUT OF SCOPE from PR Review both write `.out-of-scope/<slug>.md`. |
| 15 | |
| 16 | ## Triggers |
| 17 | |
| 18 | - `/rune review-intake` — manual invocation, PR Review Mode by default |
| 19 | - `/rune review-intake <issue-ref>` — Issue Triage Mode (issue number, URL, or path) |
| 20 | - `/rune review-intake --inbox` — Issue Triage Mode batch sweep (unlabeled + needs-triage + needs-info-with-activity) |
| 21 | - Auto-trigger: when `cook` or `fix` receives PR review comments → PR Review Mode |
| 22 | - Auto-trigger: when user pastes review feedback into session → PR Review Mode |
| 23 | - Auto-trigger: when user pastes an issue body or references a ticket → Issue Triage Mode |
| 24 | |
| 25 | ## Calls (outbound) |
| 26 | |
| 27 | - `scout` (L3): verify reviewer claims against actual codebase |
| 28 | - `fix` (L2): apply verified changes |
| 29 | - `test` (L2): add tests for edge cases reviewers found |
| 30 | - `hallucination-guard` (L3): verify suggested APIs/packages exist |
| 31 | - `sentinel` (L2): re-check security if reviewer flagged concerns |
| 32 | |
| 33 | ## Called By (inbound) |
| 34 | |
| 35 | - `cook` (L1): Phase 5 quality gate when external review arrives |
| 36 | - `review` (L2): when self-review surfaces issues to address |
| 37 | |
| 38 | ## Workflow (PR Review Mode) |
| 39 | |
| 40 | For Issue Triage Mode, see [references/issue-triage.md](references/issue-triage.md). Both modes converge at Phase 4.5 for rejection KB writes. |
| 41 | <MUST-READ path="references/issue-triage.md" trigger="when input is an issue tracker item, batch inbox sweep, or user explicitly says 'triage' / 'process the inbox'"/> |
| 42 | |
| 43 | ### Phase 1 — ABSORB |
| 44 | |
| 45 | Read ALL feedback items before reacting. Do not implement anything yet. |
| 46 | |
| 47 | Classify each item: |
| 48 | |
| 49 | | Type | Example | Priority | |
| 50 | |---|---|---| |
| 51 | | BLOCKING | Security vuln, data loss, broken build | P0 — fix now | |
| 52 | | BUG | Logic error, off-by-one, race condition | P1 — fix soon | |
| 53 | | IMPROVEMENT | Better pattern, cleaner API, perf gain | P2 — evaluate | |
| 54 | | STYLE | Naming, formatting, conventions | P3 — quick fix | |
| 55 | | OPINION | "I would do it differently" | P4 — evaluate | |
| 56 | |
| 57 | ### Phase 2 — COMPREHEND |
| 58 | |
| 59 | For each item, restate the technical requirement in your own words. |
| 60 | |
| 61 | <HARD-GATE> |
| 62 | If ANY item is unclear → STOP entirely. |
| 63 | Do not implement clear items while unclear ones remain. |
| 64 | Items may be interconnected — partial understanding = wrong implementation. |
| 65 | |
| 66 | Ask: "I understand items [X]. Need clarification on [Y] before proceeding." |
| 67 | </HARD-GATE> |
| 68 | |
| 69 | ### Phase 3 — VERIFY |
| 70 | |
| 71 | Before implementing ANY suggestion, verify it against the codebase: |
| 72 | |
| 73 | ``` |
| 74 | For each item: |
| 75 | 1. Does the file/function reviewer references actually exist? |
| 76 | 2. Is the reviewer's understanding of current behavior correct? |
| 77 | 3. Will this change break existing tests? |
| 78 | 4. Does it conflict with architectural decisions already made? |
| 79 | 5. If suggesting a package/API — does it actually exist? (hallucination-guard) |
| 80 | ``` |
| 81 | |
| 82 | Use `scout` to check claims. Use `grep` to find actual usage patterns. |
| 83 | |
| 84 | ### Phase 4 — EVALUATE |
| 85 | |
| 86 | For each verified item, decide: |
| 87 | |
| 88 | | Verdict | Action | |
| 89 | |---|---| |
| 90 | | **CORRECT + APPLICABLE** | Queue for implementation | |
| 91 | | **CORRECT + ALREADY DONE** | Reply with evidence | |
| 92 | | **CORRECT + OUT OF SCOPE** | Acknowledge, defer to backlog | |
| 93 | | **INCORRECT** | Push back with technical reasoning | |
| 94 | | **YAGNI** | Check if feature is actually used — if unused, propose removal | |
| 95 | |
| 96 | **YAGNI check:** |
| 97 | ```bash |
| 98 | # Reviewer says "implement this properly" |
| 99 | # First: is |
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
