execution-plan-review

# execution-plan-review Present the per-issue ordering and execution assignments as one table, absorb the user's revisions, and keep the GitHub issues — the single source of truth cold agents read — in sync. ## Steps ### 1. Render the table from the issues, not from memory Fetch every issue in the milestone (`gh issue list --milestone ... --json number,title,body`) and parse the `## Execution` blocks. The table: | Issue | C | Depends on | Runs after | Build model | Effort | Validate effort | fableplan first? | |---|---|---|---|---|---|---|---| (Validate effort defaults to high when an issue's block omits the line — show the effective value. Display an absent ordering field as `missing`, not `none`, so legacy prose inference is not silently discarded.) Follow with 2–3 sentences on the pattern (which Capability bands dominate, where fableplan bridges Capability 2, what the review trigger is) — enough for the user to sanity-check against the `prd-to-issues` / `validate-issue` band table, not a lecture. ### 2. Take revisions - The user revises in shorthand ("11 should be medium", "12 depends on 8 and 9", "13 runs after 12", "clear 14's dependencies"). Resolve ambiguous references (row position vs issue number) against the table just shown; when genuinely ambiguous, confirm in half a sentence. - **Push back once when a revision conflicts with the score band** (canonical table in `validate-issue` step 6 / `prd-to-issues`) — e.g. fableplan on Capability 0–1, or dropping bel...