Offer to create follow-up issues from non-blocking review findings after PR merge

[sebastientaggart]

Problem

When the PR review agent runs during /submit-for-review, it emits findings at three levels: CRITICAL (blocking), WARNING, and NOTE. Only CRITICAL blocks the merge — WARNING and NOTE findings are reported but silently dropped after merge. In practice these non-blocking findings are often insightful and deserve follow-up work, but today converting them into tracked tickets is a manual step that rarely happens.

Goal

After a PR is successfully merged via /submit-for-review, if the code review produced any non-blocking findings, offer the user the option to convert one or more of them into GitHub issues for follow-up.

Why the timing matters

The offer must happen after merge, not before:

• If the review produces CRITICAL findings, the user fixes them and re-runs /submit-for-review. Earlier findings are stale by then — only the findings from the final approved review should become tickets.
• Running the offer after merge avoids delaying the merge path and keeps the happy path fast.

Scope

• Applies to ai and advisory review gates. Skipped entirely when the gate is off (no review, no findings).
• User is prompted once, can select specific findings, all, or none.
• Follow-up issues link back to the merged PR for context.
• Always offered — no new config setting.

[sebastientaggart]

Agent Implementation Notes

Files to change:

• skills/submit-for-review.md — add new Step 9 "Offer follow-up issues" between the post-merge success report and the "Important constraints" section. Add one bullet to the constraints section.
• skills/review-agent.md — one-sentence clarification in the "Review Output Format" section stating that WARNING/NOTE findings should be phrased as self-contained sentences (no "see above" references) so they can become standalone ticket titles.

Step 9 flow:

1. Gate: skip if REVIEW_GATE is off, or if the review produced no non-blocking findings.
2. Parse the review output retained from Step 7 for [WARNING] and [NOTE] lines. For advisory mode, also include any [CRITICAL] lines that were merged over.
3. Show numbered list and ask exactly once: "The review flagged N non-blocking findings. Create follow-up issues for any of them? Enter numbers (e.g. 1,3), all, or none."
4. For each selected finding, gh issue create with:
   • Title: finding text with [WARNING]/[NOTE] prefix stripped
   • Body: finding text + "Follow-up from PR #" reference + note that it was auto-proposed from code review
   • Labels: pool-selection from bug, documentation, enhancement, chore per finding (same three-tier resolver logic as /start, but pool-only since no per-invocation flag is available)
   • Milestone: omit (follow-ups are future work, not current sprint)
   • No --assignee @me (backlog items)
5. Report: Created N follow-up issue(s): #X, #Y or No follow-up issues created.

Key decisions:

• Always offer, no config setting. User dismisses with none if not wanted.
• No new template variables in .codecannon.yaml.
• Follow-ups do not inherit the current milestone — they are future work.
• For advisory mode with CRITICAL findings: those merged-over criticals also become eligible for follow-up tickets, since the user chose to ship anyway.

Edge cases:

• Review output empty or unparseable → skip silently.
• User input invalid (not numbers/all/none) → re-prompt once, then skip.
• gh issue create fails for one finding → report the failure, continue with remaining selections.