mcj-coder Structured Review Workflow
Intent
Coordinate review activities by composing the request and response skills so feedback is handled consistently and evidence remains the source of truth.
When to Use
- When you need the full review loop (request + receive).
- When multiple review personas are involved.
- When review scope or expectations are ambiguous.
Precondition Failure Signal
- Review is requested without evidence.
- Feedback is implemented without verification or clarification.
- Scope grows beyond the original task.
Postcondition Success Signal
- Review request includes summary, evidence, and focus areas.
- Feedback is handled item-by-item with verification evidence.
- The review loop closes with explicit reviewer notification.
Process
- Request: Apply
requesting-code-review. - Receive: Apply
receiving-code-review. - Close: Re-run verification and notify reviewers.
- Review: Tech Lead validates process adherence.
Example Test / Validation
- Request: "Please review feat-X. Tests pass (logs attached). Focus on the migration in
V1__init.sql." - Response: "Applied null check in
UserService.cs. Keeping list as-is because [technical reason]."
Common Red Flags / Guardrail Violations
- Skipping
requesting-code-revieworreceiving-code-review. - Ignoring reviewer comments without justification.
- Expanding scope to appease subjective feedback.
Recommended Review Personas
- Tech Lead – validates process integrity and technical outcomes.
- Software Engineer – validates peer-level clarity and maintainability.
Skill Priority
P2 – Consistency & Governance
Conflict Resolution Rules
- Postcondition Success Signals from applied skills are the objective truth in any review conflict.
- Escalate to the Skill Priority Model (P0-P4) if reviewers disagree on priorities.
Conceptual Dependencies
- requesting-code-review
- receiving-code-review
- superpowers:verification-before-completion
Classification
Governance Core
Notes
Reviews are about the code, not the person. Use the defined skills as the common language for feedback.