MCAF: Code Review
Trigger On
- shaping PR review policy
- preparing a change for review
- auditing whether a change is actually review-ready
- tightening reviewer expectations or templates
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- implementing the code change itself
- generic team-process work with no PR or review component
Inputs
- the diff or planned PR scope
- tests, docs, and architecture notes affected by the change
- current review template or review policy, if any
Quick Start
- Read the nearest
AGENTS.md and confirm scope and constraints.
- Run this skill's
Workflow through the Ralph Loop until outcomes are acceptable.
- Return the
Required Result Format with concrete artifacts and verification evidence.
Workflow
- Confirm the change is small enough to review coherently. Split if needed.
- Check that tests, docs, and architecture notes moved with the code.
- Review in this order:
- behavioural risk
- design and maintainability
- test quality
- operational or security impact
- If the repo needs review policy or a template, define it in-repo.
- Keep reviewer guidance concrete. Avoid vague "review carefully" language.
Deliver
- review-ready pull requests
- review guidance that is specific and enforceable
- findings tied to behaviour, design, testing, and risk
Validate
- the review guidance tells reviewers what to check, not just that they should check
- PR scope is understandable without opening the whole repo
- tests and docs are part of review readiness, not afterthoughts
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Plan first (mandatory):
- analyze current state
- define target outcome, constraints, and risks
- write a detailed execution plan
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicable with explicit reason and fallback path.
Required Result Format
status: complete | clean | improved | configured | not_applicable | blocked
plan: concise plan and current iteration step
actions_taken: concrete changes made
validation_skills: final skills run, or skipped with reasons
verification: commands, checks, or review evidence summary
remaining: top unresolved items or none
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
- read
references/code-reviews.md and references/pull-requests.md first
- open
references/pull-request-template.md, references/inclusion-in-code-review.md, or references/faq.md only when needed
Example Requests
- "Make our PR template less useless."
- "Is this change actually ready for code review?"
- "Define stricter review expectations for this repo."
1---2name: mcaf-code-review3description: Prepare for, perform, or tighten code review workflow: PR scope, review checklist, reviewer expectations, and merge hygiene. Use when shaping pull requests, defining review policy, or auditing whether a change is review-ready.4---56# MCAF: Code Review78## Trigger On910- shaping PR review policy11- preparing a change for review12- auditing whether a change is actually review-ready13- tightening reviewer expectations or templates1415## Value1617- produce a concrete project delta: code, docs, config, tests, CI, or review artifact18- reduce ambiguity through explicit planning, verification, and final validation skills19- leave reusable project context so future tasks are faster and safer2021## Do Not Use For2223- implementing the code change itself24- generic team-process work with no PR or review component2526## Inputs2728- the diff or planned PR scope29- tests, docs, and architecture notes affected by the change30- current review template or review policy, if any3132## Quick Start33341. Read the nearest `AGENTS.md` and confirm scope and constraints.352. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.363. Return the `Required Result Format` with concrete artifacts and verification evidence.3738## Workflow39401. Confirm the change is small enough to review coherently. Split if needed.412. Check that tests, docs, and architecture notes moved with the code.423. Review in this order:43 - behavioural risk44 - design and maintainability45 - test quality46 - operational or security impact474. If the repo needs review policy or a template, define it in-repo.485. Keep reviewer guidance concrete. Avoid vague "review carefully" language.4950## Deliver5152- review-ready pull requests53- review guidance that is specific and enforceable54- findings tied to behaviour, design, testing, and risk5556## Validate5758- the review guidance tells reviewers what to check, not just that they should check59- PR scope is understandable without opening the whole repo60- tests and docs are part of review readiness, not afterthoughts6162## Ralph Loop6364Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.65661. Plan first (mandatory):67 - analyze current state68 - define target outcome, constraints, and risks69 - write a detailed execution plan70 - list final validation skills to run at the end, with order and reason712. Execute one planned step and produce a concrete delta.723. Review the result and capture findings with actionable next fixes.734. Apply fixes in small batches and rerun the relevant checks or review steps.745. Update the plan after each iteration.756. Repeat until outcomes are acceptable or only explicit exceptions remain.767. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.7778### Required Result Format7980- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`81- `plan`: concise plan and current iteration step82- `actions_taken`: concrete changes made83- `validation_skills`: final skills run, or skipped with reasons84- `verification`: commands, checks, or review evidence summary85- `remaining`: top unresolved items or `none`8687For setup-only requests with no execution, return `status: configured` and exact next commands.8889## Load References9091- read `references/code-reviews.md` and `references/pull-requests.md` first92- open `references/pull-request-template.md`, `references/inclusion-in-code-review.md`, or `references/faq.md` only when needed9394## Example Requests9596- "Make our PR template less useless."97- "Is this change actually ready for code review?"98- "Define stricter review expectations for this repo."