diff --git a/.agents/skills/deploy/SKILL.md b/.agents/skills/deploy/SKILL.md index 274faa4..9ca68c1 100644 --- a/.agents/skills/deploy/SKILL.md +++ b/.agents/skills/deploy/SKILL.md @@ -1,6 +1,6 @@ --- name: deploy -description: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step +description: Code Cannon: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -235,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 ``. Run `make deploy-prod` to ship to production." - + diff --git a/.agents/skills/qa/SKILL.md b/.agents/skills/qa/SKILL.md index 79cb5ff..3caff8a 100644 --- a/.agents/skills/qa/SKILL.md +++ b/.agents/skills/qa/SKILL.md @@ -1,6 +1,6 @@ --- name: qa -description: View the QA queue or review a specific issue +description: Code Cannon: View the QA queue or review a specific issue --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -141,4 +141,4 @@ After applying labels, tell the user what was done: - Never post the comment without showing it to the user first. - Never apply labels without user confirmation (the confirmation in Step 3 is the single gate for both posting the comment and applying labels). - Never merge, deploy, or take any action beyond labeling and commenting. - + diff --git a/.agents/skills/review/SKILL.md b/.agents/skills/review/SKILL.md index 1e8617a..3b05b77 100644 --- a/.agents/skills/review/SKILL.md +++ b/.agents/skills/review/SKILL.md @@ -1,6 +1,6 @@ --- name: review -description: Run a standalone code review on a pull request +description: Code Cannon: Run a standalone code review on a pull request --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -65,4 +65,4 @@ After the review agent completes, relay its verdict to the user: - This command does not commit, push, or merge anything. It only reviews. - It may be called manually at any time, not just from `/submit-for-review`. - The review comment is posted to GitHub for the audit trail. - + diff --git a/.agents/skills/setup/SKILL.md b/.agents/skills/setup/SKILL.md index 7c0c4dc..25e82cc 100644 --- a/.agents/skills/setup/SKILL.md +++ b/.agents/skills/setup/SKILL.md @@ -1,6 +1,6 @@ --- name: setup -description: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values +description: Code Cannon: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -475,4 +475,4 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. - Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 08e8f5d..088a9f0 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -1,6 +1,6 @@ --- name: start -description: Start a new feature or bugfix +description: Code Cannon: Start a new feature or bugfix --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -230,4 +230,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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`. - 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/status/SKILL.md b/.agents/skills/status/SKILL.md index e9afa6c..1be68e0 100644 --- a/.agents/skills/status/SKILL.md +++ b/.agents/skills/status/SKILL.md @@ -1,6 +1,6 @@ --- name: status -description: Summarize in-progress and recently completed work from GitHub and git +description: Code Cannon: Summarize in-progress and recently completed work from GitHub and git --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -241,4 +241,4 @@ Do not post, comment, write files, or take any action. Output only. - If `gh` is unauthenticated or any fetch fails, report the error and stop immediately. - Do not retry failed commands. - Strip the leading `@` from the subject when passing to `gh` flags that do not accept it. - + diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index f90b34a..35afd88 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.agents/skills/submit-for-review/SKILL.md @@ -1,6 +1,6 @@ --- name: submit-for-review -description: Type-check, commit, open PR, review, and merge to the integration branch +description: Code Cannon: Type-check, commit, open PR, review, and merge to the integration branch --- > **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline. @@ -200,6 +200,56 @@ Report success based on mode: --- +## Step 9 — Offer follow-up issues for non-blocking findings + +**Gate this step entirely** if any of the following are true: +- `ai` is `"off"` (no review was performed). +- The merge in Step 8 did not actually happen (e.g. `ai` mode with REQUEST CHANGES). +- The review output contains no non-blocking findings. + +**Collect non-blocking findings** from the review output retained from Step 7: +- Always include lines starting with `[WARNING]` or `[NOTE]`. +- If `ai` is `"advisory"`, also include any `[CRITICAL]` lines — the user chose to merge over them, so they are now follow-up candidates too. +- If `ai` is `"ai"`, do not include `[CRITICAL]` lines (there should not be any on the merge path, but guard anyway). + +If the collected list is empty, skip the rest of this step silently. + +**Present and ask once.** Show the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` / `[CRITICAL]` prefix in the display for clarity) and ask exactly: + +> "The review flagged N non-blocking finding(s). Create follow-up issues for any of them? Enter numbers (e.g. `1,3`), `all`, or `none`." + +Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is unparseable, re-prompt once; if still invalid, treat as `none` and move on. + +**Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags: + +``` +gh issue create \ + --title "" \ + --body "$(cat <<'EOF' +Follow-up from PR # — auto-proposed from the code review. + +**Finding:** + +See the review comment on the PR for context. +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`. + +Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. + +Do **not** pass `--assignee @me` — these are backlog items, not immediately assigned. + +If a single `gh issue create` call fails, report the failure for that finding and continue with the remaining selections. + +**Report the result:** +- If one or more issues were created: `"Created N follow-up issue(s): #X, #Y, #Z"`. +- If the user chose `none` or all creations were skipped: say nothing further, proceed to end. + +--- + ## Important constraints - Never skip `make check`. A failed check is a hard stop. @@ -208,4 +258,5 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/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/deploy.md b/.claude/commands/deploy.md index 3cf9838..c7ec275 100644 --- a/.claude/commands/deploy.md +++ b/.claude/commands/deploy.md @@ -1,4 +1,4 @@ -Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step +Code Cannon: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step --- @@ -230,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 ``. Run `make deploy-prod` to ship to production." - + diff --git a/.claude/commands/qa.md b/.claude/commands/qa.md index 6e5cbc2..7a09d4d 100644 --- a/.claude/commands/qa.md +++ b/.claude/commands/qa.md @@ -1,4 +1,4 @@ -View the QA queue or review a specific issue +Code Cannon: View the QA queue or review a specific issue --- @@ -136,4 +136,4 @@ After applying labels, tell the user what was done: - Never post the comment without showing it to the user first. - Never apply labels without user confirmation (the confirmation in Step 3 is the single gate for both posting the comment and applying labels). - Never merge, deploy, or take any action beyond labeling and commenting. - + diff --git a/.claude/commands/review.md b/.claude/commands/review.md index 1e44882..6be83ca 100644 --- a/.claude/commands/review.md +++ b/.claude/commands/review.md @@ -1,4 +1,4 @@ -Run a standalone code review on a pull request +Code Cannon: Run a standalone code review on a pull request --- @@ -60,4 +60,4 @@ After the review agent completes, relay its verdict to the user: - This command does not commit, push, or merge anything. It only reviews. - It may be called manually at any time, not just from `/submit-for-review`. - The review comment is posted to GitHub for the audit trail. - + diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md index 884406f..8813884 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -1,4 +1,4 @@ -Detect setup state, guide first-time configuration, populate labels, and walk through optional config values +Code Cannon: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values --- @@ -470,4 +470,4 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. - Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index d587b2e..9d9b0a9 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -1,4 +1,4 @@ -Start a new feature or bugfix +Code Cannon: Start a new feature or bugfix --- @@ -225,4 +225,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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`. - 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/status.md b/.claude/commands/status.md index d3dfca6..cab7d0b 100644 --- a/.claude/commands/status.md +++ b/.claude/commands/status.md @@ -1,4 +1,4 @@ -Summarize in-progress and recently completed work from GitHub and git +Code Cannon: Summarize in-progress and recently completed work from GitHub and git --- @@ -236,4 +236,4 @@ Do not post, comment, write files, or take any action. Output only. - If `gh` is unauthenticated or any fetch fails, report the error and stop immediately. - Do not retry failed commands. - Strip the leading `@` from the subject when passing to `gh` flags that do not accept it. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index a77f02c..585ce7d 100644 --- a/.claude/commands/submit-for-review.md +++ b/.claude/commands/submit-for-review.md @@ -1,4 +1,4 @@ -Type-check, commit, open PR, review, and merge to the integration branch +Code Cannon: Type-check, commit, open PR, review, and merge to the integration branch --- @@ -195,6 +195,56 @@ Report success based on mode: --- +## Step 9 — Offer follow-up issues for non-blocking findings + +**Gate this step entirely** if any of the following are true: +- `ai` is `"off"` (no review was performed). +- The merge in Step 8 did not actually happen (e.g. `ai` mode with REQUEST CHANGES). +- The review output contains no non-blocking findings. + +**Collect non-blocking findings** from the review output retained from Step 7: +- Always include lines starting with `[WARNING]` or `[NOTE]`. +- If `ai` is `"advisory"`, also include any `[CRITICAL]` lines — the user chose to merge over them, so they are now follow-up candidates too. +- If `ai` is `"ai"`, do not include `[CRITICAL]` lines (there should not be any on the merge path, but guard anyway). + +If the collected list is empty, skip the rest of this step silently. + +**Present and ask once.** Show the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` / `[CRITICAL]` prefix in the display for clarity) and ask exactly: + +> "The review flagged N non-blocking finding(s). Create follow-up issues for any of them? Enter numbers (e.g. `1,3`), `all`, or `none`." + +Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is unparseable, re-prompt once; if still invalid, treat as `none` and move on. + +**Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags: + +``` +gh issue create \ + --title "" \ + --body "$(cat <<'EOF' +Follow-up from PR # — auto-proposed from the code review. + +**Finding:** + +See the review comment on the PR for context. +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`. + +Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. + +Do **not** pass `--assignee @me` — these are backlog items, not immediately assigned. + +If a single `gh issue create` call fails, report the failure for that finding and continue with the remaining selections. + +**Report the result:** +- If one or more issues were created: `"Created N follow-up issue(s): #X, #Y, #Z"`. +- If the user chose `none` or all creations were skipped: say nothing further, proceed to end. + +--- + ## Important constraints - Never skip `make check`. A failed check is a hard stop. @@ -203,4 +253,5 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/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/review-agent-prompt.md b/.claude/review-agent-prompt.md index 4477634..8c167c1 100644 --- a/.claude/review-agent-prompt.md +++ b/.claude/review-agent-prompt.md @@ -91,6 +91,8 @@ Post your review as a PR comment via `gh pr comment` with a body structured like If no findings: "No issues found. Code looks correct and follows project conventions." ``` +**Phrasing rule for all findings (CRITICAL, WARNING, and NOTE):** Write each one as a self-contained sentence that would make sense as a standalone ticket title — no "see above", "same as previous", or references to other findings. Non-blocking findings may be converted into follow-up GitHub issues after merge, and CRITICAL findings are promoted to follow-up issue titles when the review runs in advisory mode; vague phrasing produces unusable tickets in either case. + ## Decision Rules - **APPROVE** if there are no CRITICAL findings. Warnings and notes are acceptable. @@ -105,4 +107,4 @@ If no findings: "No issues found. Code looks correct and follows project convent - Do not suggest improvements outside the scope of the PR. - Do not re-review files that haven't changed. - Your review is posted to GitHub for the audit trail — keep it professional. - + diff --git a/.cursor/rules/deploy.mdc b/.cursor/rules/deploy.mdc index c9a8a4a..578379c 100644 --- a/.cursor/rules/deploy.mdc +++ b/.cursor/rules/deploy.mdc @@ -1,5 +1,5 @@ --- -description: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step +description: Code Cannon: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step globs: alwaysApply: false --- @@ -236,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 ``. Run `make deploy-prod` to ship to production." - + diff --git a/.cursor/rules/qa.mdc b/.cursor/rules/qa.mdc index 778a80f..d5e2f97 100644 --- a/.cursor/rules/qa.mdc +++ b/.cursor/rules/qa.mdc @@ -1,5 +1,5 @@ --- -description: View the QA queue or review a specific issue +description: Code Cannon: View the QA queue or review a specific issue globs: alwaysApply: false --- @@ -142,4 +142,4 @@ After applying labels, tell the user what was done: - Never post the comment without showing it to the user first. - Never apply labels without user confirmation (the confirmation in Step 3 is the single gate for both posting the comment and applying labels). - Never merge, deploy, or take any action beyond labeling and commenting. - + diff --git a/.cursor/rules/review.mdc b/.cursor/rules/review.mdc index 3834fc8..76f26ec 100644 --- a/.cursor/rules/review.mdc +++ b/.cursor/rules/review.mdc @@ -1,5 +1,5 @@ --- -description: Run a standalone code review on a pull request +description: Code Cannon: Run a standalone code review on a pull request globs: alwaysApply: false --- @@ -66,4 +66,4 @@ After the review agent completes, relay its verdict to the user: - This command does not commit, push, or merge anything. It only reviews. - It may be called manually at any time, not just from `/submit-for-review`. - The review comment is posted to GitHub for the audit trail. - + diff --git a/.cursor/rules/setup.mdc b/.cursor/rules/setup.mdc index 3809a98..9067bc7 100644 --- a/.cursor/rules/setup.mdc +++ b/.cursor/rules/setup.mdc @@ -1,5 +1,5 @@ --- -description: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values +description: Code Cannon: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values globs: alwaysApply: false --- @@ -476,4 +476,4 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. - Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 84b5b46..bf1ee94 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -1,5 +1,5 @@ --- -description: Start a new feature or bugfix +description: Code Cannon: Start a new feature or bugfix globs: alwaysApply: false --- @@ -231,4 +231,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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`. - 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/status.mdc b/.cursor/rules/status.mdc index b94dd3b..084b206 100644 --- a/.cursor/rules/status.mdc +++ b/.cursor/rules/status.mdc @@ -1,5 +1,5 @@ --- -description: Summarize in-progress and recently completed work from GitHub and git +description: Code Cannon: Summarize in-progress and recently completed work from GitHub and git globs: alwaysApply: false --- @@ -242,4 +242,4 @@ Do not post, comment, write files, or take any action. Output only. - If `gh` is unauthenticated or any fetch fails, report the error and stop immediately. - Do not retry failed commands. - Strip the leading `@` from the subject when passing to `gh` flags that do not accept it. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 0ff6a75..0645d89 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.cursor/rules/submit-for-review.mdc @@ -1,5 +1,5 @@ --- -description: Type-check, commit, open PR, review, and merge to the integration branch +description: Code Cannon: Type-check, commit, open PR, review, and merge to the integration branch globs: alwaysApply: false --- @@ -201,6 +201,56 @@ Report success based on mode: --- +## Step 9 — Offer follow-up issues for non-blocking findings + +**Gate this step entirely** if any of the following are true: +- `ai` is `"off"` (no review was performed). +- The merge in Step 8 did not actually happen (e.g. `ai` mode with REQUEST CHANGES). +- The review output contains no non-blocking findings. + +**Collect non-blocking findings** from the review output retained from Step 7: +- Always include lines starting with `[WARNING]` or `[NOTE]`. +- If `ai` is `"advisory"`, also include any `[CRITICAL]` lines — the user chose to merge over them, so they are now follow-up candidates too. +- If `ai` is `"ai"`, do not include `[CRITICAL]` lines (there should not be any on the merge path, but guard anyway). + +If the collected list is empty, skip the rest of this step silently. + +**Present and ask once.** Show the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` / `[CRITICAL]` prefix in the display for clarity) and ask exactly: + +> "The review flagged N non-blocking finding(s). Create follow-up issues for any of them? Enter numbers (e.g. `1,3`), `all`, or `none`." + +Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is unparseable, re-prompt once; if still invalid, treat as `none` and move on. + +**Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags: + +``` +gh issue create \ + --title "" \ + --body "$(cat <<'EOF' +Follow-up from PR # — auto-proposed from the code review. + +**Finding:** + +See the review comment on the PR for context. +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`. + +Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. + +Do **not** pass `--assignee @me` — these are backlog items, not immediately assigned. + +If a single `gh issue create` call fails, report the failure for that finding and continue with the remaining selections. + +**Report the result:** +- If one or more issues were created: `"Created N follow-up issue(s): #X, #Y, #Z"`. +- If the user chose `none` or all creations were skipped: say nothing further, proceed to end. + +--- + ## Important constraints - Never skip `make check`. A failed check is a hard stop. @@ -209,4 +259,5 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/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/deploy/SKILL.md b/.gemini/skills/deploy/SKILL.md index be52f23..820a5e7 100644 --- a/.gemini/skills/deploy/SKILL.md +++ b/.gemini/skills/deploy/SKILL.md @@ -1,6 +1,6 @@ --- name: deploy -description: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step +description: Code Cannon: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -235,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 ``. Run `make deploy-prod` to ship to production." - + diff --git a/.gemini/skills/qa/SKILL.md b/.gemini/skills/qa/SKILL.md index 5e768dc..c0a1c01 100644 --- a/.gemini/skills/qa/SKILL.md +++ b/.gemini/skills/qa/SKILL.md @@ -1,6 +1,6 @@ --- name: qa -description: View the QA queue or review a specific issue +description: Code Cannon: View the QA queue or review a specific issue --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -141,4 +141,4 @@ After applying labels, tell the user what was done: - Never post the comment without showing it to the user first. - Never apply labels without user confirmation (the confirmation in Step 3 is the single gate for both posting the comment and applying labels). - Never merge, deploy, or take any action beyond labeling and commenting. - + diff --git a/.gemini/skills/review/SKILL.md b/.gemini/skills/review/SKILL.md index 539095c..6ed1327 100644 --- a/.gemini/skills/review/SKILL.md +++ b/.gemini/skills/review/SKILL.md @@ -1,6 +1,6 @@ --- name: review -description: Run a standalone code review on a pull request +description: Code Cannon: Run a standalone code review on a pull request --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -65,4 +65,4 @@ After the review agent completes, relay its verdict to the user: - This command does not commit, push, or merge anything. It only reviews. - It may be called manually at any time, not just from `/submit-for-review`. - The review comment is posted to GitHub for the audit trail. - + diff --git a/.gemini/skills/setup/SKILL.md b/.gemini/skills/setup/SKILL.md index c91640b..cf649b8 100644 --- a/.gemini/skills/setup/SKILL.md +++ b/.gemini/skills/setup/SKILL.md @@ -1,6 +1,6 @@ --- name: setup -description: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values +description: Code Cannon: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -475,4 +475,4 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling. - Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation. - If the user skips a config value, do not ask again. Move on. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index ec15781..9c5712d 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -1,6 +1,6 @@ --- name: start -description: Start a new feature or bugfix +description: Code Cannon: Start a new feature or bugfix --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -230,4 +230,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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`. - 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/status/SKILL.md b/.gemini/skills/status/SKILL.md index dab504d..0fbfbfc 100644 --- a/.gemini/skills/status/SKILL.md +++ b/.gemini/skills/status/SKILL.md @@ -1,6 +1,6 @@ --- name: status -description: Summarize in-progress and recently completed work from GitHub and git +description: Code Cannon: Summarize in-progress and recently completed work from GitHub and git --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -241,4 +241,4 @@ Do not post, comment, write files, or take any action. Output only. - If `gh` is unauthenticated or any fetch fails, report the error and stop immediately. - Do not retry failed commands. - Strip the leading `@` from the subject when passing to `gh` flags that do not accept it. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 0ebead7..7d074ba 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.gemini/skills/submit-for-review/SKILL.md @@ -1,6 +1,6 @@ --- name: submit-for-review -description: Type-check, commit, open PR, review, and merge to the integration branch +description: Code Cannon: Type-check, commit, open PR, review, and merge to the integration branch --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. @@ -200,6 +200,56 @@ Report success based on mode: --- +## Step 9 — Offer follow-up issues for non-blocking findings + +**Gate this step entirely** if any of the following are true: +- `ai` is `"off"` (no review was performed). +- The merge in Step 8 did not actually happen (e.g. `ai` mode with REQUEST CHANGES). +- The review output contains no non-blocking findings. + +**Collect non-blocking findings** from the review output retained from Step 7: +- Always include lines starting with `[WARNING]` or `[NOTE]`. +- If `ai` is `"advisory"`, also include any `[CRITICAL]` lines — the user chose to merge over them, so they are now follow-up candidates too. +- If `ai` is `"ai"`, do not include `[CRITICAL]` lines (there should not be any on the merge path, but guard anyway). + +If the collected list is empty, skip the rest of this step silently. + +**Present and ask once.** Show the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` / `[CRITICAL]` prefix in the display for clarity) and ask exactly: + +> "The review flagged N non-blocking finding(s). Create follow-up issues for any of them? Enter numbers (e.g. `1,3`), `all`, or `none`." + +Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is unparseable, re-prompt once; if still invalid, treat as `none` and move on. + +**Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags: + +``` +gh issue create \ + --title "" \ + --body "$(cat <<'EOF' +Follow-up from PR # — auto-proposed from the code review. + +**Finding:** + +See the review comment on the PR for context. +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`. + +Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. + +Do **not** pass `--assignee @me` — these are backlog items, not immediately assigned. + +If a single `gh issue create` call fails, report the failure for that finding and continue with the remaining selections. + +**Report the result:** +- If one or more issues were created: `"Created N follow-up issue(s): #X, #Y, #Z"`. +- If the user chose `none` or all creations were skipped: say nothing further, proceed to end. + +--- + ## Important constraints - Never skip `make check`. A failed check is a hard stop. @@ -208,4 +258,5 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/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/VERSION b/VERSION index c2c0004..449d7e7 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.3.5 +0.3.6 diff --git a/skills/deploy.md b/skills/deploy.md index 9f6c087..de71d27 100644 --- a/skills/deploy.md +++ b/skills/deploy.md @@ -1,7 +1,7 @@ --- skill: deploy type: skill -description: "Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step" +description: "Code Cannon: Bump the project version, create a GitHub Release, and promote to production — handles both versioning and releasing in one step" args: none --- diff --git a/skills/qa.md b/skills/qa.md index 8a4f575..0512bb5 100644 --- a/skills/qa.md +++ b/skills/qa.md @@ -1,7 +1,7 @@ --- skill: qa type: skill -description: View the QA queue or review a specific issue +description: "Code Cannon: View the QA queue or review a specific issue" args: "none | issue number" --- diff --git a/skills/review-agent.md b/skills/review-agent.md index fb1603d..33ff33e 100644 --- a/skills/review-agent.md +++ b/skills/review-agent.md @@ -103,6 +103,8 @@ Post your review as a PR comment via `gh pr comment` with a body structured like If no findings: "No issues found. Code looks correct and follows project conventions." ``` +**Phrasing rule for all findings (CRITICAL, WARNING, and NOTE):** Write each one as a self-contained sentence that would make sense as a standalone ticket title — no "see above", "same as previous", or references to other findings. Non-blocking findings may be converted into follow-up GitHub issues after merge, and CRITICAL findings are promoted to follow-up issue titles when the review runs in advisory mode; vague phrasing produces unusable tickets in either case. + ## Decision Rules - **APPROVE** if there are no CRITICAL findings. Warnings and notes are acceptable. diff --git a/skills/review.md b/skills/review.md index 2b65ca1..d9834af 100644 --- a/skills/review.md +++ b/skills/review.md @@ -1,7 +1,7 @@ --- skill: review type: skill -description: Run a standalone code review on a pull request +description: "Code Cannon: Run a standalone code review on a pull request" args: "PR number (optional — defaults to current branch's open PR)" --- diff --git a/skills/setup.md b/skills/setup.md index c1dd9b7..dc20c5d 100644 --- a/skills/setup.md +++ b/skills/setup.md @@ -1,7 +1,7 @@ --- skill: setup type: skill -description: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values +description: "Code Cannon: Detect setup state, guide first-time configuration, populate labels, and walk through optional config values" args: none --- diff --git a/skills/start.md b/skills/start.md index 449f20c..23aad3f 100644 --- a/skills/start.md +++ b/skills/start.md @@ -1,7 +1,7 @@ --- skill: start type: skill -description: Start a new feature or bugfix +description: "Code Cannon: Start a new feature or bugfix" args: "feature description or issue number" --- diff --git a/skills/status.md b/skills/status.md index 7542feb..9e462c5 100644 --- a/skills/status.md +++ b/skills/status.md @@ -1,6 +1,6 @@ --- skill: status -description: Summarize in-progress and recently completed work from GitHub and git +description: "Code Cannon: Summarize in-progress and recently completed work from GitHub and git" args: "optional: lookback days (e.g. 14), a GitHub username (@alice), or --milestone " --- diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index 1a96785..92a8ce4 100644 --- a/skills/submit-for-review.md +++ b/skills/submit-for-review.md @@ -1,7 +1,7 @@ --- skill: submit-for-review type: skill -description: Type-check, commit, open PR, review, and merge to the integration branch +description: "Code Cannon: Type-check, commit, open PR, review, and merge to the integration branch" args: none --- @@ -240,6 +240,56 @@ Report success based on mode: --- +## Step 9 — Offer follow-up issues for non-blocking findings + +**Gate this step entirely** if any of the following are true: +- `{{REVIEW_GATE}}` is `"off"` (no review was performed). +- The merge in Step 8 did not actually happen (e.g. `ai` mode with REQUEST CHANGES). +- The review output contains no non-blocking findings. + +**Collect non-blocking findings** from the review output retained from Step 7: +- Always include lines starting with `[WARNING]` or `[NOTE]`. +- If `{{REVIEW_GATE}}` is `"advisory"`, also include any `[CRITICAL]` lines — the user chose to merge over them, so they are now follow-up candidates too. +- If `{{REVIEW_GATE}}` is `"ai"`, do not include `[CRITICAL]` lines (there should not be any on the merge path, but guard anyway). + +If the collected list is empty, skip the rest of this step silently. + +**Present and ask once.** Show the findings as a numbered list (preserve the `[WARNING]` / `[NOTE]` / `[CRITICAL]` prefix in the display for clarity) and ask exactly: + +> "The review flagged N non-blocking finding(s). Create follow-up issues for any of them? Enter numbers (e.g. `1,3`), `all`, or `none`." + +Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is unparseable, re-prompt once; if still invalid, treat as `none` and move on. + +**Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags: + +``` +gh issue create \ + --title "" \ + --body "$(cat <<'EOF' +Follow-up from PR # — auto-proposed from the code review. + +**Finding:** + +See the review comment on the PR for context. +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}}`. + +Do **not** pass `--milestone` — follow-ups are future work and should not inherit the current sprint. + +Do **not** pass `--assignee @me` — these are backlog items, not immediately assigned. + +If a single `gh issue create` call fails, report the failure for that finding and continue with the remaining selections. + +**Report the result:** +- If one or more issues were created: `"Created N follow-up issue(s): #X, #Y, #Z"`. +- If the user chose `none` or all creations were skipped: say nothing further, proceed to end. + +--- + ## Important constraints - Never skip `{{CHECK_CMD}}`. A failed check is a hard stop. @@ -253,3 +303,4 @@ Report success based on mode: - Merges target `{{BRANCH_PROD}}` (trunk mode). {{/if}} - If `{{MERGE_CMD}}` 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.