Fix start skill re-prompting and deploy lightweight tag failure

.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/start/SKILL.md

@@ -25,6 +25,8 @@ Otherwise → go to **Case A: New work**.
 
 > Skip this entirely if `$ARGUMENTS` triggered Case B.
 
+> **Execution order:** Resolve labels and milestones **now**, before entering Case A Step 1. If milestone auto-detection requires a user prompt (2+ open milestones), that prompt happens here — not later during issue creation. By the time you reach Step 2's human gate, all metadata must already be resolved so that Step 3 can proceed without re-prompting.
+
 The argument string may contain optional inline flags after the description. Parse as follows:
 
 1. **Identify flags** — scan for the first token that starts with `--label`, `-l`, `--milestone`, or `-m`. Everything before it is the **description**. Everything from the first flag onward is **flags**.
@@ -147,9 +149,9 @@ gh issue create \
 
 > **IMPORTANT — never pass body content inline in the `gh` command.** Do not use `--body`, `--body-file -`, heredocs (`<<EOF` or `<<'EOF'`), or `$(cat ...)`. All of these embed markdown in a Bash command, which triggers permission prompts that cannot be permanently allowed (the shell parser flags `#` headings, quoted delimiters, and substitutions). The two-step pattern above — file-writing tool then `--body-file <path>` — is the only approach that works without prompts across Claude Code, Gemini CLI, Cursor, and Codex.
 
-Resolve labels and milestone using the resolution steps in the Parsing section above:
-- **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
-- **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
+Use the labels and milestone you already resolved in the Parsing section (before Step 1). Do **not** re-run label or milestone resolution here — the values are final:
+- **Labels**: if non-empty, add `--label "<value>"` to the command. If empty, omit `--label` entirely.
+- **Milestone**: if non-empty, add `--milestone "<value>"` to the command. If empty, omit `--milestone` entirely.
 
 **Body structure (required sections, in this order):**
 
@@ -313,4 +315,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.py | skill: start | adapter: codex | hash: 7aa119f7 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: codex | hash: 1748fe41 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.claude/commands/deploy.md

@@ -112,7 +112,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
@@ -248,4 +260,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: claude | hash: 1fa58dba | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: claude | hash: 5bb8e194 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.claude/commands/start.md

@@ -20,6 +20,8 @@ Otherwise → go to **Case A: New work**.
 
 > Skip this entirely if `$ARGUMENTS` triggered Case B.
 
+> **Execution order:** Resolve labels and milestones **now**, before entering Case A Step 1. If milestone auto-detection requires a user prompt (2+ open milestones), that prompt happens here — not later during issue creation. By the time you reach Step 2's human gate, all metadata must already be resolved so that Step 3 can proceed without re-prompting.
+
 The argument string may contain optional inline flags after the description. Parse as follows:
 
 1. **Identify flags** — scan for the first token that starts with `--label`, `-l`, `--milestone`, or `-m`. Everything before it is the **description**. Everything from the first flag onward is **flags**.
@@ -142,9 +144,9 @@ gh issue create \
 
 > **IMPORTANT — never pass body content inline in the `gh` command.** Do not use `--body`, `--body-file -`, heredocs (`<<EOF` or `<<'EOF'`), or `$(cat ...)`. All of these embed markdown in a Bash command, which triggers permission prompts that cannot be permanently allowed (the shell parser flags `#` headings, quoted delimiters, and substitutions). The two-step pattern above — file-writing tool then `--body-file <path>` — is the only approach that works without prompts across Claude Code, Gemini CLI, Cursor, and Codex.
 
-Resolve labels and milestone using the resolution steps in the Parsing section above:
-- **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
-- **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
+Use the labels and milestone you already resolved in the Parsing section (before Step 1). Do **not** re-run label or milestone resolution here — the values are final:
+- **Labels**: if non-empty, add `--label "<value>"` to the command. If empty, omit `--label` entirely.
+- **Milestone**: if non-empty, add `--milestone "<value>"` to the command. If empty, omit `--milestone` entirely.
 
 **Body structure (required sections, in this order):**
 
@@ -308,4 +310,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.py | skill: start | adapter: claude | hash: 1ef4856c | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: claude | hash: d7882b03 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.cursor/rules/deploy.mdc

@@ -118,7 +118,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
@@ -254,4 +266,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: cursor | hash: 31e92299 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: cursor | hash: bcbec2e6 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.cursor/rules/start.mdc

@@ -26,6 +26,8 @@ Otherwise → go to **Case A: New work**.
 
 > Skip this entirely if `$ARGUMENTS` triggered Case B.
 
+> **Execution order:** Resolve labels and milestones **now**, before entering Case A Step 1. If milestone auto-detection requires a user prompt (2+ open milestones), that prompt happens here — not later during issue creation. By the time you reach Step 2's human gate, all metadata must already be resolved so that Step 3 can proceed without re-prompting.
+
 The argument string may contain optional inline flags after the description. Parse as follows:
 
 1. **Identify flags** — scan for the first token that starts with `--label`, `-l`, `--milestone`, or `-m`. Everything before it is the **description**. Everything from the first flag onward is **flags**.
@@ -148,9 +150,9 @@ gh issue create \
 
 > **IMPORTANT — never pass body content inline in the `gh` command.** Do not use `--body`, `--body-file -`, heredocs (`<<EOF` or `<<'EOF'`), or `$(cat ...)`. All of these embed markdown in a Bash command, which triggers permission prompts that cannot be permanently allowed (the shell parser flags `#` headings, quoted delimiters, and substitutions). The two-step pattern above — file-writing tool then `--body-file <path>` — is the only approach that works without prompts across Claude Code, Gemini CLI, Cursor, and Codex.
 
-Resolve labels and milestone using the resolution steps in the Parsing section above:
-- **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
-- **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
+Use the labels and milestone you already resolved in the Parsing section (before Step 1). Do **not** re-run label or milestone resolution here — the values are final:
+- **Labels**: if non-empty, add `--label "<value>"` to the command. If empty, omit `--label` entirely.
+- **Milestone**: if non-empty, add `--milestone "<value>"` to the command. If empty, omit `--milestone` entirely.
 
 **Body structure (required sections, in this order):**
 
@@ -314,4 +316,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.py | skill: start | adapter: cursor | hash: 9614896e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: cursor | hash: b5b55da5 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.gemini/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: gemini | hash: 7e8845cd | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: deploy | adapter: gemini | hash: 7014d32b | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.gemini/skills/start/SKILL.md

@@ -25,6 +25,8 @@ Otherwise → go to **Case A: New work**.
 
 > Skip this entirely if `$ARGUMENTS` triggered Case B.
 
+> **Execution order:** Resolve labels and milestones **now**, before entering Case A Step 1. If milestone auto-detection requires a user prompt (2+ open milestones), that prompt happens here — not later during issue creation. By the time you reach Step 2's human gate, all metadata must already be resolved so that Step 3 can proceed without re-prompting.
+
 The argument string may contain optional inline flags after the description. Parse as follows:
 
 1. **Identify flags** — scan for the first token that starts with `--label`, `-l`, `--milestone`, or `-m`. Everything before it is the **description**. Everything from the first flag onward is **flags**.
@@ -147,9 +149,9 @@ gh issue create \
 
 > **IMPORTANT — never pass body content inline in the `gh` command.** Do not use `--body`, `--body-file -`, heredocs (`<<EOF` or `<<'EOF'`), or `$(cat ...)`. All of these embed markdown in a Bash command, which triggers permission prompts that cannot be permanently allowed (the shell parser flags `#` headings, quoted delimiters, and substitutions). The two-step pattern above — file-writing tool then `--body-file <path>` — is the only approach that works without prompts across Claude Code, Gemini CLI, Cursor, and Codex.
 
-Resolve labels and milestone using the resolution steps in the Parsing section above:
-- **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
-- **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
+Use the labels and milestone you already resolved in the Parsing section (before Step 1). Do **not** re-run label or milestone resolution here — the values are final:
+- **Labels**: if non-empty, add `--label "<value>"` to the command. If empty, omit `--label` entirely.
+- **Milestone**: if non-empty, add `--milestone "<value>"` to the command. If empty, omit `--milestone` entirely.
 
 **Body structure (required sections, in this order):**
 
@@ -313,4 +315,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 `bug, documentation, enhancement, chore` → omit `--label` entirely. Never apply a label outside `bug, documentation, enhancement, chore`.
 - Milestone resolution order: per-invocation flag → auto-detected from GitHub open milestones. Never prompt for a milestone more than once per invocation.
-<!-- generated by CodeCannon/sync.py | skill: start | adapter: gemini | hash: 7d162d14 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: gemini | hash: 93092932 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

skills/deploy.md

@@ -148,7 +148,19 @@ If the user chose a bump level, map their response to a command:
 | "major" | `{{BUMP_MAJOR_CMD}}` |
 | A specific version e.g. "2.4.5" | `{{SET_VERSION_CMD}} 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