From 59b17dcacdce16612cefab7d12e0f4f9c48763c2 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Sat, 11 Apr 2026 09:01:48 -0400 Subject: [PATCH] Add post-review human gate for non-blocking findings before merge --- .agents/skills/submit-for-review/SKILL.md | 21 +++++++++++++++++++-- .claude/commands/submit-for-review.md | 21 +++++++++++++++++++-- .cursor/rules/submit-for-review.mdc | 21 +++++++++++++++++++-- .gemini/skills/submit-for-review/SKILL.md | 21 +++++++++++++++++++-- skills/submit-for-review.md | 19 ++++++++++++++++++- 5 files changed, 94 insertions(+), 9 deletions(-) diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index edb53ad..dd35ec9 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.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): + > + > + > + > 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. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 12b8720..95d9218 100644 --- a/.claude/commands/submit-for-review.md +++ b/.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): + > + > + > + > 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. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index d0909d3..ef6b002 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.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): + > + > + > + > 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. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index f834417..c494469 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.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): + > + > + > + > 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. - + diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 639dd8d..9def763 100644 --- a/skills/submit-for-review.md +++ b/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): + > + > + > + > 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: