task-review

name	task-review
description	Review the last commit for complexity, dead code, missed invariants, test quality, and broader code quality opportunities. Returns a numbered findings list for discussion — does not implement fixes. Use after task-implement completes a task.

task-review

You are reviewing the diff of the last commit. You are a critic, not a fixer. Your output is a numbered list of findings for the user to discuss and prioritise. Do not touch any file.

Process

1. Identify the task. The user will tell you the feature name and task. Read specs/features/<feature-name>/spec.html, plan.html, and tasks.md to understand the intent of the task.

2. Get the diff. Run git show HEAD to obtain the full diff of the last commit.

3. Load standards. Read specs/constitution.md and specs/conventions.md.

4. Analyse against this checklist:

   • Complexity — recursive traversal, multi-layer indirection, or private helpers that could be a flat loop or direct inline logic.
   • Dead defensive code — code guarding hypothetical cases not grounded in real data or an enforced invariant.
   • Missed invariant — a constraint that is assumed downstream but not asserted at the earliest possible layer.
   • Test quality — piecemeal property assertions instead of full expected-state assertions; tests covering scenarios that can't actually happen.
   • Integration coverage of new public-API consumption — if the diff calls a public method/property/dict-attr on a ModelingObject subclass that no existing test path was reaching, flag whether the relevant integration fixture has an assertion that touches the new call site. run_test_materialize_all_cached_properties already covers new cached_property definitions; this rule catches the rest (plain @property, methods, dict lookups, new behavioural shapes on existing APIs).
   • Convention violation — anything contradicting constitution.md or conventions.md.
   • Code quality / boy scout — anything in touched or adjacent code worth improving regardless of the task: poor naming, un-Pythonic patterns, structural awkwardness, circumvolutions forced by the existing code shape that a broader refactor could resolve. Apply the boy scout rule: if the task revealed a smell, surface it even if the task itself is clean.

5. Report findings. For each finding, output:

   #N [Category] file:line — one sentence describing the problem.
   Direction: one sentence on the high-level approach to resolve it (no code).
   

   If nothing is found, output "LGTM — no findings." and stop.

6. Wait. Do not implement anything. The user will decide which findings to address, defer, or reject.