LightbridgeLab · sebastientaggart · Mar 25, 2026 · Mar 25, 2026 · Mar 25, 2026
diff --git a/.claude/commands/qa.md b/.claude/commands/qa.md
@@ -1,3 +1,4 @@
+<!-- generated by CodeCanon/sync.sh | skill: qa | adapter: claude | hash: 447216d6 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/qa` skill. Your argument is: $ARGUMENTS
 
 ---

diff --git a/.claude/commands/release.md b/.claude/commands/release.md
@@ -1,3 +1,4 @@
+<!-- generated by CodeCanon/sync.sh | skill: release | adapter: claude | hash: b470d522 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/release` skill. Your argument is: $ARGUMENTS
 
 ---

diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md
@@ -1,3 +1,4 @@
+<!-- generated by CodeCanon/sync.sh | skill: setup | adapter: claude | hash: 5e26ca1c | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/setup` skill. Your argument is: $ARGUMENTS
 
 ---
@@ -280,6 +281,30 @@ Run:
 gh label list --limit 100 --json name,color,description
 ```
 
+If zero labels are found, treat this as a greenfield repository and offer a starter label baseline before asking about `TICKET_LABELS`.
+
+Show this recommendation:
+
+```
+No labels were found. For new projects, a practical baseline is:
+  - bug
+  - enhancement
+  - chore
+  - documentation
+  - ready-for-qa
+  - qa-passed
+  - qa-failed
+```
+
+Ask: **"Create any missing labels from this baseline now? (yes/no)"**
+
+Wait for response.
+
+- **yes** → create missing labels only (do not recreate existing labels). Use sensible colors and short descriptions.
+- **no / skip / anything else** → continue without creating labels.
+
+After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again and continue with the numbered list flow below.
+
 Display the results as a numbered list:
 
 ```
@@ -327,6 +352,28 @@ The walkthrough adapts based on profile. Walk through each applicable unset opti
 
 ---
 
+### Greenfield GitHub baseline guidance (for PM/BA setup)
+
+Before the value walkthrough, provide this mini guide when either condition is true:
+- `TICKET_LABELS` is unset, or
+- fewer than 5 labels exist in the repository.
+
+Keep it short and practical:
+
+1. Explain that `/start` works best with a clear issue-label pool (`TICKET_LABELS`) and `/qa` needs explicit QA lifecycle labels.
+2. Recommend this baseline label set for new projects:
+   - Work intake: `bug`, `enhancement`, `chore`, `documentation`
+   - QA lifecycle: `ready-for-qa`, `qa-passed`, `qa-failed`
+   - Optional planning: one lightweight priority scheme (for example `priority:high`, `priority:medium`, `priority:low`)
+3. Explain milestone guidance:
+   - If the team runs planned iterations, set `DEFAULT_MILESTONE` (example: `Sprint 12` or `Release 2026.04`).
+   - If not, leave it unset so `/start` auto-detects open milestones and prompts only when needed.
+4. End with: "Want me to help apply this baseline now during setup? (yes/no)"
+
+If user says no, continue immediately with the normal walkthrough.
+
+---
+
 **DEFAULT_MILESTONE** (Governed and Custom only)
 
 "Sets the default milestone applied to every issue `/start` creates — skip if you're not using milestones or prefer auto-detect."

diff --git a/.claude/commands/ship.md b/.claude/commands/ship.md
@@ -1,3 +1,4 @@
+<!-- generated by CodeCanon/sync.sh | skill: ship | adapter: claude | hash: d98aef47 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/ship` skill. Your argument is: $ARGUMENTS
 
 ---

diff --git a/.claude/commands/version.md b/.claude/commands/version.md
@@ -1,3 +1,4 @@
+<!-- generated by CodeCanon/sync.sh | skill: version | adapter: claude | hash: ab8011ef | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/version` skill. Your argument is: $ARGUMENTS
 
 ---
@@ -16,6 +17,11 @@ Determine the required branch:
 
 If not on the required branch, abort and say: "Switch to `<required-branch>` before running `/version`."
 
+Pull the latest changes before proceeding:
+```bash
+git pull
+```
+
 ---
 
 ## Step 2 — Read current version

diff --git a/README.md b/README.md
@@ -44,6 +44,24 @@ Plus `/qa` for structured QA workflows and `/setup` for guided onboarding.
 
 **Every change has a ticket.** There is no path for code without an issue. The issue is the unit of work — branch, PR, and release all link back to it.
 
+## GitHub baseline for PM/BA setup
+
+If your repo is new and you want predictable behavior from `/start` and `/qa`, configure a minimal GitHub baseline before day-to-day usage:
+
+- **Starter labels for issue intake:** `bug`, `enhancement`, `chore`, `documentation`
+- **QA lifecycle labels:** `ready-for-qa`, `qa-passed`, `qa-failed`
+- **Optional planning labels:** a single priority scheme (for example `priority:high`, `priority:medium`, `priority:low`)
+
+How this maps to Code Cannon behavior:
+
+- `/start` uses `TICKET_LABELS` as its allowed label pool when creating issues.
+- `/qa` depends on `QA_READY_LABEL` to build the QA queue and applies `QA_PASSED_LABEL` or `QA_FAILED_LABEL` as verdicts.
+- Milestones can stay dynamic (auto-detected from GitHub open milestones) or be pinned using `DEFAULT_MILESTONE` when your team runs fixed iterations (for example `Sprint 12` or `Release 2026.04`).
+
+For first-time setup, run `/setup`; it can populate labels and walk through these options interactively.
+
+**Reviewer selection is never automatic.** `/ship` adds reviewers only from two sources: a detected `CODEOWNERS` file (checked in `CODEOWNERS`, `.github/CODEOWNERS`, and `docs/CODEOWNERS`) and the `DEFAULT_REVIEWERS` config key. The agent never infers reviewers from git history, blame, or team membership.
+
 **Configure, don't fork.** Skills use `{{PLACEHOLDER}}` tokens for project-specific values. Your `.codecannon.yaml` fills them in. When upstream skills improve, pull the submodule and re-sync.
 
 **Agent-agnostic.** Skills are written once. Adapters handle the translation to Claude Code, Cursor, or any future agent.

diff --git a/skills/setup.md b/skills/setup.md
@@ -283,6 +283,30 @@ Run:
 gh label list --limit 100 --json name,color,description
 ```
 
+If zero labels are found, treat this as a greenfield repository and offer a starter label baseline before asking about `TICKET_LABELS`.
+
+Show this recommendation:
+
+```
+No labels were found. For new projects, a practical baseline is:
+  - bug
+  - enhancement
+  - chore
+  - documentation
+  - ready-for-qa
+  - qa-passed
+  - qa-failed
+```
+
+Ask: **"Create any missing labels from this baseline now? (yes/no)"**
+
+Wait for response.
+
+- **yes** → create missing labels only (do not recreate existing labels). Use sensible colors and short descriptions.
+- **no / skip / anything else** → continue without creating labels.
+
+After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again and continue with the numbered list flow below.
+
 Display the results as a numbered list:
 
 ```
@@ -330,6 +354,28 @@ The walkthrough adapts based on profile. Walk through each applicable unset opti
 
 ---
 
+### Greenfield GitHub baseline guidance (for PM/BA setup)
+
+Before the value walkthrough, provide this mini guide when either condition is true:
+- `TICKET_LABELS` is unset, or
+- fewer than 5 labels exist in the repository.
+
+Keep it short and practical:
+
+1. Explain that `/start` works best with a clear issue-label pool (`TICKET_LABELS`) and `/qa` needs explicit QA lifecycle labels.
+2. Recommend this baseline label set for new projects:
+   - Work intake: `bug`, `enhancement`, `chore`, `documentation`
+   - QA lifecycle: `ready-for-qa`, `qa-passed`, `qa-failed`
+   - Optional planning: one lightweight priority scheme (for example `priority:high`, `priority:medium`, `priority:low`)
+3. Explain milestone guidance:
+   - If the team runs planned iterations, set `DEFAULT_MILESTONE` (example: `Sprint 12` or `Release 2026.04`).
+   - If not, leave it unset so `/start` auto-detects open milestones and prompts only when needed.
+4. End with: "Want me to help apply this baseline now during setup? (yes/no)"
+
+If user says no, continue immediately with the normal walkthrough.
+
+---
+
 **DEFAULT_MILESTONE** (Governed and Custom only)
 
 "Sets the default milestone applied to every issue `/start` creates — skip if you're not using milestones or prefer auto-detect."

diff --git a/skills/version.md b/skills/version.md
@@ -19,6 +19,11 @@ Determine the required branch:
 
 If not on the required branch, abort and say: "Switch to `<required-branch>` before running `/version`."
 
+Pull the latest changes before proceeding:
+```bash
+git pull
+```
+
 ---
 
 ## Step 2 — Read current version

diff --git a/templates/codecannon.yaml b/templates/codecannon.yaml
@@ -55,6 +55,13 @@ config:
   REVIEW_AGENT_PROMPT: .claude/review-agent-prompt.md
 
   # ── GitHub / PR settings ─────────────────────────────────────────────────────
+  # Greenfield quick baseline (PM/BA friendly):
+  #   1) Labels: bug, enhancement, chore, documentation, ready-for-qa, qa-passed, qa-failed
+  #   2) Put work-intake labels in TICKET_LABELS so /start can triage new issues consistently.
+  #   3) Set QA_READY_LABEL / QA_PASSED_LABEL / QA_FAILED_LABEL if you want /qa status labeling.
+  #   4) Set DEFAULT_MILESTONE only when you want all /start tickets pinned by default
+  #      (for example "Sprint 12" or "Release 2026.04"); otherwise leave it unset for auto-detect.
+  #
   # Comma-separated GitHub handles or team slugs assigned as PR reviewers by /ship.
   # Accepts usernames (@alice), team slugs (org/team-name), or combinations.
   # Leave empty (or omit) to rely solely on CODEOWNERS or manual assignment.