mcaf-code-review

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

1. Read the nearest AGENTS.md and confirm scope and constraints.
2. Run this skill's Workflow through the Ralph Loop until outcomes are acceptable.
3. Return the Required Result Format with concrete artifacts and verification evidence.

Workflow

1. Confirm the change is small enough to review coherently. Split if needed.
2. Check that tests, docs, and architecture notes moved with the code.
3. Review in this order:
   • behavioural risk
   • design and maintainability
   • test quality
   • operational or security impact
4. If the repo needs review policy or a template, define it in-repo.
5. 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.

1. Brainstorm first (mandatory):
   • analyze current state
   • define the problem, target outcome, constraints, and risks
   • generate options and think through trade-offs before committing
   • capture the recommended direction and open questions
2. Plan second (mandatory):
   • write a detailed execution plan from the chosen direction
   • list final validation skills to run at the end, with order and reason
3. Execute one planned step and produce a concrete delta.
4. Review the result and capture findings with actionable next fixes.
5. Apply fixes in small batches and rerun the relevant checks or review steps.
6. Update the plan after each iteration.
7. Repeat until outcomes are acceptable or only explicit exceptions remain.
8. If a dependency is missing, bootstrap it or return status: not_applicable with explicit reason and fallback path.