review-with-intentlisted

# Inputs Expected input from the user: - **Intent source** — one of: - a GitHub issue number (e.g. `#42`) - a GitHub issue URL - pasted text (spec, ticket body, acceptance criteria, user story) - free-form description of the goal - **Changes to review** — one of: - current branch diff vs main (default) - a specific PR number or URL - a named branch - an explicit commit range If intent source is missing but a PR is provided, check the PR description for linked issues (e.g. `Closes #42`, `Fixes #42`, bare `#42` references) before asking — fetch the linked issue and use it as the intent source. Only ask if no intent can be found this way. # High-level behavior Follow this approach strictly in order: ## Step 1 — Extract intent Extract the structured intent from the provided source. Produce: - **Goal** — one-sentence summary of the intent - **Scope** — what is in and out of scope (inferred if not explicit) - **Acceptance criteria** — bulleted list; extract explicit ones or derive from the description - **Key behaviors** — specific behaviors or constraints the implementation must satisfy ## Step 2 — Gather the diff Get the code changes with `gh` cli and git operations. ## Step 3 — Review against intent Compare the diff to the structured intent from Step 1. Evaluate: 1. **Intent match** — which acceptance criteria and key behaviors are clearly implemented 2. **Intent gaps** — criteria or behaviors with no corresponding implementation 3. **Intent divergen