Add post-review gate for NOTE/WARNING findings before merge

.agents/skills/submit-for-review/SKILL.md

@@ -180,7 +180,24 @@ Apply QA label and report success (see below).
 
 **If `ai` is `"ai"` (default):**
 
-**If APPROVE (no CRITICAL findings):** Run the merge command. Apply QA label and report success (see below).
+**If APPROVE (no CRITICAL findings):**
+
+Collect any non-blocking findings (`[WARNING]` or `[NOTE]` lines) from the review output.
+
+- **If there are no non-blocking findings** (clean review): Run the merge command immediately. Apply QA label and report success (see below).
+
+- **If there are non-blocking findings**: Present the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` prefix) and say:
+
+  > "The review approved with N non-blocking finding(s):
+  >
+  > <numbered list of findings>
+  >
+  > Would you like to **address these first** before merging, or **merge now**?"
+
+  Wait for the user to respond.
+
+  - User says **address / fix** → return to the coding loop. Say: "Fix the findings and run `/submit-for-review` again when ready." Do NOT merge.
+  - User says **merge now** → run the merge command. Apply QA label and report success (see below). Proceed to Step 9 as normal (which will offer to create follow-up issues for any remaining findings).
 
 **If REQUEST CHANGES (at least one CRITICAL finding):** Report the findings to the user. Do NOT merge. Say:
 
@@ -281,4 +298,4 @@ If a single `gh issue create` call fails, report the failure for that finding an
 - `/submit-for-review` merges only to `dev` — never directly to `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
 - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 49145655 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: ba60d5aa | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.claude/commands/submit-for-review.md

@@ -175,7 +175,24 @@ Apply QA label and report success (see below).
 
 **If `ai` is `"ai"` (default):**
 
-**If APPROVE (no CRITICAL findings):** Run the merge command. Apply QA label and report success (see below).
+**If APPROVE (no CRITICAL findings):**
+
+Collect any non-blocking findings (`[WARNING]` or `[NOTE]` lines) from the review output.
+
+- **If there are no non-blocking findings** (clean review): Run the merge command immediately. Apply QA label and report success (see below).
+
+- **If there are non-blocking findings**: Present the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` prefix) and say:
+
+  > "The review approved with N non-blocking finding(s):
+  >
+  > <numbered list of findings>
+  >
+  > Would you like to **address these first** before merging, or **merge now**?"
+
+  Wait for the user to respond.
+
+  - User says **address / fix** → return to the coding loop. Say: "Fix the findings and run `/submit-for-review` again when ready." Do NOT merge.
+  - User says **merge now** → run the merge command. Apply QA label and report success (see below). Proceed to Step 9 as normal (which will offer to create follow-up issues for any remaining findings).
 
 **If REQUEST CHANGES (at least one CRITICAL finding):** Report the findings to the user. Do NOT merge. Say:
 
@@ -276,4 +293,4 @@ If a single `gh issue create` call fails, report the failure for that finding an
 - `/submit-for-review` merges only to `dev` — never directly to `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
 - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 357d6721 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 28da1f65 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.cursor/rules/submit-for-review.mdc

@@ -181,7 +181,24 @@ Apply QA label and report success (see below).
 
 **If `ai` is `"ai"` (default):**
 
-**If APPROVE (no CRITICAL findings):** Run the merge command. Apply QA label and report success (see below).
+**If APPROVE (no CRITICAL findings):**
+
+Collect any non-blocking findings (`[WARNING]` or `[NOTE]` lines) from the review output.
+
+- **If there are no non-blocking findings** (clean review): Run the merge command immediately. Apply QA label and report success (see below).
+
+- **If there are non-blocking findings**: Present the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` prefix) and say:
+
+  > "The review approved with N non-blocking finding(s):
+  >
+  > <numbered list of findings>
+  >
+  > Would you like to **address these first** before merging, or **merge now**?"
+
+  Wait for the user to respond.
+
+  - User says **address / fix** → return to the coding loop. Say: "Fix the findings and run `/submit-for-review` again when ready." Do NOT merge.
+  - User says **merge now** → run the merge command. Apply QA label and report success (see below). Proceed to Step 9 as normal (which will offer to create follow-up issues for any remaining findings).
 
 **If REQUEST CHANGES (at least one CRITICAL finding):** Report the findings to the user. Do NOT merge. Say:
 
@@ -282,4 +299,4 @@ If a single `gh issue create` call fails, report the failure for that finding an
 - `/submit-for-review` merges only to `dev` — never directly to `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
 - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 19e7acf4 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: d2df6354 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.gemini/skills/submit-for-review/SKILL.md

@@ -180,7 +180,24 @@ Apply QA label and report success (see below).
 
 **If `ai` is `"ai"` (default):**
 
-**If APPROVE (no CRITICAL findings):** Run the merge command. Apply QA label and report success (see below).
+**If APPROVE (no CRITICAL findings):**
+
+Collect any non-blocking findings (`[WARNING]` or `[NOTE]` lines) from the review output.
+
+- **If there are no non-blocking findings** (clean review): Run the merge command immediately. Apply QA label and report success (see below).
+
+- **If there are non-blocking findings**: Present the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` prefix) and say:
+
+  > "The review approved with N non-blocking finding(s):
+  >
+  > <numbered list of findings>
+  >
+  > Would you like to **address these first** before merging, or **merge now**?"
+
+  Wait for the user to respond.
+
+  - User says **address / fix** → return to the coding loop. Say: "Fix the findings and run `/submit-for-review` again when ready." Do NOT merge.
+  - User says **merge now** → run the merge command. Apply QA label and report success (see below). Proceed to Step 9 as normal (which will offer to create follow-up issues for any remaining findings).
 
 **If REQUEST CHANGES (at least one CRITICAL finding):** Report the findings to the user. Do NOT merge. Say:
 
@@ -281,4 +298,4 @@ If a single `gh issue create` call fails, report the failure for that finding an
 - `/submit-for-review` merges only to `dev` — never directly to `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
 - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: a051c639 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: 156f1ee6 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

skills/submit-for-review.md

@@ -204,7 +204,24 @@ Apply QA label and report success (see below).
 
 **If `{{REVIEW_GATE}}` is `"ai"` (default):**
 
-**If APPROVE (no CRITICAL findings):** Run the merge command. Apply QA label and report success (see below).
+**If APPROVE (no CRITICAL findings):**
+
+Collect any non-blocking findings (`[WARNING]` or `[NOTE]` lines) from the review output.
+
+- **If there are no non-blocking findings** (clean review): Run the merge command immediately. Apply QA label and report success (see below).
+
+- **If there are non-blocking findings**: Present the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` prefix) and say:
+
+  > "The review approved with N non-blocking finding(s):
+  >
+  > <numbered list of findings>
+  >
+  > Would you like to **address these first** before merging, or **merge now**?"
+
+  Wait for the user to respond.
+
+  - User says **address / fix** → return to the coding loop. Say: "Fix the findings and run `/submit-for-review` again when ready." Do NOT merge.
+  - User says **merge now** → run the merge command. Apply QA label and report success (see below). Proceed to Step 9 as normal (which will offer to create follow-up issues for any remaining findings).
 
 **If REQUEST CHANGES (at least one CRITICAL finding):** Report the findings to the user. Do NOT merge. Say: