Problem to Fix
When a project is configured with QA labels (QA_READY_LABEL, QA_PASSED_LABEL, QA_FAILED_LABEL) or relies on the issue-creation label pool (bug, documentation, enhancement, chore), nothing checks at setup time that those labels actually exist in the GitHub repository. If a label is missing, downstream skills fail at the worst possible moment — /submit-for-review tries to apply ready-for-qa after a successful merge and the gh issue edit call errors out, requiring the operator to notice, fix, and re-run.
Why it Matters
The labels are static configuration — they don't change between PRs. Re-checking them on every merge is wasted work, but never checking them means the first time a fresh project hits a label-dependent code path, the operator gets a surprise failure. /setup is the natural place to catch this: it already walks first-time configuration end-to-end.
General Approach
During /setup, after configuration is resolved, list the labels the project's skills will rely on (the configured QA labels plus the issue-creation pool) and verify each one exists in the target repo via gh label list. For any missing label, offer to create it on the spot (gh label create) with a sensible default color and description, or warn and continue if the operator declines. This is purely additive — no behaviour change for projects whose labels already exist.
Complexity
Verification / QA effort: moderate
The check itself is one gh label list call, but the interactive create-or-skip flow needs to be exercised against a repo missing one or more labels to confirm it doesn't trip /setup's main path. Manual test on a scratch repo is enough.
Acceptance Criteria
/setup performs a label-existence check for all labels the configured skills will use (QA labels + issue-creation pool).- Missing labels prompt the operator with a one-shot create-or-skip choice, with a default color and description for each known label.
- If the operator skips,
/setup continues without error but surfaces a summary of which labels are missing so the operator knows to expect downstream warnings.
- Projects where every label already exists see no new prompts and no observable change to
/setup.
Notes
Spun out from #182, which is fixing the immediate symptom (/submit-for-review aborting when the QA label apply fails). That fix makes the failure non-blocking, but doing the check at setup time prevents the failure altogether for projects that go through /setup.
Problem to Fix
When a project is configured with QA labels (
QA_READY_LABEL,QA_PASSED_LABEL,QA_FAILED_LABEL) or relies on the issue-creation label pool (bug,documentation,enhancement,chore), nothing checks at setup time that those labels actually exist in the GitHub repository. If a label is missing, downstream skills fail at the worst possible moment —/submit-for-reviewtries to applyready-for-qaafter a successful merge and thegh issue editcall errors out, requiring the operator to notice, fix, and re-run.Why it Matters
The labels are static configuration — they don't change between PRs. Re-checking them on every merge is wasted work, but never checking them means the first time a fresh project hits a label-dependent code path, the operator gets a surprise failure.
/setupis the natural place to catch this: it already walks first-time configuration end-to-end.General Approach
During
/setup, after configuration is resolved, list the labels the project's skills will rely on (the configured QA labels plus the issue-creation pool) and verify each one exists in the target repo viagh label list. For any missing label, offer to create it on the spot (gh label create) with a sensible default color and description, or warn and continue if the operator declines. This is purely additive — no behaviour change for projects whose labels already exist.Complexity
Verification / QA effort: moderate
The check itself is one
gh label listcall, but the interactive create-or-skip flow needs to be exercised against a repo missing one or more labels to confirm it doesn't trip /setup's main path. Manual test on a scratch repo is enough.Acceptance Criteria
/setupperforms a label-existence check for all labels the configured skills will use (QA labels + issue-creation pool)./setupcontinues without error but surfaces a summary of which labels are missing so the operator knows to expect downstream warnings./setup.Notes
Spun out from #182, which is fixing the immediate symptom (
/submit-for-reviewaborting when the QA label apply fails). That fix makes the failure non-blocking, but doing the check at setup time prevents the failure altogether for projects that go through/setup.