review-change
installsforks
How to install review-change?
gtrabanco/agentic-workflow/review-change
$npx -y skills add gtrabanco/agentic-workflow --skill review-changePlatform-adaptive review orchestrator. Reviews the current change by running review-implementation (find → classify) AND the workflow's own internal review pack — only the passes that apply to this project and this change (review-code, review-security, review-verify, review-debt,
SKILL.md
| 1 | # Review Change |
| 2 | |
| 3 | The quality gate for a change: get every review that *applies* — and skip the ones |
| 4 | that don't — in one synthesized, classified report. **Findings only; never edits |
| 5 | or refactors.** |
| 6 | |
| 7 | ## Turn contract — verify before ending the turn |
| 8 | |
| 9 | ``` |
| 10 | ✓ This review runs in a conversation that did NOT implement the change; if this conversation wrote the diff, STOP and hand off to a fresh one (the reviewer works from the diff + the SPEC, not the author's mental state). |
| 11 | ✓ The synthesized decision table + manual-verification checklist + `Decision: PASS | FAIL` were returned in the fixed output format |
| 12 | ✓ Every non-fix-now finding got a destination (triaged — issue / decision / drop) |
| 13 | ✓ The closing `→ Next:` block is printed as the ABSOLUTE last output |
| 14 | ``` |
| 15 | |
| 16 | About to end the turn with any box unchecked? The turn is NOT done — complete |
| 17 | the missing box first (weak models drop end-of-document duties; this list is |
| 18 | first on purpose). |
| 19 | |
| 20 | ## When to use |
| 21 | |
| 22 | - **Mandatory before every merge** — every unit (feature, single-pass, or fix) gets a |
| 23 | `review-change` pass before its merge gate; that end review is never skipped, and |
| 24 | it must run in a conversation that did **not** implement the change — the |
| 25 | conversation that wrote a diff shares the author's mental model and tends to |
| 26 | catch only mechanical issues, missing design defects a context-clean, |
| 27 | adversarial reviewer would find (see the turn-contract box above). If the |
| 28 | reviewing conversation authored the diff, stop and hand off to a fresh one |
| 29 | before reviewing. |
| 30 | `execute-phase` additionally **recommends** a hand-off at its trigger-based |
| 31 | checkpoints (layer boundary, accumulation, or sensitivity — see `#77`) — an |
| 32 | optional checkpoint the user may skip. |
| 33 | - When you want the *right* reviews for this change without running irrelevant |
| 34 | passes (e.g. accessibility on a backend change). |
| 35 | |
| 36 | ## Scope |
| 37 | |
| 38 | Default target is the **current change** (branch diff vs the default branch); |
| 39 | accept a path/glob to widen or narrow. State the scope at the top of the report. |
| 40 | |
| 41 | ## Step 0 — Discover the project & the change (always first) |
| 42 | |
| 43 | Per the agent guide's **Workflow conventions** + **documentation map**, then |
| 44 | decide which axes apply from two inputs: |
| 45 | |
| 46 | 1. **Project nature** — from the guide/map: is there a UI (`docs/frontend/` |
| 47 | present)? Is it web, mobile, console/CLI, library/SDK, or backend/infra? Note |
| 48 | any optional platform review skills the project recorded (its `init-workspace` |
| 49 | notes them) — extras, never requirements. |
| 50 | 2. **Change footprint** — what the diff actually touches (UI components? an API? |
| 51 | infra? domain logic?). An axis applies only if **both** the project has it |
| 52 | **and** the change touches it. |
| 53 | |
| 54 | ## Applicability matrix (default; the project's docs refine it) |
| 55 | |
| 56 | Every axis maps to a skill of the workflow's **own internal review pack** |
| 57 | (`skills/review-*` — installed with the workflow, so none can be missing): |
| 58 | |
| 59 | | Axis — internal pack skill | Web | Mobile | Console/CLI | Lib/SDK | Backend/Infra | |
| 60 | |---|---|---|---|---|---| |
| 61 | | `review-implementation` (bugs, arch, security, dead code, perf, tests, rules) | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 62 | | `review-code` (correctness + simplification) | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 63 | | `review-security` | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 64 | | `review-verify` (run it, confirm real behavior) | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 65 | | `review-debt` | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 66 | | `review-design` (UI/UX) | ✓ | ✓ | TUI only | ✗ | ✗ | |
| 67 | | `review-a11y` | ✓ | ✓ | rare | ✗ | ✗ | |
| 68 | | `review-brand` (voice/copy) | ✓ | ✓ | output text | ✗ | ✗ | |
| 69 | | `review-perf` | ✓ | ✓ | ✓ | ✓ | ✓ | |
| 70 | | `review-seo` | ✓ | ✗ | ✗ | ✗ | ✗ | |
| 71 | | API ergonomics / usage docs (inline pass) | if API | if API | flags/help | ✓✓ | ✓ | |
| 72 | |
| 73 | ## Isolation rule (defaul |
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
