reviewing-code
installsforks
How to install reviewing-code?
alexei-led/cc-thingz/reviewing-code
$npx -y skills add alexei-led/cc-thingz --skill reviewing-codeTrack phases with TaskCreate and TaskUpdate when available:
SKILL.md
| 1 | # Code Review |
| 2 | |
| 3 | ## Platform workflow additions |
| 4 | |
| 5 | Track phases with `TaskCreate` and `TaskUpdate` when available: |
| 6 | |
| 7 | 1. Scope resolved. |
| 8 | 2. References loaded. |
| 9 | 3. Evidence gathered. |
| 10 | 4. Findings consolidated. |
| 11 | 5. Report emitted. |
| 12 | |
| 13 | ## Arguments |
| 14 | |
| 15 | If `$ARGUMENTS` is passed, interpret these keywords: |
| 16 | |
| 17 | - `quick`: changed lines plus direct context; security and correctness only. |
| 18 | - `deep`: all dimensions from the host skill. |
| 19 | - `team`: parallel reviewer sub-tasks, then one consolidated report. |
| 20 | - `external`: second-model or external-AI review; only when explicitly requested. |
| 21 | |
| 22 | Default is standard. Never run `external` implicitly. |
| 23 | |
| 24 | ## Scope prompt |
| 25 | |
| 26 | When scope is missing, use `AskUserQuestion` with header `Review scope` and these options: |
| 27 | |
| 28 | - Uncommitted changes. |
| 29 | - Branch compared to default branch. |
| 30 | - Specific files or PR diff supplied by the user. |
| 31 | |
| 32 | ## Team mode |
| 33 | |
| 34 | Run sub-tasks as the read-only `reviewer` role. Split by review dimension or file group. Each sub-task must use the host skill's severity rubric and return only evidence-backed findings. |
| 35 | |
| 36 | Consolidate before reporting: |
| 37 | |
| 38 | - Deduplicate by `file:line` plus claim. |
| 39 | - Keep the highest severity only when the evidence matches the rubric. |
| 40 | - Move unsupported or disputed claims to Needs review. |
| 41 | - Prefix confirmed findings with `[Flagged by: <dimension or file group>]` only when it helps explain coverage. |
| 42 | |
| 43 | ## External mode |
| 44 | |
| 45 | When `external` is requested, spawn configured external reviewer bridges in parallel if available. Do not depend on a specific bridge or model. |
| 46 | |
| 47 | Report the result explicitly: |
| 48 | |
| 49 | - `External review: completed` when it ran. |
| 50 | - `External review: unavailable` when no bridge exists. |
| 51 | - `External review: skipped` when privacy, missing scope, or tooling prevents it. |
| 52 | |
| 53 | Apply the host severity rubric to external output. Do not include external claims as confirmed findings unless the local review can verify the evidence. |
| 54 | |
| 55 | ## Historical context |
| 56 | |
| 57 | If memory search is available, query past observations for files in scope. Use it only to avoid repeating already-litigated findings. Do not treat memory as evidence for a new finding. |
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
