qa

{{#if !QA_READY_LABEL}}

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 CodeCannon/sync.py.

Note: In trunk mode, /submit-for-review does not apply this label automatically — you would need to apply it manually or via a separate workflow.

Do not proceed. Stop here. {{/if}} {{#if QA_READY_LABEL}}

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 "{{QA_READY_LABEL}}" --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 <number> --json number,title,body,labels,url,comments

Display the issue title and body.

Check whether {{QA_READY_LABEL}} is currently applied to the issue. If it is not present, warn:

"Issue #N does not have the {{QA_READY_LABEL}} 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:**
<their description>

**Findings:**
<their findings, or "None — feature works as expected.">

**Screenshots:**
<image links if provided, or "None attached.">

Show the comment to the user before posting. Ask:

"Post this to issue #N? (yes/no)"

Wait for confirmation. On yes:

gh issue comment <number> --body "<comment>"

On no, stop — do not post and do not apply labels.

Step 4 — Apply verdict label

Based on the verdict:

PASS: {{#if QA_PASSED_LABEL}}

gh issue edit <number> --add-label "{{QA_PASSED_LABEL}}" --remove-label "{{QA_READY_LABEL}}"

{{/if}} {{#if !QA_PASSED_LABEL}}

gh issue edit <number> --remove-label "{{QA_READY_LABEL}}"

{{/if}}

FAIL:

Before applying labels, fetch the issue's current assignees:

gh issue view <number> --json assignees

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 @<assignee> — this issue needs attention.

If there are multiple assignees, include one cc @<login> per line. If the command errors or returns no results, omit the line silently.

{{#if QA_FAILED_LABEL}}

gh issue edit <number> --add-label "{{QA_FAILED_LABEL}}" --remove-label "{{QA_READY_LABEL}}"

{{/if}} {{#if !QA_FAILED_LABEL}}

gh issue edit <number> --remove-label "{{QA_READY_LABEL}}"

{{/if}}

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 <number> 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. {{/if}}