submit-for-review should apply a configurable ready-for-qa label to the closed issue after merge

[sebastientaggart]

Problem

When /submit-for-review successfully merges a PR, the linked issue is auto-closed by GitHub's closing-keyword and a resolution comment is posted. But no label is applied to the closed issue, so projects that gate human QA on a label (e.g. ready-for-qa) lose track of which closed issues are actually ready to test.

Today the section in submit-for-review.md is even titled "After merge — QA label and success report" but the QA-label step isn't implemented. The success report happens; the label doesn't.

Why it matters

The intended workflow is:

1. PR merges
2. Issue closes
3. Reviewer (human) picks up closed-and-labeled issues from the QA queue
4. Reviewer labels qa-passed or qa-failed

Step 3 currently requires the operator to remember to label each merge by hand. After a multi-PR session that's easy to miss — I just shipped four PRs back-to-back and forgot to label any of them.

Proposed behaviour

After a successful merge in submit-for-review (Step 8's "After merge" path), apply a configurable QA label to the linked issue using gh issue edit <issue-number> --add-label "<value>".

Configuration knob in .codecannon.yaml (suggested key + default):

qa_label: ready-for-qa # set to '' or omit to disable

Skip the label step silently if:

• qa_label is empty / unset
• No linked issue was identified in Step 3 (matches the existing resolution-comment skip)
• The label apply fails (log + continue; do not block the success report)

Acceptance

• After a merge, the closed issue carries the configured QA label.
• When qa_label is unset, behaviour is unchanged from today.
• Failure to apply the label (label doesn't exist in the repo, gh auth issue, etc.) prints a warning but does not roll back the merge or block the
  success report.
• The skill template's "After merge — QA label and success report" section header now matches what the code actually does.

Notes

• Should probably also handle qa-failed / qa-passed removal if the label being applied is ready-for-qa (so re-running on an issue that was
  previously QA'd resets state cleanly), but that's a nice-to-have, not blocking.
• Worth considering whether docs-only PRs should skip the label by default — but that's hard to detect reliably from skill-side; probably leave it to the operator to decide per project.

[sebastientaggart]

Note above was reported on:

cd CodeCannon
git status
HEAD detached at 82d8746
nothing to commit, working tree clean

[sebastientaggart]

Investigation Findings

• Reporter's state was HEAD detached at 82d8746 (v0.3.11, April 2026). Most of the requested behaviour has already landed on dev since then:
  • skills/github-agile/submit-for-review.md has the "After merge — QA label and success report" block with a working gh issue edit <number> --add-label "{{QA_READY_LABEL}}" step, gated on {{#if QA_READY_LABEL}} + {{#if BRANCH_DEV}} + {{#if !BRANCH_TEST}}.
  • config.schema.yaml defines QA_READY_LABEL (default ready-for-qa); .codecannon.yaml sets it; rendered .claude/commands/submit-for-review.md emits the label step correctly for this project.
  • Section title already matches what the prompt does.
• The only acceptance criterion still unmet is: failure to apply the label should warn + continue, not abort the success report. The current prompt is silent on what to do if gh issue edit exits non-zero, which means the LLM would likely halt. This is the minimal change scoped here.
• Considered (and rejected) extracting the label apply into a script — it's one gh call, so wrapping it costs more tokens than it saves. The more useful check (verifying the label exists in the repo at all) is best done once at /setup time, not on every merge. Spun out as Audit configured labels at /setup time and offer to create any missing ones #183.
• Nice-to-haves from the original report (auto-removing qa-passed / qa-failed when re-applying ready-for-qa, docs-only PR detection) remain out of scope for this ticket.

[sebastientaggart]

Resolution

After a successful merge, if the step that tags the closed issue with the configured "ready for QA" label runs into trouble (for example, the label doesn't exist in the repo yet), the workflow now prints a one-line warning and keeps going instead of stopping. The merge has already happened by that point, so surfacing the problem is enough — no need to interrupt the success report or leave the operator wondering whether anything got through. A follow-up ticket (#183) covers checking the labels once at setup time so this failure mode can be avoided up front for new projects.

See #184 for full technical details.