diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index e5e97f3..4d5beca 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -263,7 +263,7 @@ If a linked issue number was identified in Step 3, apply the QA label: ``` gh issue edit --add-label "ready-for-qa" ``` -If no linked issue was found, skip silently. +If no linked issue was found, skip silently. If the command fails (e.g. the label does not exist in the repo, or `gh` returns a non-zero exit), print a one-line warning showing the stderr and continue to the resolution comment and success report — do not abort. The merge has already happened; surfacing the failure is enough. **Post a resolution comment** on the linked issue (skip silently if no linked issue): @@ -380,4 +380,4 @@ Use the unqualified `#N` form for all issue and PR references in the body. If `/ - `/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 actionable findings (WARNINGs in `ai` mode, plus CRITICALs in `advisory` mode). Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. NOTEs never become follow-up tickets. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 6499c9e..a675832 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -258,7 +258,7 @@ If a linked issue number was identified in Step 3, apply the QA label: ``` gh issue edit --add-label "ready-for-qa" ``` -If no linked issue was found, skip silently. +If no linked issue was found, skip silently. If the command fails (e.g. the label does not exist in the repo, or `gh` returns a non-zero exit), print a one-line warning showing the stderr and continue to the resolution comment and success report — do not abort. The merge has already happened; surfacing the failure is enough. **Post a resolution comment** on the linked issue (skip silently if no linked issue): @@ -375,4 +375,4 @@ Use the unqualified `#N` form for all issue and PR references in the body. If `/ - `/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 actionable findings (WARNINGs in `ai` mode, plus CRITICALs in `advisory` mode). Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. NOTEs never become follow-up tickets. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 919c82f..5aa2ddc 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -264,7 +264,7 @@ If a linked issue number was identified in Step 3, apply the QA label: ``` gh issue edit --add-label "ready-for-qa" ``` -If no linked issue was found, skip silently. +If no linked issue was found, skip silently. If the command fails (e.g. the label does not exist in the repo, or `gh` returns a non-zero exit), print a one-line warning showing the stderr and continue to the resolution comment and success report — do not abort. The merge has already happened; surfacing the failure is enough. **Post a resolution comment** on the linked issue (skip silently if no linked issue): @@ -381,4 +381,4 @@ Use the unqualified `#N` form for all issue and PR references in the body. If `/ - `/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 actionable findings (WARNINGs in `ai` mode, plus CRITICALs in `advisory` mode). Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. NOTEs never become follow-up tickets. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 7d8c4a1..0a04080 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -263,7 +263,7 @@ If a linked issue number was identified in Step 3, apply the QA label: ``` gh issue edit --add-label "ready-for-qa" ``` -If no linked issue was found, skip silently. +If no linked issue was found, skip silently. If the command fails (e.g. the label does not exist in the repo, or `gh` returns a non-zero exit), print a one-line warning showing the stderr and continue to the resolution comment and success report — do not abort. The merge has already happened; surfacing the failure is enough. **Post a resolution comment** on the linked issue (skip silently if no linked issue): @@ -380,4 +380,4 @@ Use the unqualified `#N` form for all issue and PR references in the body. If `/ - `/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 actionable findings (WARNINGs in `ai` mode, plus CRITICALs in `advisory` mode). Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed. NOTEs never become follow-up tickets. - + diff --git a/skills/github-agile/submit-for-review.md b/skills/github-agile/submit-for-review.md index a3a59eb..abfec68 100644 --- a/skills/github-agile/submit-for-review.md +++ b/skills/github-agile/submit-for-review.md @@ -290,7 +290,7 @@ If a linked issue number was identified in Step 3, apply the QA label: ``` gh issue edit --add-label "{{QA_READY_LABEL}}" ``` -If no linked issue was found, skip silently. +If no linked issue was found, skip silently. If the command fails (e.g. the label does not exist in the repo, or `gh` returns a non-zero exit), print a one-line warning showing the stderr and continue to the resolution comment and success report — do not abort. The merge has already happened; surfacing the failure is enough. {{/if}} {{/if}} {{/if}}