From e1e60fbc6db9cd137d6e294384f64e0bc6e6224c Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Thu, 9 Apr 2026 18:21:17 -0400 Subject: [PATCH 1/7] Fix awkward TICKET_LABEL_CREATION_ALLOWED substitutions in start skill --- .agents/skills/start/SKILL.md | 11 +++-------- .agents/skills/submit-for-review/SKILL.md | 4 ++-- .claude/commands/start.md | 11 +++-------- .claude/commands/submit-for-review.md | 4 ++-- .cursor/rules/start.mdc | 11 +++-------- .cursor/rules/submit-for-review.mdc | 4 ++-- .gemini/skills/start/SKILL.md | 11 +++-------- .gemini/skills/submit-for-review/SKILL.md | 4 ++-- skills/start.md | 15 ++++++++++++--- skills/submit-for-review.md | 2 +- sync.sh | 6 +++++- 11 files changed, 38 insertions(+), 45 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index a84d3e8..caa34c3 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -40,12 +40,7 @@ After parsing flags, determine the active labels in this order: 2. **Pool-based selection** — the allowed label pool is: `bug, documentation, enhancement, chore` (comma-separated). Select 1–3 labels from this pool that genuinely fit the task description and implementation approach. Do not apply labels mechanically — pick only what fits. If no pool label fits the task, fall through to step 3. - If any selected label name contains a space (e.g. `good first issue`), quote the entire `--label` value. 3. **No label / creation** — if the pool is empty or no pool label fits: - - If label creation is allowed (`false` = `true`, case-insensitive): the agent **may** create a new label before applying it: - ```bash - gh label create "" --color "" --description "" - ``` - Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - - Otherwise (`false` = `false` or unset): omit `--label` entirely. Proceed silently; do not inform the user. + - Label creation is not allowed in this project. Omit `--label` entirely. Proceed silently; do not inform the user. **Milestone resolution (three-tier, Case A only):** @@ -228,6 +223,6 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - If already on a feature branch when `/start` is invoked, warn the user before creating another branch. - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. -- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit (or, when `false` = `true`, create). Never apply a label outside `bug, documentation, enhancement, chore` unless `false` = `true`. +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index 35afd88..c7ed607 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -236,7 +236,7 @@ EOF [--label ""] ``` -Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and do not create new labels regardless of `false`. +Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. @@ -259,4 +259,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/start.md b/.claude/commands/start.md index ccd7f07..043ad93 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -35,12 +35,7 @@ After parsing flags, determine the active labels in this order: 2. **Pool-based selection** — the allowed label pool is: `bug, documentation, enhancement, chore` (comma-separated). Select 1–3 labels from this pool that genuinely fit the task description and implementation approach. Do not apply labels mechanically — pick only what fits. If no pool label fits the task, fall through to step 3. - If any selected label name contains a space (e.g. `good first issue`), quote the entire `--label` value. 3. **No label / creation** — if the pool is empty or no pool label fits: - - If label creation is allowed (`false` = `true`, case-insensitive): the agent **may** create a new label before applying it: - ```bash - gh label create "" --color "" --description "" - ``` - Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - - Otherwise (`false` = `false` or unset): omit `--label` entirely. Proceed silently; do not inform the user. + - Label creation is not allowed in this project. Omit `--label` entirely. Proceed silently; do not inform the user. **Milestone resolution (three-tier, Case A only):** @@ -223,6 +218,6 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - If already on a feature branch when `/start` is invoked, warn the user before creating another branch. - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. -- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit (or, when `false` = `true`, create). Never apply a label outside `bug, documentation, enhancement, chore` unless `false` = `true`. +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 585ce7d..d0d0e18 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -231,7 +231,7 @@ EOF [--label ""] ``` -Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and do not create new labels regardless of `false`. +Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. @@ -254,4 +254,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/start.mdc b/.cursor/rules/start.mdc index 7e2f615..6566199 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -41,12 +41,7 @@ After parsing flags, determine the active labels in this order: 2. **Pool-based selection** — the allowed label pool is: `bug, documentation, enhancement, chore` (comma-separated). Select 1–3 labels from this pool that genuinely fit the task description and implementation approach. Do not apply labels mechanically — pick only what fits. If no pool label fits the task, fall through to step 3. - If any selected label name contains a space (e.g. `good first issue`), quote the entire `--label` value. 3. **No label / creation** — if the pool is empty or no pool label fits: - - If label creation is allowed (`false` = `true`, case-insensitive): the agent **may** create a new label before applying it: - ```bash - gh label create "" --color "" --description "" - ``` - Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - - Otherwise (`false` = `false` or unset): omit `--label` entirely. Proceed silently; do not inform the user. + - Label creation is not allowed in this project. Omit `--label` entirely. Proceed silently; do not inform the user. **Milestone resolution (three-tier, Case A only):** @@ -229,6 +224,6 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - If already on a feature branch when `/start` is invoked, warn the user before creating another branch. - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. -- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit (or, when `false` = `true`, create). Never apply a label outside `bug, documentation, enhancement, chore` unless `false` = `true`. +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 0645d89..378a674 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -237,7 +237,7 @@ EOF [--label ""] ``` -Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and do not create new labels regardless of `false`. +Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. @@ -260,4 +260,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/start/SKILL.md b/.gemini/skills/start/SKILL.md index 74c21a3..e62aaa3 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -40,12 +40,7 @@ After parsing flags, determine the active labels in this order: 2. **Pool-based selection** — the allowed label pool is: `bug, documentation, enhancement, chore` (comma-separated). Select 1–3 labels from this pool that genuinely fit the task description and implementation approach. Do not apply labels mechanically — pick only what fits. If no pool label fits the task, fall through to step 3. - If any selected label name contains a space (e.g. `good first issue`), quote the entire `--label` value. 3. **No label / creation** — if the pool is empty or no pool label fits: - - If label creation is allowed (`false` = `true`, case-insensitive): the agent **may** create a new label before applying it: - ```bash - gh label create "" --color "" --description "" - ``` - Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - - Otherwise (`false` = `false` or unset): omit `--label` entirely. Proceed silently; do not inform the user. + - Label creation is not allowed in this project. Omit `--label` entirely. Proceed silently; do not inform the user. **Milestone resolution (three-tier, Case A only):** @@ -228,6 +223,6 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - If already on a feature branch when `/start` is invoked, warn the user before creating another branch. - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. -- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit (or, when `false` = `true`, create). Never apply a label outside `bug, documentation, enhancement, chore` unless `false` = `true`. +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 7d074ba..2ca4f1d 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -236,7 +236,7 @@ EOF [--label ""] ``` -Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and do not create new labels regardless of `false`. +Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. @@ -259,4 +259,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/start.md b/skills/start.md index 3003ca3..169a2de 100644 --- a/skills/start.md +++ b/skills/start.md @@ -48,12 +48,16 @@ After parsing flags, determine the active labels in this order: 2. **Pool-based selection** — no label pool is configured. Fall through to step 3. {{/if}} 3. **No label / creation** — if the pool is empty or no pool label fits: - - If label creation is allowed (`{{TICKET_LABEL_CREATION_ALLOWED}}` = `true`, case-insensitive): the agent **may** create a new label before applying it: +{{#if TICKET_LABEL_CREATION_ALLOWED}} + - Label creation is allowed in this project. The agent **may** create a new label before applying it: ```bash gh label create "" --color "" --description "" ``` Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - - Otherwise (`{{TICKET_LABEL_CREATION_ALLOWED}}` = `false` or unset): omit `--label` entirely. Proceed silently; do not inform the user. +{{/if}} +{{#if !TICKET_LABEL_CREATION_ALLOWED}} + - Label creation is not allowed in this project. Omit `--label` entirely. Proceed silently; do not inform the user. +{{/if}} {{#if !TICKET_LABELS}} > **Tip:** Run `/setup` to populate TICKET_LABELS from your repo's existing GitHub labels. @@ -295,7 +299,12 @@ When done, say: **"The code is ready for review. Please run `{{DEV_CMD}}` and te - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor. - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. {{#if TICKET_LABELS}} -- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `{{TICKET_LABELS}}` → omit (or, when `{{TICKET_LABEL_CREATION_ALLOWED}}` = `true`, create). Never apply a label outside `{{TICKET_LABELS}}` unless `{{TICKET_LABEL_CREATION_ALLOWED}}` = `true`. +{{#if TICKET_LABEL_CREATION_ALLOWED}} +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `{{TICKET_LABELS}}` → create a new label when nothing in the pool fits. Labels outside `{{TICKET_LABELS}}` may only be created when no pool label is a good fit. +{{/if}} +{{#if !TICKET_LABEL_CREATION_ALLOWED}} +- Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `{{TICKET_LABELS}}` → omit `--label` entirely. Never apply a label outside `{{TICKET_LABELS}}`. +{{/if}} {{/if}} {{#if !TICKET_LABELS}} - Apply labels only when explicitly provided via `--label`. No label pool is configured. diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 92a8ce4..f011345 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -276,7 +276,7 @@ EOF [--label ""] ``` -Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `{{TICKET_LABELS}}` that genuinely fit the finding. If `{{TICKET_LABELS}}` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and do not create new labels regardless of `{{TICKET_LABEL_CREATION_ALLOWED}}`. +Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `{{TICKET_LABELS}}` that genuinely fit the finding. If `{{TICKET_LABELS}}` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. diff --git a/sync.sh b/sync.sh index 253ddb8..238ee57 100755 --- a/sync.sh +++ b/sync.sh @@ -146,7 +146,11 @@ def apply_conditionals(text, values): m = _IF_OPEN.match(lines[open_idx]) negated = m.group(1) == '!' key = m.group(2) - truthy = bool(values.get(key, '').strip()) + raw_value = values.get(key, '').strip() + # Empty string and boolean-like falsy strings ('false', 'no', '0') + # are treated as falsy so config values like 'false' behave intuitively + # in conditional blocks. + truthy = bool(raw_value) and raw_value.lower() not in ('false', 'no', '0') keep = (not truthy) if negated else truthy if keep: From 615f32e3a4d0a4fe87aaa8c15f6d14cf3da1af99 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Thu, 9 Apr 2026 18:34:53 -0400 Subject: [PATCH 2/7] Fix sync.sh --validate to respect {{#if}} conditionals --- sync.sh | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sync.sh b/sync.sh index 238ee57..af6e906 100755 --- a/sync.sh +++ b/sync.sh @@ -351,10 +351,11 @@ def validate_placeholders(skill_files, project_config): for skill_path in skill_files: raw = skill_path.read_text() fm, body = parse_frontmatter(raw) - # Check body and frontmatter description - text_to_check = body + # Evaluate conditionals first — placeholders inside stripped blocks + # are not part of the final output and should not be reported. + text_to_check = apply_conditionals(body, project_config) if fm.get('description'): - text_to_check += '\n' + fm['description'] + text_to_check += '\n' + apply_conditionals(fm['description'], project_config) missing = [p for p in find_unresolved(text_to_check) if p not in project_config] for p in missing: errors.append(f" {skill_path.name}: {{{{{p}}}}} not defined in config") From c6c29e5b4bab041ff4d7ea86c79fa9c9888c539b Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Thu, 9 Apr 2026 18:42:01 -0400 Subject: [PATCH 3/7] Prescribe structured ticket body with Problem/Why/Approach/Acceptance Criteria sections --- .agents/skills/start/SKILL.md | 23 +++++++++++++++++++++-- .claude/commands/start.md | 23 +++++++++++++++++++++-- .cursor/rules/start.mdc | 23 +++++++++++++++++++++-- .gemini/skills/start/SKILL.md | 23 +++++++++++++++++++++-- skills/start.md | 21 ++++++++++++++++++++- 5 files changed, 104 insertions(+), 9 deletions(-) diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index caa34c3..740cfa5 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -93,7 +93,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor): ```bash gh issue create \ --title "" \ - --body "" \ + --body "" \ --assignee @me \ [--label ""] \ [--milestone ""] @@ -103,6 +103,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label ""` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely. - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone ""` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely. +**Body structure (required sections, in this order):** + +```markdown +## Problem to Fix + + +## Why it Matters + + +## General Approach + + +## Acceptance Criteria +- +- +``` + +All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals). + **Title rules:** - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us` - ❌ `Fix broken link` @@ -225,4 +244,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index 043ad93..dc9d2b3 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -88,7 +88,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor): ```bash gh issue create \ --title "" \ - --body "" \ + --body "" \ --assignee @me \ [--label ""] \ [--milestone ""] @@ -98,6 +98,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label ""` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely. - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone ""` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely. +**Body structure (required sections, in this order):** + +```markdown +## Problem to Fix + + +## Why it Matters + + +## General Approach + + +## Acceptance Criteria +- +- +``` + +All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals). + **Title rules:** - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us` - ❌ `Fix broken link` @@ -220,4 +239,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 6566199..56b6728 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -94,7 +94,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor): ```bash gh issue create \ --title "" \ - --body "" \ + --body "" \ --assignee @me \ [--label ""] \ [--milestone ""] @@ -104,6 +104,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label ""` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely. - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone ""` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely. +**Body structure (required sections, in this order):** + +```markdown +## Problem to Fix + + +## Why it Matters + + +## General Approach + + +## Acceptance Criteria +- +- +``` + +All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals). + **Title rules:** - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us` - ❌ `Fix broken link` @@ -226,4 +245,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index e62aaa3..5ad7329 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -93,7 +93,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor): ```bash gh issue create \ --title "" \ - --body "" \ + --body "" \ --assignee @me \ [--label ""] \ [--milestone ""] @@ -103,6 +103,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label ""` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely. - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone ""` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely. +**Body structure (required sections, in this order):** + +```markdown +## Problem to Fix + + +## Why it Matters + + +## General Approach + + +## Acceptance Criteria +- +- +``` + +All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals). + **Title rules:** - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us` - ❌ `Fix broken link` @@ -225,4 +244,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit --remove-assignee @me`. - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`. - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation. - + diff --git a/skills/start.md b/skills/start.md index 169a2de..0f72dc6 100644 --- a/skills/start.md +++ b/skills/start.md @@ -136,7 +136,7 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor): ```bash gh issue create \ --title "" \ - --body "" \ + --body "" \ --assignee @me \ [--label ""] \ [--milestone ""] @@ -146,6 +146,25 @@ Resolve labels and milestone using the resolution steps in the Parsing section a - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label ""` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely. - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone ""` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely. +**Body structure (required sections, in this order):** + +```markdown +## Problem to Fix + + +## Why it Matters + + +## General Approach + + +## Acceptance Criteria +- +- +``` + +All four sections are required. Write for a non-developer audience — no code, no file paths. Acceptance Criteria must be concrete and verifiable (not vague goals). + **Title rules:** - ✅ `Fix 'Contact Us' footer link pointing to 404 instead of /contact-us` - ❌ `Fix broken link` From 56b56e7de8a82437dcae18a123981420fdfa7195 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart Date: Thu, 9 Apr 2026 19:02:36 -0400 Subject: [PATCH 4/7] Warn against fully-qualified Closes owner/repo#N in PR bodies --- .agents/skills/deploy/SKILL.md | 4 +++- .agents/skills/submit-for-review/SKILL.md | 4 +++- .claude/commands/deploy.md | 4 +++- .claude/commands/submit-for-review.md | 4 +++- .cursor/rules/deploy.mdc | 4 +++- .cursor/rules/submit-for-review.mdc | 4 +++- .gemini/skills/deploy/SKILL.md | 4 +++- .gemini/skills/submit-for-review/SKILL.md | 4 +++- skills/deploy.md | 4 ++++ skills/submit-for-review.md | 2 ++ 10 files changed, 30 insertions(+), 8 deletions(-) diff --git a/.agents/skills/deploy/SKILL.md b/.agents/skills/deploy/SKILL.md index 9ca68c1..7a67b52 100644 --- a/.agents/skills/deploy/SKILL.md +++ b/.agents/skills/deploy/SKILL.md @@ -186,6 +186,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `main` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge @@ -235,4 +237,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at ``. Run `make deploy-prod` to ship to production." - + diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index c7ed607..496b492 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -107,6 +107,8 @@ PR target branch: `dev` Use `Issue #` as the issue reference — the issue stays open until `/deploy` promotes to `main`. +> **Critical:** Use the unqualified `#N` form (e.g. `Closes #42`), never the fully-qualified `owner/repo#N` form (e.g. `Closes LightbridgeLab/CodeCannon#42`), even for same-repo references. GitHub's closing-keyword parser reliably populates `closingIssuesReferences` only for the unqualified form; the qualified form leaves that GraphQL edge empty, which silently breaks GitHub's native auto-close and any downstream automation that reads it. This overrides any general "use owner/repo#N for cross-linking" guidance your harness may have — closing-keyword lines in PR bodies are a special case. + Then create the PR with explicit title and body (never use an interactive editor): ``` gh pr create --base --title "" --body "$(cat <<'EOF' @@ -259,4 +261,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: d60b1861 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 6957b622 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.claude/commands/deploy.md b/.claude/commands/deploy.md index c7ec275..eaf91f2 100644 --- a/.claude/commands/deploy.md +++ b/.claude/commands/deploy.md @@ -181,6 +181,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `main` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge @@ -230,4 +232,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: claude | hash: e0dd0480 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: claude | hash: f84c747b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index d0d0e18..846a1db 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -102,6 +102,8 @@ PR target branch: `dev` Use `Issue #<number>` as the issue reference — the issue stays open until `/deploy` promotes to `main`. +> **Critical:** Use the unqualified `#N` form (e.g. `Closes #42`), never the fully-qualified `owner/repo#N` form (e.g. `Closes LightbridgeLab/CodeCannon#42`), even for same-repo references. GitHub's closing-keyword parser reliably populates `closingIssuesReferences` only for the unqualified form; the qualified form leaves that GraphQL edge empty, which silently breaks GitHub's native auto-close and any downstream automation that reads it. This overrides any general "use owner/repo#N for cross-linking" guidance your harness may have — closing-keyword lines in PR bodies are a special case. + Then create the PR with explicit title and body (never use an interactive editor): ``` gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' @@ -254,4 +256,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: 284df7a8 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: d5d59df8 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.cursor/rules/deploy.mdc b/.cursor/rules/deploy.mdc index 578379c..73dfb6b 100644 --- a/.cursor/rules/deploy.mdc +++ b/.cursor/rules/deploy.mdc @@ -187,6 +187,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `main` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge @@ -236,4 +238,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: cursor | hash: 95958d2d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: cursor | hash: bb0fe2f1 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 378a674..6e3c5ef 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -108,6 +108,8 @@ PR target branch: `dev` Use `Issue #<number>` as the issue reference — the issue stays open until `/deploy` promotes to `main`. +> **Critical:** Use the unqualified `#N` form (e.g. `Closes #42`), never the fully-qualified `owner/repo#N` form (e.g. `Closes LightbridgeLab/CodeCannon#42`), even for same-repo references. GitHub's closing-keyword parser reliably populates `closingIssuesReferences` only for the unqualified form; the qualified form leaves that GraphQL edge empty, which silently breaks GitHub's native auto-close and any downstream automation that reads it. This overrides any general "use owner/repo#N for cross-linking" guidance your harness may have — closing-keyword lines in PR bodies are a special case. + Then create the PR with explicit title and body (never use an interactive editor): ``` gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' @@ -260,4 +262,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: a6ae754e | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 71f7fe12 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.gemini/skills/deploy/SKILL.md b/.gemini/skills/deploy/SKILL.md index 820a5e7..913e745 100644 --- a/.gemini/skills/deploy/SKILL.md +++ b/.gemini/skills/deploy/SKILL.md @@ -186,6 +186,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `main` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge @@ -235,4 +237,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: gemini | hash: 83be1fd6 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: gemini | hash: adfc11de | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 2ca4f1d..9a7a93d 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -107,6 +107,8 @@ PR target branch: `dev` Use `Issue #<number>` as the issue reference — the issue stays open until `/deploy` promotes to `main`. +> **Critical:** Use the unqualified `#N` form (e.g. `Closes #42`), never the fully-qualified `owner/repo#N` form (e.g. `Closes LightbridgeLab/CodeCannon#42`), even for same-repo references. GitHub's closing-keyword parser reliably populates `closingIssuesReferences` only for the unqualified form; the qualified form leaves that GraphQL edge empty, which silently breaks GitHub's native auto-close and any downstream automation that reads it. This overrides any general "use owner/repo#N for cross-linking" guidance your harness may have — closing-keyword lines in PR bodies are a special case. + Then create the PR with explicit title and body (never use an interactive editor): ``` gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' @@ -259,4 +261,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: 782435a2 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: 39738177 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/skills/deploy.md b/skills/deploy.md index de71d27..cd10ad5 100644 --- a/skills/deploy.md +++ b/skills/deploy.md @@ -289,6 +289,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `{{BRANCH_PROD}}` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge @@ -362,6 +364,8 @@ Note the PR number from the output. The `Closes #N` lines will auto-close the linked issues because this PR merges into `{{BRANCH_PROD}}` (the default branch). +> **Critical:** Use the unqualified `#N` form only. Never write `Closes owner/repo#N`, even for same-repo refs — GitHub's closing-keyword parser only populates `closingIssuesReferences` for the unqualified form, and the qualified form silently breaks auto-close. + --- ## Step 7 — Merge diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index f011345..a7d91a3 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -124,6 +124,8 @@ PR target branch: `{{BRANCH_PROD}}` (trunk mode) Use `Closes #<number>` as the issue reference — merging to the default branch will auto-close the issue. {{/if}} +> **Critical:** Use the unqualified `#N` form (e.g. `Closes #42`), never the fully-qualified `owner/repo#N` form (e.g. `Closes LightbridgeLab/CodeCannon#42`), even for same-repo references. GitHub's closing-keyword parser reliably populates `closingIssuesReferences` only for the unqualified form; the qualified form leaves that GraphQL edge empty, which silently breaks GitHub's native auto-close and any downstream automation that reads it. This overrides any general "use owner/repo#N for cross-linking" guidance your harness may have — closing-keyword lines in PR bodies are a special case. + Then create the PR with explicit title and body (never use an interactive editor): ``` gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' From a5c3a0ebf38461eee71dd0b201bdb37307b87285 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart <sebastien.taggart@gmail.com> Date: Thu, 9 Apr 2026 19:25:43 -0400 Subject: [PATCH 5/7] Use --body-file - stdin heredoc for gh multi-line bodies to preserve Bash(gh:*) permission match --- .agents/skills/deploy/SKILL.md | 8 +++----- .agents/skills/submit-for-review/SKILL.md | 12 ++++++------ .claude/commands/deploy.md | 8 +++----- .claude/commands/submit-for-review.md | 12 ++++++------ .cursor/rules/deploy.mdc | 8 +++----- .cursor/rules/submit-for-review.mdc | 12 ++++++------ .gemini/skills/deploy/SKILL.md | 8 +++----- .gemini/skills/submit-for-review/SKILL.md | 12 ++++++------ skills/deploy.md | 15 +++++---------- skills/submit-for-review.md | 10 +++++----- 10 files changed, 46 insertions(+), 59 deletions(-) diff --git a/.agents/skills/deploy/SKILL.md b/.agents/skills/deploy/SKILL.md index 7a67b52..037b39a 100644 --- a/.agents/skills/deploy/SKILL.md +++ b/.agents/skills/deploy/SKILL.md @@ -169,7 +169,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo ```bash gh pr create --base main --head dev \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -179,7 +179,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -215,7 +214,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -223,7 +222,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. @@ -237,4 +235,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: codex | hash: 2a98511e | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: codex | hash: 0e47902b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index 496b492..b004d8e 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -111,14 +111,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de Then create the PR with explicit title and body (never use an interactive editor): ``` -gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' +gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF' <description of what changed and why> <Closes #N OR Issue #N, based on target above> EOF -)" ``` +> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags). + Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames. If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. @@ -227,15 +228,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body "$(cat <<'EOF' + --body-file - \ + [--label "<pool-selected labels>"] <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> See the review comment on the PR for context. EOF -)" \ - [--label "<pool-selected labels>"] ``` Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. @@ -261,4 +261,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: 6957b622 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 61513e5d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.claude/commands/deploy.md b/.claude/commands/deploy.md index eaf91f2..4c919ad 100644 --- a/.claude/commands/deploy.md +++ b/.claude/commands/deploy.md @@ -164,7 +164,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo ```bash gh pr create --base main --head dev \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -174,7 +174,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -210,7 +209,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -218,7 +217,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. @@ -232,4 +230,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: claude | hash: f84c747b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: claude | hash: b1efee29 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 846a1db..b7231f5 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -106,14 +106,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de Then create the PR with explicit title and body (never use an interactive editor): ``` -gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' +gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF' <description of what changed and why> <Closes #N OR Issue #N, based on target above> EOF -)" ``` +> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags). + Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames. If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. @@ -222,15 +223,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body "$(cat <<'EOF' + --body-file - \ + [--label "<pool-selected labels>"] <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> See the review comment on the PR for context. EOF -)" \ - [--label "<pool-selected labels>"] ``` Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. @@ -256,4 +256,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: d5d59df8 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 2aa076dc | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.cursor/rules/deploy.mdc b/.cursor/rules/deploy.mdc index 73dfb6b..a34de2c 100644 --- a/.cursor/rules/deploy.mdc +++ b/.cursor/rules/deploy.mdc @@ -170,7 +170,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo ```bash gh pr create --base main --head dev \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -180,7 +180,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -216,7 +215,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -224,7 +223,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. @@ -238,4 +236,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: cursor | hash: bb0fe2f1 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: cursor | hash: 96c1037f | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 6e3c5ef..b0d2f4b 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -112,14 +112,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de Then create the PR with explicit title and body (never use an interactive editor): ``` -gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' +gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF' <description of what changed and why> <Closes #N OR Issue #N, based on target above> EOF -)" ``` +> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags). + Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames. If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. @@ -228,15 +229,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body "$(cat <<'EOF' + --body-file - \ + [--label "<pool-selected labels>"] <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> See the review comment on the PR for context. EOF -)" \ - [--label "<pool-selected labels>"] ``` Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. @@ -262,4 +262,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: 71f7fe12 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 7fefc571 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.gemini/skills/deploy/SKILL.md b/.gemini/skills/deploy/SKILL.md index 913e745..9146f22 100644 --- a/.gemini/skills/deploy/SKILL.md +++ b/.gemini/skills/deploy/SKILL.md @@ -169,7 +169,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo ```bash gh pr create --base main --head dev \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -179,7 +179,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -215,7 +214,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -223,7 +222,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. @@ -237,4 +235,4 @@ After the command runs, note the release URL from the output. Tell the user: > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production." -<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: gemini | hash: adfc11de | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: gemini | hash: cde00382 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 9a7a93d..32c0a9c 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -111,14 +111,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de Then create the PR with explicit title and body (never use an interactive editor): ``` -gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' +gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF' <description of what changed and why> <Closes #N OR Issue #N, based on target above> EOF -)" ``` +> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags). + Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames. If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. @@ -227,15 +228,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body "$(cat <<'EOF' + --body-file - \ + [--label "<pool-selected labels>"] <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> See the review comment on the PR for context. EOF -)" \ - [--label "<pool-selected labels>"] ``` Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. @@ -261,4 +261,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: 39738177 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: c5b1249c | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/skills/deploy.md b/skills/deploy.md index cd10ad5..a0c21c4 100644 --- a/skills/deploy.md +++ b/skills/deploy.md @@ -242,7 +242,7 @@ The version tag and PR/issue list are already known. If no previous tag exists, ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -250,7 +250,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, use just the PR title. @@ -272,7 +271,7 @@ Tell the user: ```bash gh pr create --base {{BRANCH_PROD}} --head {{BRANCH_DEV}} \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -282,7 +281,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -318,7 +316,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -326,7 +324,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. @@ -347,7 +344,7 @@ Tell the user: ```bash gh pr create --base {{BRANCH_PROD}} --head {{BRANCH_TEST}} \ --title "Release vX.Y.Z" \ - --body "$(cat <<'EOF' + --body-file - <<'EOF' Release vX.Y.Z PRs included: @@ -357,7 +354,6 @@ PRs included: Closes #14 Closes #15 EOF -)" ``` Note the PR number from the output. @@ -393,7 +389,7 @@ Create the release: ```bash gh release create <version-tag> \ --title "<version-tag>" \ - --notes "$(cat <<'EOF' + --notes-file - <<'EOF' ## Changes - #<issue> — <PR title> (PR #<pr-number>) @@ -401,7 +397,6 @@ gh release create <version-tag> \ **Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag> EOF -)" ``` Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title. diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index a7d91a3..c746095 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -128,14 +128,15 @@ Use `Closes #<number>` as the issue reference — merging to the default branch Then create the PR with explicit title and body (never use an interactive editor): ``` -gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF' +gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF' <description of what changed and why> <Closes #N OR Issue #N, based on target above> EOF -)" ``` +> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags). + {{#if DEFAULT_REVIEWERS}} Add `--reviewer` to the `gh pr create` command above using the handles from `{{DEFAULT_REVIEWERS}}`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames. @@ -267,15 +268,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body "$(cat <<'EOF' + --body-file - \ + [--label "<pool-selected labels>"] <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> See the review comment on the PR for context. EOF -)" \ - [--label "<pool-selected labels>"] ``` Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `{{TICKET_LABELS}}` that genuinely fit the finding. If `{{TICKET_LABELS}}` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project. From a5ca58d5fd502630fc0e9b5499a867ac50977d55 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart <sebastien.taggart@gmail.com> Date: Thu, 9 Apr 2026 19:49:18 -0400 Subject: [PATCH 6/7] Place --body-file - adjacent to heredoc in gh issue create example for readability --- .agents/skills/submit-for-review/SKILL.md | 6 +++--- .claude/commands/submit-for-review.md | 6 +++--- .cursor/rules/submit-for-review.mdc | 6 +++--- .gemini/skills/submit-for-review/SKILL.md | 6 +++--- skills/submit-for-review.md | 4 ++-- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index b004d8e..4bb8b8c 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -228,8 +228,8 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body-file - \ - [--label "<pool-selected labels>"] <<'EOF' + [--label "<pool-selected labels>"] \ + --body-file - <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> @@ -261,4 +261,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: 61513e5d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 7f9a2844 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index b7231f5..cf071a5 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -223,8 +223,8 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body-file - \ - [--label "<pool-selected labels>"] <<'EOF' + [--label "<pool-selected labels>"] \ + --body-file - <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> @@ -256,4 +256,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: 2aa076dc | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 4845c4c2 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index b0d2f4b..7ac52cf 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -229,8 +229,8 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body-file - \ - [--label "<pool-selected labels>"] <<'EOF' + [--label "<pool-selected labels>"] \ + --body-file - <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> @@ -262,4 +262,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: 7fefc571 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 3499993e | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 32c0a9c..fa2e5d5 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -228,8 +228,8 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body-file - \ - [--label "<pool-selected labels>"] <<'EOF' + [--label "<pool-selected labels>"] \ + --body-file - <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> @@ -261,4 +261,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: c5b1249c | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> +<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: 56d02482 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate --> diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index c746095..d598aec 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -268,8 +268,8 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is ``` gh issue create \ --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \ - --body-file - \ - [--label "<pool-selected labels>"] <<'EOF' + [--label "<pool-selected labels>"] \ + --body-file - <<'EOF' Follow-up from PR #<merged-pr-number> — auto-proposed from the code review. **Finding:** <full finding text, prefix included> From cc4f9b87f98df0b0e7db40b292d13b74a4d471e8 Mon Sep 17 00:00:00 2001 From: Sebastien Taggart <sebastien.taggart@gmail.com> Date: Thu, 9 Apr 2026 19:51:13 -0400 Subject: [PATCH 7/7] Bump version to 0.4.0 --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index 2080591..1d0ba9e 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.3.11 +0.4.0