diff --git a/.agents/skills/qa/SKILL.md b/.agents/skills/qa/SKILL.md index 27fc421..bc458db 100644 --- a/.agents/skills/qa/SKILL.md +++ b/.agents/skills/qa/SKILL.md @@ -7,11 +7,138 @@ description: View the QA queue or review a specific issue --- -> **QA workflow is not configured.** `/qa` requires `QA_READY_LABEL` to be set in `.codecannon.yaml` so it can find issues waiting for QA. -> -> To enable: add `QA_READY_LABEL: ready-for-qa` (or your preferred label name) to `.codecannon.yaml` and re-run `CodeCanon/sync.sh`. -> -> Note: In trunk mode, `/ship` does not apply this label automatically — you would need to apply it manually or via a separate workflow. - -Do not proceed. Stop here. - +## What `/qa` does + +`/qa` has two modes: + +- **No argument** — show all issues awaiting QA. +- **Numeric argument** — walk through QA review for a specific issue. + +--- + +## Mode A — No argument: QA queue view + +Run: +``` +gh issue list --label "ready-for-qa" --state open \ + --json number,title,url,labels,milestone,assignees +``` + +Display as a numbered list. For each issue show: issue number, title, milestone (if set), and URL. + +If the list is empty, say: + +> "No issues are currently waiting for QA." + +Do not take any other action. + +--- + +## Mode B — Numeric argument: Review a specific issue + +The argument is an issue number. Work through the following steps. + +### Step 1 — Load context + +``` +gh issue view --json number,title,body,labels,url,comments +``` + +Display the issue title and body. + +Check whether `ready-for-qa` is currently applied to the issue. If it is **not** present, warn: + +> "Issue #N does not have the ready-for-qa label. It may not be deployed to preview yet. Continue anyway? (yes/no)" + +Wait. If the user says no, stop. + +--- + +### Step 2 — Review prompt + +Say: + +> "Test this feature on the preview environment. When you're done, describe what you tested, what you found, and your verdict (pass or fail). Include screenshots if you have them — paste image links or drag-and-drop into GitHub directly." + +**Stop. Wait for the QA person's input. Do not proceed until they provide a verdict.** + +--- + +### Step 3 — Post findings as issue comment + +Build a structured comment from their input: + +``` +## QA Review + +**Verdict:** PASS (or FAIL) + +**What was tested:** + + +**Findings:** + + +**Screenshots:** + +``` + +Show the comment to the user before posting. Ask: + +> "Post this to issue #N? (yes/no)" + +Wait for confirmation. On yes: +``` +gh issue comment --body "" +``` + +On no, stop — do not post and do not apply labels. + +--- + +### Step 4 — Apply verdict label + +Based on the verdict: + +**PASS:** +``` +gh issue edit --add-label "qa-passed" --remove-label "ready-for-qa" +``` + +**FAIL:** + +Before applying labels, fetch the issue's current assignees: +``` +gh issue view --json assignees --jq '.assignees[].login' 2>/dev/null +``` + +If one or more assignees are found, prepend the following line to the comment body (above the `## QA Review` heading) in the comment that was already posted: + +> cc @ — this issue needs attention. + +If there are multiple assignees, include one `cc @` per line. If the command errors or returns no results, omit the line silently. + +``` +gh issue edit --add-label "qa-failed" --remove-label "ready-for-qa" +``` + +If the `gh issue edit` command fails because a label does not exist in the repo, report the error and say: + +> "The label does not exist in this repository. Create it in GitHub Settings → Labels, then re-run `/qa ` from Step 4." + +Do not retry automatically. + +After applying labels, tell the user what was done: + +- On PASS: "Issue #N marked as QA passed. The developer can now close it or promote to production." +- On FAIL: "Issue #N marked as QA failed. The developer will see the findings in the issue comments." + +--- + +## Hard rules + +- Never close an issue — verdict recording and closure are separate concerns. +- 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/ship/SKILL.md b/.agents/skills/ship/SKILL.md index 56cd05a..5e4a1db 100644 --- a/.agents/skills/ship/SKILL.md +++ b/.agents/skills/ship/SKILL.md @@ -99,6 +99,9 @@ EOF )" ``` +Add `--reviewer @sebastientaggart` to the `gh pr create` command above. + +If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. **Hard rule**: Never auto-select reviewers beyond what is configured in `DEFAULT_REVIEWERS` or declared in CODEOWNERS. Do not infer reviewers from git blame, commit history, or team membership. @@ -163,6 +166,11 @@ Return to the coding loop. When fixed, run `/ship` again from Step 1. ### After merge — QA label and success report +If a linked issue number was identified in Step 3, apply the QA label: +``` +gh issue edit --add-label "ready-for-qa" +``` +If no linked issue was found, skip silently. Report success based on mode: "PR merged. Issues stay open until testing confirms the fix. Run `make deploy-preview` when ready to deploy to preview." @@ -177,4 +185,4 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/ship` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - + diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md index 33121f7..d8c17ac 100644 --- a/.agents/skills/start/SKILL.md +++ b/.agents/skills/start/SKILL.md @@ -37,7 +37,8 @@ The argument string may contain optional inline flags after the description. Par After parsing flags, determine the active labels in this order: 1. **Per-invocation flag** — if `--label ` was in `$ARGUMENTS`, use that value verbatim. Skip all remaining steps. -2. **Pool-based selection** — no label pool is configured. Fall through to step 3. +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 `false` is `true` (case-insensitive string match): the agent **may** create a new label before applying it: ```bash @@ -46,8 +47,6 @@ After parsing flags, determine the active labels in this order: Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - If `false` is `false` or unset: omit `--label` entirely. Proceed silently; do not inform the user. -> **Tip:** Run `/setup` to populate TICKET_LABELS from your repo's existing GitHub labels. - **Milestone resolution (three-tier, Case A only):** After parsing flags, determine the active milestone in this order: @@ -66,7 +65,7 @@ After parsing flags, determine the active milestone in this order: | `$ARGUMENTS` | Description | Labels | Milestone | |---|---|---|---| -| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | none (no label pool) | auto-detected | +| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | auto-selected from pool | auto-detected | | `Add dark mode --label enhancement` | `Add dark mode` | `enhancement` (verbatim) | auto-detected | | `Add dark mode --label enhancement,ux --milestone "Sprint 4"` | `Add dark mode` | `enhancement,ux` (verbatim) | `Sprint 4` | @@ -227,6 +226,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 labels only when explicitly provided via `--label`. No label pool is configured. +- 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/qa.md b/.claude/commands/qa.md index a61e0a0..b94b5bf 100644 --- a/.claude/commands/qa.md +++ b/.claude/commands/qa.md @@ -2,11 +2,138 @@ View the QA queue or review a specific issue --- -> **QA workflow is not configured.** `/qa` requires `QA_READY_LABEL` to be set in `.codecannon.yaml` so it can find issues waiting for QA. -> -> To enable: add `QA_READY_LABEL: ready-for-qa` (or your preferred label name) to `.codecannon.yaml` and re-run `CodeCanon/sync.sh`. -> -> Note: In trunk mode, `/ship` does not apply this label automatically — you would need to apply it manually or via a separate workflow. - -Do not proceed. Stop here. - +## What `/qa` does + +`/qa` has two modes: + +- **No argument** — show all issues awaiting QA. +- **Numeric argument** — walk through QA review for a specific issue. + +--- + +## Mode A — No argument: QA queue view + +Run: +``` +gh issue list --label "ready-for-qa" --state open \ + --json number,title,url,labels,milestone,assignees +``` + +Display as a numbered list. For each issue show: issue number, title, milestone (if set), and URL. + +If the list is empty, say: + +> "No issues are currently waiting for QA." + +Do not take any other action. + +--- + +## Mode B — Numeric argument: Review a specific issue + +The argument is an issue number. Work through the following steps. + +### Step 1 — Load context + +``` +gh issue view --json number,title,body,labels,url,comments +``` + +Display the issue title and body. + +Check whether `ready-for-qa` is currently applied to the issue. If it is **not** present, warn: + +> "Issue #N does not have the ready-for-qa label. It may not be deployed to preview yet. Continue anyway? (yes/no)" + +Wait. If the user says no, stop. + +--- + +### Step 2 — Review prompt + +Say: + +> "Test this feature on the preview environment. When you're done, describe what you tested, what you found, and your verdict (pass or fail). Include screenshots if you have them — paste image links or drag-and-drop into GitHub directly." + +**Stop. Wait for the QA person's input. Do not proceed until they provide a verdict.** + +--- + +### Step 3 — Post findings as issue comment + +Build a structured comment from their input: + +``` +## QA Review + +**Verdict:** PASS (or FAIL) + +**What was tested:** + + +**Findings:** + + +**Screenshots:** + +``` + +Show the comment to the user before posting. Ask: + +> "Post this to issue #N? (yes/no)" + +Wait for confirmation. On yes: +``` +gh issue comment --body "" +``` + +On no, stop — do not post and do not apply labels. + +--- + +### Step 4 — Apply verdict label + +Based on the verdict: + +**PASS:** +``` +gh issue edit --add-label "qa-passed" --remove-label "ready-for-qa" +``` + +**FAIL:** + +Before applying labels, fetch the issue's current assignees: +``` +gh issue view --json assignees --jq '.assignees[].login' 2>/dev/null +``` + +If one or more assignees are found, prepend the following line to the comment body (above the `## QA Review` heading) in the comment that was already posted: + +> cc @ — this issue needs attention. + +If there are multiple assignees, include one `cc @` per line. If the command errors or returns no results, omit the line silently. + +``` +gh issue edit --add-label "qa-failed" --remove-label "ready-for-qa" +``` + +If the `gh issue edit` command fails because a label does not exist in the repo, report the error and say: + +> "The label does not exist in this repository. Create it in GitHub Settings → Labels, then re-run `/qa ` from Step 4." + +Do not retry automatically. + +After applying labels, tell the user what was done: + +- On PASS: "Issue #N marked as QA passed. The developer can now close it or promote to production." +- On FAIL: "Issue #N marked as QA failed. The developer will see the findings in the issue comments." + +--- + +## Hard rules + +- Never close an issue — verdict recording and closure are separate concerns. +- 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/ship.md b/.claude/commands/ship.md index e13fed0..baffeae 100644 --- a/.claude/commands/ship.md +++ b/.claude/commands/ship.md @@ -94,6 +94,9 @@ EOF )" ``` +Add `--reviewer @sebastientaggart` to the `gh pr create` command above. + +If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. **Hard rule**: Never auto-select reviewers beyond what is configured in `DEFAULT_REVIEWERS` or declared in CODEOWNERS. Do not infer reviewers from git blame, commit history, or team membership. @@ -158,6 +161,11 @@ Return to the coding loop. When fixed, run `/ship` again from Step 1. ### After merge — QA label and success report +If a linked issue number was identified in Step 3, apply the QA label: +``` +gh issue edit --add-label "ready-for-qa" +``` +If no linked issue was found, skip silently. Report success based on mode: "PR merged. Issues stay open until testing confirms the fix. Run `make deploy-preview` when ready to deploy to preview." @@ -172,4 +180,4 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/ship` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - + diff --git a/.claude/commands/start.md b/.claude/commands/start.md index 14983a6..3a5a64d 100644 --- a/.claude/commands/start.md +++ b/.claude/commands/start.md @@ -32,7 +32,8 @@ The argument string may contain optional inline flags after the description. Par After parsing flags, determine the active labels in this order: 1. **Per-invocation flag** — if `--label ` was in `$ARGUMENTS`, use that value verbatim. Skip all remaining steps. -2. **Pool-based selection** — no label pool is configured. Fall through to step 3. +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 `false` is `true` (case-insensitive string match): the agent **may** create a new label before applying it: ```bash @@ -41,8 +42,6 @@ After parsing flags, determine the active labels in this order: Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - If `false` is `false` or unset: omit `--label` entirely. Proceed silently; do not inform the user. -> **Tip:** Run `/setup` to populate TICKET_LABELS from your repo's existing GitHub labels. - **Milestone resolution (three-tier, Case A only):** After parsing flags, determine the active milestone in this order: @@ -61,7 +60,7 @@ After parsing flags, determine the active milestone in this order: | `$ARGUMENTS` | Description | Labels | Milestone | |---|---|---|---| -| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | none (no label pool) | auto-detected | +| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | auto-selected from pool | auto-detected | | `Add dark mode --label enhancement` | `Add dark mode` | `enhancement` (verbatim) | auto-detected | | `Add dark mode --label enhancement,ux --milestone "Sprint 4"` | `Add dark mode` | `enhancement,ux` (verbatim) | `Sprint 4` | @@ -222,6 +221,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 labels only when explicitly provided via `--label`. No label pool is configured. +- 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/.codecannon.yaml b/.codecannon.yaml index de64149..f778699 100644 --- a/.codecannon.yaml +++ b/.codecannon.yaml @@ -32,12 +32,12 @@ config: BUMP_MAJOR_CMD: make bump-major SET_VERSION_CMD: "make set-version V=" REVIEW_AGENT_PROMPT: .claude/review-agent-prompt.md - DEFAULT_REVIEWERS: "" - TICKET_LABELS: "" + DEFAULT_REVIEWERS: "@sebastientaggart" + TICKET_LABELS: "bug, documentation, enhancement, chore" TICKET_LABEL_CREATION_ALLOWED: "false" DEFAULT_MILESTONE: "" - QA_READY_LABEL: "" - QA_PASSED_LABEL: "" - QA_FAILED_LABEL: "" + QA_READY_LABEL: "ready-for-qa" + QA_PASSED_LABEL: "qa-passed" + QA_FAILED_LABEL: "qa-failed" PLATFORM_COMPLIANCE_NOTES: "" CONVENTIONS_NOTES: "" diff --git a/.cursor/rules/qa.mdc b/.cursor/rules/qa.mdc index ba53587..05ca798 100644 --- a/.cursor/rules/qa.mdc +++ b/.cursor/rules/qa.mdc @@ -8,11 +8,138 @@ alwaysApply: false --- -> **QA workflow is not configured.** `/qa` requires `QA_READY_LABEL` to be set in `.codecannon.yaml` so it can find issues waiting for QA. -> -> To enable: add `QA_READY_LABEL: ready-for-qa` (or your preferred label name) to `.codecannon.yaml` and re-run `CodeCanon/sync.sh`. -> -> Note: In trunk mode, `/ship` does not apply this label automatically — you would need to apply it manually or via a separate workflow. - -Do not proceed. Stop here. - +## What `/qa` does + +`/qa` has two modes: + +- **No argument** — show all issues awaiting QA. +- **Numeric argument** — walk through QA review for a specific issue. + +--- + +## Mode A — No argument: QA queue view + +Run: +``` +gh issue list --label "ready-for-qa" --state open \ + --json number,title,url,labels,milestone,assignees +``` + +Display as a numbered list. For each issue show: issue number, title, milestone (if set), and URL. + +If the list is empty, say: + +> "No issues are currently waiting for QA." + +Do not take any other action. + +--- + +## Mode B — Numeric argument: Review a specific issue + +The argument is an issue number. Work through the following steps. + +### Step 1 — Load context + +``` +gh issue view --json number,title,body,labels,url,comments +``` + +Display the issue title and body. + +Check whether `ready-for-qa` is currently applied to the issue. If it is **not** present, warn: + +> "Issue #N does not have the ready-for-qa label. It may not be deployed to preview yet. Continue anyway? (yes/no)" + +Wait. If the user says no, stop. + +--- + +### Step 2 — Review prompt + +Say: + +> "Test this feature on the preview environment. When you're done, describe what you tested, what you found, and your verdict (pass or fail). Include screenshots if you have them — paste image links or drag-and-drop into GitHub directly." + +**Stop. Wait for the QA person's input. Do not proceed until they provide a verdict.** + +--- + +### Step 3 — Post findings as issue comment + +Build a structured comment from their input: + +``` +## QA Review + +**Verdict:** PASS (or FAIL) + +**What was tested:** + + +**Findings:** + + +**Screenshots:** + +``` + +Show the comment to the user before posting. Ask: + +> "Post this to issue #N? (yes/no)" + +Wait for confirmation. On yes: +``` +gh issue comment --body "" +``` + +On no, stop — do not post and do not apply labels. + +--- + +### Step 4 — Apply verdict label + +Based on the verdict: + +**PASS:** +``` +gh issue edit --add-label "qa-passed" --remove-label "ready-for-qa" +``` + +**FAIL:** + +Before applying labels, fetch the issue's current assignees: +``` +gh issue view --json assignees --jq '.assignees[].login' 2>/dev/null +``` + +If one or more assignees are found, prepend the following line to the comment body (above the `## QA Review` heading) in the comment that was already posted: + +> cc @ — this issue needs attention. + +If there are multiple assignees, include one `cc @` per line. If the command errors or returns no results, omit the line silently. + +``` +gh issue edit --add-label "qa-failed" --remove-label "ready-for-qa" +``` + +If the `gh issue edit` command fails because a label does not exist in the repo, report the error and say: + +> "The label does not exist in this repository. Create it in GitHub Settings → Labels, then re-run `/qa ` from Step 4." + +Do not retry automatically. + +After applying labels, tell the user what was done: + +- On PASS: "Issue #N marked as QA passed. The developer can now close it or promote to production." +- On FAIL: "Issue #N marked as QA failed. The developer will see the findings in the issue comments." + +--- + +## Hard rules + +- Never close an issue — verdict recording and closure are separate concerns. +- 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/ship.mdc b/.cursor/rules/ship.mdc index 01dbec9..29187ab 100644 --- a/.cursor/rules/ship.mdc +++ b/.cursor/rules/ship.mdc @@ -100,6 +100,9 @@ EOF )" ``` +Add `--reviewer @sebastientaggart` to the `gh pr create` command above. + +If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. **Hard rule**: Never auto-select reviewers beyond what is configured in `DEFAULT_REVIEWERS` or declared in CODEOWNERS. Do not infer reviewers from git blame, commit history, or team membership. @@ -164,6 +167,11 @@ Return to the coding loop. When fixed, run `/ship` again from Step 1. ### After merge — QA label and success report +If a linked issue number was identified in Step 3, apply the QA label: +``` +gh issue edit --add-label "ready-for-qa" +``` +If no linked issue was found, skip silently. Report success based on mode: "PR merged. Issues stay open until testing confirms the fix. Run `make deploy-preview` when ready to deploy to preview." @@ -178,4 +186,4 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/ship` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - + diff --git a/.cursor/rules/start.mdc b/.cursor/rules/start.mdc index 3ac7f85..771c602 100644 --- a/.cursor/rules/start.mdc +++ b/.cursor/rules/start.mdc @@ -38,7 +38,8 @@ The argument string may contain optional inline flags after the description. Par After parsing flags, determine the active labels in this order: 1. **Per-invocation flag** — if `--label ` was in `$ARGUMENTS`, use that value verbatim. Skip all remaining steps. -2. **Pool-based selection** — no label pool is configured. Fall through to step 3. +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 `false` is `true` (case-insensitive string match): the agent **may** create a new label before applying it: ```bash @@ -47,8 +48,6 @@ After parsing flags, determine the active labels in this order: Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - If `false` is `false` or unset: omit `--label` entirely. Proceed silently; do not inform the user. -> **Tip:** Run `/setup` to populate TICKET_LABELS from your repo's existing GitHub labels. - **Milestone resolution (three-tier, Case A only):** After parsing flags, determine the active milestone in this order: @@ -67,7 +66,7 @@ After parsing flags, determine the active milestone in this order: | `$ARGUMENTS` | Description | Labels | Milestone | |---|---|---|---| -| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | none (no label pool) | auto-detected | +| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | auto-selected from pool | auto-detected | | `Add dark mode --label enhancement` | `Add dark mode` | `enhancement` (verbatim) | auto-detected | | `Add dark mode --label enhancement,ux --milestone "Sprint 4"` | `Add dark mode` | `enhancement,ux` (verbatim) | `Sprint 4` | @@ -228,6 +227,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 labels only when explicitly provided via `--label`. No label pool is configured. +- 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/qa/SKILL.md b/.gemini/skills/qa/SKILL.md index 01ec99a..46ad04a 100644 --- a/.gemini/skills/qa/SKILL.md +++ b/.gemini/skills/qa/SKILL.md @@ -7,11 +7,138 @@ description: View the QA queue or review a specific issue --- -> **QA workflow is not configured.** `/qa` requires `QA_READY_LABEL` to be set in `.codecannon.yaml` so it can find issues waiting for QA. -> -> To enable: add `QA_READY_LABEL: ready-for-qa` (or your preferred label name) to `.codecannon.yaml` and re-run `CodeCanon/sync.sh`. -> -> Note: In trunk mode, `/ship` does not apply this label automatically — you would need to apply it manually or via a separate workflow. - -Do not proceed. Stop here. - +## What `/qa` does + +`/qa` has two modes: + +- **No argument** — show all issues awaiting QA. +- **Numeric argument** — walk through QA review for a specific issue. + +--- + +## Mode A — No argument: QA queue view + +Run: +``` +gh issue list --label "ready-for-qa" --state open \ + --json number,title,url,labels,milestone,assignees +``` + +Display as a numbered list. For each issue show: issue number, title, milestone (if set), and URL. + +If the list is empty, say: + +> "No issues are currently waiting for QA." + +Do not take any other action. + +--- + +## Mode B — Numeric argument: Review a specific issue + +The argument is an issue number. Work through the following steps. + +### Step 1 — Load context + +``` +gh issue view --json number,title,body,labels,url,comments +``` + +Display the issue title and body. + +Check whether `ready-for-qa` is currently applied to the issue. If it is **not** present, warn: + +> "Issue #N does not have the ready-for-qa label. It may not be deployed to preview yet. Continue anyway? (yes/no)" + +Wait. If the user says no, stop. + +--- + +### Step 2 — Review prompt + +Say: + +> "Test this feature on the preview environment. When you're done, describe what you tested, what you found, and your verdict (pass or fail). Include screenshots if you have them — paste image links or drag-and-drop into GitHub directly." + +**Stop. Wait for the QA person's input. Do not proceed until they provide a verdict.** + +--- + +### Step 3 — Post findings as issue comment + +Build a structured comment from their input: + +``` +## QA Review + +**Verdict:** PASS (or FAIL) + +**What was tested:** + + +**Findings:** + + +**Screenshots:** + +``` + +Show the comment to the user before posting. Ask: + +> "Post this to issue #N? (yes/no)" + +Wait for confirmation. On yes: +``` +gh issue comment --body "" +``` + +On no, stop — do not post and do not apply labels. + +--- + +### Step 4 — Apply verdict label + +Based on the verdict: + +**PASS:** +``` +gh issue edit --add-label "qa-passed" --remove-label "ready-for-qa" +``` + +**FAIL:** + +Before applying labels, fetch the issue's current assignees: +``` +gh issue view --json assignees --jq '.assignees[].login' 2>/dev/null +``` + +If one or more assignees are found, prepend the following line to the comment body (above the `## QA Review` heading) in the comment that was already posted: + +> cc @ — this issue needs attention. + +If there are multiple assignees, include one `cc @` per line. If the command errors or returns no results, omit the line silently. + +``` +gh issue edit --add-label "qa-failed" --remove-label "ready-for-qa" +``` + +If the `gh issue edit` command fails because a label does not exist in the repo, report the error and say: + +> "The label does not exist in this repository. Create it in GitHub Settings → Labels, then re-run `/qa ` from Step 4." + +Do not retry automatically. + +After applying labels, tell the user what was done: + +- On PASS: "Issue #N marked as QA passed. The developer can now close it or promote to production." +- On FAIL: "Issue #N marked as QA failed. The developer will see the findings in the issue comments." + +--- + +## Hard rules + +- Never close an issue — verdict recording and closure are separate concerns. +- 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/ship/SKILL.md b/.gemini/skills/ship/SKILL.md index af140b4..1cd81f0 100644 --- a/.gemini/skills/ship/SKILL.md +++ b/.gemini/skills/ship/SKILL.md @@ -99,6 +99,9 @@ EOF )" ``` +Add `--reviewer @sebastientaggart` to the `gh pr create` command above. + +If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top. **Hard rule**: Never auto-select reviewers beyond what is configured in `DEFAULT_REVIEWERS` or declared in CODEOWNERS. Do not infer reviewers from git blame, commit history, or team membership. @@ -163,6 +166,11 @@ Return to the coding loop. When fixed, run `/ship` again from Step 1. ### After merge — QA label and success report +If a linked issue number was identified in Step 3, apply the QA label: +``` +gh issue edit --add-label "ready-for-qa" +``` +If no linked issue was found, skip silently. Report success based on mode: "PR merged. Issues stay open until testing confirms the fix. Run `make deploy-preview` when ready to deploy to preview." @@ -177,4 +185,4 @@ Report success based on mode: - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass. - `/ship` merges only to `dev` — never directly to `main`. - If `make merge` fails for any reason, report it and stop — do not attempt workarounds. - + diff --git a/.gemini/skills/start/SKILL.md b/.gemini/skills/start/SKILL.md index fee409b..2dc5b90 100644 --- a/.gemini/skills/start/SKILL.md +++ b/.gemini/skills/start/SKILL.md @@ -37,7 +37,8 @@ The argument string may contain optional inline flags after the description. Par After parsing flags, determine the active labels in this order: 1. **Per-invocation flag** — if `--label ` was in `$ARGUMENTS`, use that value verbatim. Skip all remaining steps. -2. **Pool-based selection** — no label pool is configured. Fall through to step 3. +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 `false` is `true` (case-insensitive string match): the agent **may** create a new label before applying it: ```bash @@ -46,8 +47,6 @@ After parsing flags, determine the active labels in this order: Use judgment — only create a label with clear reuse value. Do not create near-duplicates of existing pool labels. - If `false` is `false` or unset: omit `--label` entirely. Proceed silently; do not inform the user. -> **Tip:** Run `/setup` to populate TICKET_LABELS from your repo's existing GitHub labels. - **Milestone resolution (three-tier, Case A only):** After parsing flags, determine the active milestone in this order: @@ -66,7 +65,7 @@ After parsing flags, determine the active milestone in this order: | `$ARGUMENTS` | Description | Labels | Milestone | |---|---|---|---| -| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | none (no label pool) | auto-detected | +| `Add dark mode toggle to settings page` | `Add dark mode toggle to settings page` | auto-selected from pool | auto-detected | | `Add dark mode --label enhancement` | `Add dark mode` | `enhancement` (verbatim) | auto-detected | | `Add dark mode --label enhancement,ux --milestone "Sprint 4"` | `Add dark mode` | `enhancement,ux` (verbatim) | `Sprint 4` | @@ -227,6 +226,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 labels only when explicitly provided via `--label`. No label pool is configured. +- 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. - +