Coding Review Simplify
Tighten a completed diff while the implementation context is fresh. The result is a smaller coherent shape, or a focused concern with proof. The next consumer is the approved review plan.
This is a behavior-preserving pass. It does not automatically call full-review. The approved routing plan decides whether a later focused, seam, or deep review is needed.
Workflow
- Read the task acceptance contract, changed files, diff, and verification already captured. Start with the changed surface and expand only across a real boundary.
- Check the change against its intended observable behavior. Report a concern only when it can cause a bug, regression, maintenance trap, data risk, weak verification, or material reader confusion.
- Simplify only when the result remains behavior-preserving. Keep validation at trust boundaries, authorization checks, invariant assertions, encoding, and accessibility safeguards unless evidence proves they are dead.
- Select a focused review when the diff adds a helper, changes ownership, or affects a hot or asynchronous path. Read the matching persona from
references/personas/ only for that concern. Use data-systems-coding-lens when stored state or asynchronous behavior changes.
- Run the Connascence Pass only when the diff crosses a boundary or feels tangled. Identify what is connascent, then state its strength, locality, degree, and smallest safe remedy. Leave local static coupling alone when extraction adds indirection without safety.
- Escalate a boundary-wide design concern to the relevant lens. Do not start a broader refactor from this pass.
- Turn each accepted concern into a focused fix, test, check, or explicit follow-up. Re-run only the verification affected by a made change.
Simplification cues
Use the clean-code vocabulary. Look for a helper with no decision, a type that hides an awkward contract, needless memoization or effects, compatibility code with no callers, and unrelated diff churn. A name can be better than a wrapper. Duplication can stay when the concepts may diverge.
Output
For review-only work, list findings by severity with location, consequence, smallest useful fix, and verification.
For implementation work, return:
- Outcome: safe as is, simplified, needs a focused fix, or needs design escalation.
- Changes made.
- Verification captured.
- Remaining risk.
Use references/team-checklists.md only immediately before handoff or deployment. Do not measure success by lines removed; the measure is a simpler change that preserves observable behavior.
1---2name: coding-review-simplify3description: Review a completed code change for behavior-preserving simplification, local correctness, and maintainability. Use after implementing a scoped task or when the user asks to simplify a concrete diff. Do not use as a full feature review or to choose the delivery reviewer plan.4---56# Coding Review Simplify78Tighten a completed diff while the implementation context is fresh. The result is a smaller coherent shape, or a focused concern with proof. The next consumer is the approved review plan.910This is a behavior-preserving pass. It does not automatically call `full-review`. The approved routing plan decides whether a later focused, seam, or deep review is needed.1112## Workflow13141. Read the task acceptance contract, changed files, diff, and verification already captured. Start with the changed surface and expand only across a real boundary.152. Check the change against its intended observable behavior. Report a concern only when it can cause a bug, regression, maintenance trap, data risk, weak verification, or material reader confusion.163. Simplify only when the result remains behavior-preserving. Keep validation at trust boundaries, authorization checks, invariant assertions, encoding, and accessibility safeguards unless evidence proves they are dead.174. Select a focused review when the diff adds a helper, changes ownership, or affects a hot or asynchronous path. Read the matching persona from `references/personas/` only for that concern. Use `data-systems-coding-lens` when stored state or asynchronous behavior changes.185. Run the **Connascence Pass** only when the diff crosses a boundary or feels tangled. Identify what is **connascent**, then state its strength, locality, degree, and smallest safe remedy. Leave local static coupling alone when extraction adds indirection without safety.196. Escalate a boundary-wide design concern to the relevant lens. Do not start a broader refactor from this pass.207. Turn each accepted concern into a focused fix, test, check, or explicit follow-up. Re-run only the verification affected by a made change.2122## Simplification cues2324Use the `clean-code` vocabulary. Look for a helper with no decision, a type that hides an awkward contract, needless memoization or effects, compatibility code with no callers, and unrelated diff churn. A name can be better than a wrapper. Duplication can stay when the concepts may diverge.2526## Output2728For review-only work, list findings by severity with location, consequence, smallest useful fix, and verification.2930For implementation work, return:31321. Outcome: safe as is, simplified, needs a focused fix, or needs design escalation.332. Changes made.343. Verification captured.354. Remaining risk.3637Use `references/team-checklists.md` only immediately before handoff or deployment. Do not measure success by lines removed; the measure is a simpler change that preserves observable behavior.
robsonrung