diff --git a/.claude/commands/qa.md b/.claude/commands/qa.md index 1dbb3d4..bab055b 100644 --- a/.claude/commands/qa.md +++ b/.claude/commands/qa.md @@ -1,3 +1,4 @@ + You are executing the `/qa` skill. Your argument is: $ARGUMENTS --- diff --git a/.claude/commands/release.md b/.claude/commands/release.md index 5642a08..c43395c 100644 --- a/.claude/commands/release.md +++ b/.claude/commands/release.md @@ -1,3 +1,4 @@ + You are executing the `/release` skill. Your argument is: $ARGUMENTS --- diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md index f79b347..99d3bee 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -1,3 +1,4 @@ + 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 index 53b3351..bd287f3 100644 --- a/.claude/commands/ship.md +++ b/.claude/commands/ship.md @@ -1,3 +1,4 @@ + You are executing the `/ship` skill. Your argument is: $ARGUMENTS --- diff --git a/.claude/commands/version.md b/.claude/commands/version.md index 8fa03d9..be872a0 100644 --- a/.claude/commands/version.md +++ b/.claude/commands/version.md @@ -1,3 +1,4 @@ + 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 `` 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 index f728b04..9ba5df3 100644 --- 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 index 0caf79c..18f8938 100644 --- 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 index 8eff018..35a372f 100644 --- 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 `` 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 index 1b73214..820ef1d 100644 --- 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.