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: