Release v0.6.0

.agents/skills/delegate/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: delegate
+description: Code Cannon: Generate a scoped prompt for delegating work to another agent
+---
+
+> **Codex CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — perform any review steps inline.
+
+---
+
+## What `/delegate` does
+
+`/delegate` generates a ready-to-paste prompt that gives another AI agent everything it needs to contribute code on the current branch. Run it during the planning gate of `/start` (Step 2), before saying `go`, to carve off part of the work for another agent.
+
+Each `/delegate` invocation also tells the lead agent to skip that work when it proceeds.
+
+---
+
+## Prerequisites
+
+`/delegate` relies on context already loaded by `/start`. If you are not in the middle of a `/start` planning gate (Case A Step 2 or Case B Step 2), say:
+
+> "`/delegate` is meant to be run during the planning step of `/start`, before you type `go`. Run `/start` first to load the issue context, then use `/delegate` to carve off tasks."
+
+Stop.
+
+If `$ARGUMENTS` is empty, ask: **"What task should the prompt describe?"** and wait for a response.
+
+---
+
+## Step 1 — Gather branch and diff context
+
+```bash
+git branch --show-current
+```
+
+```bash
+git diff --name-only dev...HEAD 2>/dev/null || git diff --name-only main...HEAD
+```
+
+---
+
+## Step 2 — Build the prompt
+
+Compose the following as a fenced markdown block (` ```markdown `) so the operator can copy it.
+
+Use the issue title, body, and agent implementation notes from the current `/start` session — do not re-fetch them.
+
+```markdown
+## Your task
+
+<$ARGUMENTS — the operator's description of the delegated work>
+
+## Branch
+
+You are on branch `<branch name>`. Stay on this branch.
+
+## Context
+
+**Issue #<number>: <title>**
+
+<issue body — include the full body as-is>
+
+<if there are agent implementation notes from the issue comments, include them under a "### Agent notes" subheading>
+
+## What's already been done on this branch
+
+<list of changed files from git diff, or "No changes yet — clean branch." if empty>
+
+## Rules
+
+- **Do not commit.** Leave all changes unstaged. The lead developer will handle commits.
+- **Be surgical.** Only modify what is necessary for your task. Do not refactor adjacent code, reorganize imports, or "improve" files outside the scope of your task.
+- **Do not start until the branch exists on the remote.** The lead developer will create and push the branch. Wait until `git checkout <branch name> && git pull origin <branch name>` succeeds before beginning work.
+```
+
+---
+
+## Step 3 — Present to operator and update lead scope
+
+Print the generated prompt preceded by:
+
+> Here's a delegation prompt for: **$ARGUMENTS**
+>
+> Review and edit as needed, then paste into your agent of choice after the lead agent has created and pushed the branch.
+
+Then print the fenced prompt block.
+
+After presenting, record internally that `$ARGUMENTS` has been delegated. When the operator says `go` and the lead agent proceeds to write code, it must skip the delegated work. If multiple `/delegate` invocations occur before `go`, accumulate all of them.
+
+After presenting, say:
+
+> Noted — the lead agent will skip this part when you say `go`. Run `/delegate <another task>` to delegate more, or type `go` to proceed.
+
+---
+
+## Hard rules
+
+- Never commit, push, or modify any files.
+- Never post to GitHub (no comments, labels, or issue updates).
+- Output only — the skill produces text for the operator to copy.
+- Do not suggest or name a specific agent to paste into — that is the operator's choice.
+<!-- generated by CodeCannon/sync.py | skill: delegate | adapter: codex | hash: 09337683 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.agents/skills/deploy/SKILL.md

@@ -117,7 +117,19 @@ If the user chose a bump level, map their response to a command:
 | "major" | `make bump-major` |
 | A specific version e.g. "2.4.5" | `make set-version V= 2.4.5` |
 
-These commands update the version manifest, create a git commit, and create a git tag. Do not create commits or tags manually.
+These commands update the version manifest, create a git commit, and create a git tag.
+
+After the bump command runs, verify the tag was actually created:
+
+```bash
+git tag -l "v<new-version>"
+```
+
+If the tag is missing (some git configs like `tag.forceSignAnnotated = true` reject lightweight tags silently), create an annotated tag as a fallback:
+
+```bash
+git tag -a "v<new-version>" -m "v<new-version>"
+```
 
 Push the version bump:
 ```bash
@@ -253,4 +265,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 CodeCannon/sync.py | skill: deploy | adapter: codex | hash: 1a6fd564 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: codex | hash: 330712b1 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.agents/skills/setup/SKILL.md

@@ -258,7 +258,104 @@ A value counts as "set" if it is present, uncommented, and non-empty in `.codeca
 
 ---
 
-### Phase 2 — Label population
+### Phase 2 — Permission audit
+
+Check whether the agent's permission configuration covers the shell commands Code Cannon skills use. Read `CodeCannon/permissions.yaml` to get the list of required command prefixes.
+
+**Claude Code:** Read `.claude/settings.local.json` (if it exists) and `.claude/settings.json` (if it exists). Collect all `Bash(...)` entries from the `permissions.allow` arrays in both files. For each command prefix in `permissions.yaml`, check whether an allow rule covers it (e.g. `Bash(git:*)` or `Bash(git *)` covers the `git` prefix).
+
+If all prefixes are covered, display `Agent permissions: all skill commands pre-approved` and continue to Phase 3.
+
+If any prefixes are missing, show:
+
+```
+Agent permissions: some skill commands may prompt for approval.
+
+  Missing allow rules:
+    - Bash(cd:*)
+    - Bash(make:*)
+    ...
+
+  To pre-approve these, add them to .claude/settings.local.json (git-ignored)
+  or .claude/settings.json (shared with team). See docs/index.md for a full example.
+
+  This is optional — you can approve commands individually when prompted instead.
+```
+
+Do not modify any settings file. This is advisory only.
+
+**Other agents (Cursor, Codex, Gemini):** Skip this phase silently — Cursor doesn't prompt, and Codex/Gemini permission systems vary. The docs cover these agents separately.
+
+---
+
+### Phase 3 — Commit signing
+
+Check whether commit signing is already configured at any level (local or global):
+
+```bash
+git config --get commit.gpgsign
+```
+
+If the output is `true`, display `Commit signing: enabled` in the health summary area and skip to Phase 4.
+
+If not `true`, ask: **"Does this project require signed commits? (yes/no)"**
+
+Wait for response.
+
+- **no / skip** → continue to Phase 4.
+- **yes** → proceed with signing setup.
+
+**Verify a signing key exists:**
+
+```bash
+git config --get user.signingkey
+```
+
+**If a signing key is found**, show the proposed change and confirm:
+
+```
+I'll enable commit and tag signing for this repo:
+
+  git config commit.gpgsign true
+  git config tag.gpgsign true
+
+  Signing key: <truncated-key>
+
+Proceed? (yes/no)
+```
+
+Wait for confirmation. Write only on yes. If no, skip to Phase 4.
+
+Continue to Phase 4.
+
+**If no signing key is found**, detect the signing format:
+
+```bash
+git config --get gpg.format
+```
+
+- If `ssh` → suggest: `git config user.signingkey ~/.ssh/id_ed25519.pub` (adjust path to the user's key). Ask the user for their SSH public key path.
+- If `gpg` or unset → suggest: run `gpg --list-secret-keys --keyid-format=long` to find a key ID. Ask the user for their GPG key ID.
+
+Once the user provides a key value, show the proposed changes and confirm:
+
+```
+I'll configure signing for this repo:
+
+  git config user.signingkey <provided-key>
+  git config commit.gpgsign true
+  git config tag.gpgsign true
+
+Proceed? (yes/no)
+```
+
+Wait for confirmation. Write only on yes. If no, skip to Phase 4.
+
+If the user has no signing key and doesn't know how to create one, point them to GitHub's signing key documentation and stop: "Set up a signing key first, then run `/setup` again to enable commit signing."
+
+---
+
+### Phase 4 — Label population
 
 Run:
 
@@ -290,7 +387,7 @@ Wait for response.
 
 After this step (or if labels were non-zero initially), run `gh label list --limit 100 --json name,color,description` again.
 
-If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 3; otherwise leave it unset so `/start` auto-detects."
+If `TICKET_LABELS` is unset or fewer than 5 labels exist, add a note: "`/start` works best with a clear issue-label pool (`TICKET_LABELS`), and `/qa` needs explicit QA lifecycle labels (`ready-for-qa`, `qa-passed`, `qa-failed`). Consider a lightweight priority scheme (e.g. `priority:high`, `priority:medium`, `priority:low`) if the team needs triage support. If the team runs planned iterations, set `DEFAULT_MILESTONE` in Phase 5; otherwise leave it unset so `/start` auto-detects."
 
 Display the results as a numbered list:
 
@@ -308,7 +405,7 @@ Wait for the user's response.
 
 - **yes** → use all labels
 - **numbers** (e.g. `1,3,5`) → use only those labels
-- **no / skip / anything else** → skip this phase, continue to Phase 3
+- **no / skip / anything else** → skip this phase, continue to Phase 5
 
 Show the exact change before writing:
 
@@ -324,7 +421,7 @@ Wait for confirmation. Write only on yes.
 
 ---
 
-### Phase 3 — Optional config walkthrough (profile-aware)
+### Phase 5 — Optional config walkthrough (profile-aware)
 
 First, infer the current profile using the same rules as Phase 1.
 
@@ -346,7 +443,7 @@ The walkthrough adapts based on profile. Walk through each applicable unset valu
 
 ---
 
-### Phase 4 — Team sharing
+### Phase 6 — Team sharing
 
 After completing or skipping the config walkthrough, say:
 
@@ -364,11 +461,11 @@ Add a note: `/start` can be used to create well-formed GitHub issues without wri
 
 ## Hard rules
 
-- Only modify `.codecannon.yaml`. Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval).
+- Only modify `.codecannon.yaml` and local git config (Phase 3 signing setup). Do not touch any other file (except running `CodeCannon/sync.py`, which modifies `.claude/commands/` — permitted only with explicit user approval).
 - Do not run `sync.py` without explicit user permission.
 - Do not create `.codecannon.yaml` without explicit user permission.
 - Do not report a configuration problem unless confident the condition is genuinely broken. Prefer false negatives over false positives on all diagnostic checks.
 - 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.
+- Do not skip any human gate in Phase 3, Phase 4, or Phase 5 — each write requires confirmation.
 - If the user skips a config value, do not ask again. Move on.
-<!-- generated by CodeCannon/sync.py | skill: setup | adapter: codex | hash: 641d16b6 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: setup | adapter: codex | hash: d5d997f8 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->