Release v0.2.0

.claude/commands/qa.md

@@ -1,10 +1,10 @@
-<!-- generated by CodeCanon/sync.sh | skill: qa | adapter: claude | hash: 28f81c85 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
+<!-- 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
 
 ---
 
 <!-- Mode note: The QA label workflow is primarily used in two-branch mode, where ``
-     is applied by `/ship` after merging to ``. In trunk or three-branch mode, this label
+     is applied by `/ship` after merging to `dev`. In trunk or three-branch mode, this label
      is not applied automatically by `/ship` — set `` only if you have a manual or
      future-skill-driven QA gate. -->
 
@@ -159,3 +159,4 @@ After applying labels, tell the user what was done:
 - 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.
+<!-- generated by CodeCanon/sync.sh | skill: qa | adapter: claude | hash: 447216d6 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/release.md

@@ -1,4 +1,4 @@
-<!-- generated by CodeCanon/sync.sh | skill: release | adapter: claude | hash: ce0df502 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
+<!-- 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
 
 ---
@@ -17,9 +17,9 @@ git branch --show-current
 ```
 
 **Determine mode:**
-- If `` is empty → **Trunk Mode**. Follow the Trunk Mode section below.
-- If `` is set but `` is empty → **Two-Branch Mode**. Follow the Two-Branch Mode section below.
-- If both `` and `` are set → **Three-Branch Mode**. Follow the Three-Branch Mode section below.
+- If `dev` is empty → **Trunk Mode**. Follow the Trunk Mode section below.
+- If `dev` is set but `` is empty → **Two-Branch Mode**. Follow the Two-Branch Mode section below.
+- If both `dev` and `` are set → **Three-Branch Mode**. Follow the Three-Branch Mode section below.
 
 ---
 
@@ -116,9 +116,9 @@ Tell the user:
 
 ### Step 1 — Verify state
 
-If not on ``, switch to it:
+If not on `dev`, switch to it:
 ```bash
-git checkout  && git pull
+git checkout dev && git pull
 ```
 
 Verify a version tag exists on HEAD:
@@ -130,9 +130,9 @@ If no tag is found, warn: "No version tag found on HEAD. Run `/version` first to
 
 ### Step 2 — Compute what's being promoted
 
-Find all merge commits in `` not yet in `main`:
+Find all merge commits in `dev` not yet in `main`:
 ```bash
-git log main.. --merges --pretty=format:"%s"
+git log main..dev --merges --pretty=format:"%s"
 ```
 
 Parse PR numbers from the merge commit subjects. GitHub's format is:
@@ -169,10 +169,10 @@ Have you tested all of the above on preview? Type 'release' to confirm.
 
 Wait for the user to type "release" or an explicit confirmation. Any other response → stop and ask what they'd like to change.
 
-### Step 4 — Create PR: `` → `main`
+### Step 4 — Create PR: `dev` → `main`
 
 ```bash
-gh pr create --base main --head  \
+gh pr create --base main --head dev \
   --title "Release vX.Y.Z" \
   --body "$(cat <<'EOF'
 Release vX.Y.Z
@@ -260,7 +260,7 @@ Find all merge commits in `` not yet in `main`:
 git log main.. --merges --pretty=format:"%s"
 ```
 
-Parse PR numbers from the merge commit subjects. Note: some merge commits here may be promotion merges from `` — these are identifiable by subjects matching "Merge ... from ``". Include them in the list but note they are promotion merges; extract the original feature PRs from their PR bodies when possible.
+Parse PR numbers from the merge commit subjects. Note: some merge commits here may be promotion merges from `dev` — these are identifiable by subjects matching "Merge ... from `dev`". Include them in the list but note they are promotion merges; extract the original feature PRs from their PR bodies when possible.
 
 For each PR number found, retrieve the PR body:
 ```bash
@@ -358,3 +358,4 @@ After the command runs, note the release URL from the output.
 Tell the user:
 
 > "Released vX.Y.Z. Issues #N, #M closed automatically. GitHub Release vX.Y.Z created at `<url>`. Run `make deploy-prod` to ship to production."
+<!-- generated by CodeCanon/sync.sh | skill: release | adapter: claude | hash: b470d522 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/review.md

@@ -1,4 +1,3 @@
-<!-- generated by CodeCanon/sync.sh | skill: review | adapter: claude | hash: 06aee22d | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/review` skill. Your argument is: $ARGUMENTS
 
 ---
@@ -55,3 +54,4 @@ After the review agent completes, relay its verdict to the user:
 - This command does not commit, push, or merge anything. It only reviews.
 - It may be called manually at any time, not just from `/ship`.
 - The review comment is posted to GitHub for the audit trail.
+<!-- generated by CodeCanon/sync.sh | skill: review | adapter: claude | hash: 06aee22d | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/setup.md

@@ -1,4 +1,4 @@
-<!-- generated by CodeCanon/sync.sh | skill: setup | adapter: claude | hash: bdb21058 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
+<!-- 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
 
 ---
@@ -281,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:
 
 ```
@@ -328,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."
@@ -424,3 +470,4 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri
 - Never fetch more than 100 labels in a single command. `gh label list --limit 100` is the ceiling.
 - Do not skip any human gate in Phase 2 or Phase 3 — each write requires confirmation.
 - If the user skips a config value, do not ask again. Move on.
+<!-- generated by CodeCanon/sync.sh | skill: setup | adapter: claude | hash: bdb21058 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/ship.md

@@ -1,4 +1,4 @@
-<!-- generated by CodeCanon/sync.sh | skill: ship | adapter: claude | hash: b7dd6237 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
+<!-- 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
 
 ---
@@ -24,7 +24,7 @@ git branch --show-current
 
 Determine which branches are protected (i.e., not a feature branch):
 - Always: `main`
-- If `` is non-empty: also ``
+- If `dev` is non-empty: also `dev`
 - If `` is non-empty: also ``
 
 If the current branch matches any of the above, **abort immediately** and say:
@@ -89,7 +89,7 @@ git ls-files CODEOWNERS .github/CODEOWNERS docs/CODEOWNERS 2>/dev/null
 If the output is non-empty, inform the user: "CODEOWNERS file detected — GitHub will automatically request reviews from code owners."
 
 Determine the PR target branch:
-- If `` is non-empty, target `` (two-branch or three-branch mode).
+- If `dev` is non-empty, target `dev` (two-branch or three-branch mode).
 - Otherwise, target `main` (trunk mode).
 
 Determine the issue reference format:
@@ -132,7 +132,7 @@ Wait for the review agent to complete and report its verdict.
 ## Step 7 — Act on verdict
 
 Determine merge command (used by all paths below):
-- If in **trunk mode** (`` is empty): use `gh pr merge <number> --merge` directly — `make merge` may refuse merges targeting `main`.
+- If in **trunk mode** (`dev` is empty): use `gh pr merge <number> --merge` directly — `make merge` may refuse merges targeting `main`.
 - Otherwise: use `make merge`.
 
 ---
@@ -169,7 +169,7 @@ Return to the coding loop. When fixed, run `/ship` again from Step 1.
 
 ### After merge — QA label and success report
 
-Apply the QA label only in **two-branch mode** (`` is set AND `` is empty):
+Apply the QA label only in **two-branch mode** (`dev` is set AND `` is empty):
 - If `` is non-empty AND a linked issue number was identified in Step 3:
   ```
   gh issue edit <number> --add-label ""
@@ -180,7 +180,7 @@ Apply the QA label only in **two-branch mode** (`` is set AND `` is empty):
 Report success based on mode:
 - **Trunk mode**: "PR merged. Issue #N closed automatically. Run `make deploy-prod` when ready to deploy to production."
 - **Two-branch mode**: "PR merged. Issues stay open until testing confirms the fix. Run `make deploy-preview` when ready to deploy to preview."
-- **Three-branch mode**: "PR merged to ``. Promote to `` when ready for staging."
+- **Three-branch mode**: "PR merged to `dev`. Promote to `` when ready for staging."
 
 ---
 
@@ -190,5 +190,6 @@ Report success based on mode:
 - When `ai` is `"ai"`, never merge if the review verdict is REQUEST CHANGES.
 - When `ai` is `"advisory"`, always merge after review completes, regardless of verdict.
 - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass.
-- In trunk mode, merges target `main`. Otherwise, `/ship` merges only to `` — never directly to `` or `main`.
+- In trunk mode, merges target `main`. Otherwise, `/ship` merges only to `dev` — never directly to `` or `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
+<!-- generated by CodeCanon/sync.sh | skill: ship | adapter: claude | hash: d98aef47 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/start.md

@@ -1,4 +1,3 @@
-<!-- generated by CodeCanon/sync.sh | skill: start | adapter: claude | hash: 24909c1a | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/start` skill. Your argument is: $ARGUMENTS
 
 ---
@@ -209,3 +208,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor.
 - The issue is assigned to `@me` at creation. If you are creating a ticket on someone else's behalf, remove the assignee after creation with `gh issue edit <number> --remove-assignee @me`.
 - Apply resolved labels and milestone to every new issue. Label resolution order: per-invocation flag → pool selection from `` → omit (or create if `false` is `true`). Never apply a label not in `` unless `false` is `true`. Milestone resolution order: per-invocation flag → `` config → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
+<!-- generated by CodeCanon/sync.sh | skill: start | adapter: claude | hash: 24909c1a | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/status.md

@@ -1,4 +1,3 @@
-<!-- generated by CodeCanon/sync.sh | skill: status | adapter: claude | hash: 3e7a06c3 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 You are executing the `/status` skill. Your argument is: $ARGUMENTS
 
 ---
@@ -176,3 +175,4 @@ Do not post, comment, write files, or take any action. Output only.
 - If `gh` is unauthenticated or any fetch fails, report the error and stop immediately.
 - Do not retry failed commands.
 - Strip the leading `@` from the subject when passing to `gh` flags that do not accept it.
+<!-- generated by CodeCanon/sync.sh | skill: status | adapter: claude | hash: 3e7a06c3 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/commands/version.md

@@ -1,4 +1,4 @@
-<!-- generated by CodeCanon/sync.sh | skill: version | adapter: claude | hash: 664c0da3 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
+<!-- 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
 
 ---
@@ -12,11 +12,16 @@ git branch --show-current
 
 Determine the required branch:
 - If `` is non-empty → required branch is `` (three-branch mode).
-- Else if `` is non-empty → required branch is `` (two-branch mode).
+- Else if `dev` is non-empty → required branch is `dev` (two-branch mode).
 - Else → required branch is `main` (trunk mode).
 
 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
@@ -72,6 +77,7 @@ Both the version bump commit and the tag must be pushed.
 Tell the user the new version and tag:
 
 Report based on mode:
-- **Trunk mode** (`` empty): "Tagged vX.Y.Z. Run `/release` to create the GitHub Release."
-- **Two-branch mode** (`` set, `` empty): "Tagged vX.Y.Z. Run `make deploy-preview` to deploy to preview for testing. When testing is complete, run `/release`."
+- **Trunk mode** (`dev` empty): "Tagged vX.Y.Z. Run `/release` to create the GitHub Release."
+- **Two-branch mode** (`dev` set, `` empty): "Tagged vX.Y.Z. Run `make deploy-preview` to deploy to preview for testing. When testing is complete, run `/release`."
 - **Three-branch mode** (both set): "Tagged vX.Y.Z. Run `make deploy-preview` to deploy to staging. When testing is complete, run `/release`."
+<!-- generated by CodeCanon/sync.sh | skill: version | adapter: claude | hash: 955517c9 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->

.claude/review-agent-prompt.md

@@ -1,4 +1,3 @@
-<!-- generated by CodeCanon/sync.sh | skill: review-agent | adapter: claude | hash: df853bb2 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->
 # Code Review Agent Prompt
 
 You are a code review agent for this project. You review feature branch pull requests before they are merged.
@@ -106,3 +105,4 @@ If no findings: "No issues found. Code looks correct and follows project convent
 - Do not suggest improvements outside the scope of the PR.
 - Do not re-review files that haven't changed.
 - Your review is posted to GitHub for the audit trail — keep it professional.
+<!-- generated by CodeCanon/sync.sh | skill: review-agent | adapter: claude | hash: df853bb2 | DO NOT EDIT — run CodeCanon/sync.sh to regenerate -->