Fix start skill re-prompting after approval and deploy skill lightweight tag failure

[sebastientaggart]

Problem to Fix

Two skill reliability issues affect agents running Code Cannon workflows on consumer projects:

1. Start skill re-prompts after approval — When an agent finishes discussing an implementation approach and the user approves, the agent sometimes re-runs repository detection and milestone lookups, then asks the user to pick a milestone again. This breaks the flow and confuses users who already gave the green light.

2. Deploy skill fails to create version tags — When a user's git config enforces annotated tags (e.g. tag.forceSignAnnotated = true), the version bump command's lightweight tag creation silently fails. The agent must then manually recover, adding friction to every deploy.

Why it Matters

Both issues cause unnecessary back-and-forth during critical workflow moments — right when the user expects the agent to just execute. The start skill issue forces users to answer the same milestone question twice, and the deploy tag issue can block releases until the agent figures out the workaround.

General Approach

1. Add an explicit execution-order directive to the start skill's argument-parsing section so agents resolve labels and milestones before the investigation step — not during issue creation after the human gate.
2. Add a tag verification step to the deploy skill after version bump commands, with an annotated-tag fallback when the expected tag is missing.

Complexity

Verification / QA effort: moderate
Both fixes are documentation/instruction changes to skill files — verification involves running /start and /deploy on a test project to confirm agents no longer re-prompt or fail on tags.

Acceptance Criteria

• After a user approves the approach in /start, the agent proceeds directly to issue creation without re-running milestone detection or re-prompting
• The deploy skill verifies the version tag exists after a bump command and creates an annotated tag as fallback if missing
• All four adapter outputs (claude, cursor, codex, gemini) are regenerated via sync

[sebastientaggart]

Agent Implementation Notes

Files changed

1. skills/start.md (canonical source)

   • Added execution-order blockquote in the "Parsing $ARGUMENTS" section (after the "Skip this entirely" note, before the flag-parsing list) directing agents to resolve labels and milestones immediately — before Case A Step 1.
   • Updated Step 3's label/milestone instructions from "Resolve labels and milestone using the resolution steps in the Parsing section above" to "Use the labels and milestone you already resolved in the Parsing section" with an explicit "do not re-run" directive.

2. skills/deploy.md (canonical source)

   • Added a tag verification block in Step 3, between the bump command table and the git push commands. After the bump runs, git tag -l "v<new-version>" checks if the tag exists. If missing, git tag -a "v<new-version>" -m "v<new-version>" creates an annotated tag as fallback.
   • Removed the sentence "Do not create commits or tags manually" since the fallback now intentionally creates a tag when the bump command fails to.

3. Adapter outputs (auto-generated by sync.py --force)

   • .claude/commands/start.md, .claude/commands/deploy.md
   • .cursor/rules/start.mdc, .cursor/rules/deploy.mdc
   • .agents/skills/start/SKILL.md, .agents/skills/deploy/SKILL.md
   • .gemini/skills/start/SKILL.md, .gemini/skills/deploy/SKILL.md

Key decisions

• The start fix is purely an ordering/instruction clarification — no structural changes to the skill flow.
• The deploy fix uses git tag -a -m (annotated) rather than trying to detect the specific git config, since annotated tags work universally regardless of config.

[sebastientaggart]

Resolution

The start skill now resolves milestones and labels upfront during argument parsing, so agents no longer re-prompt for milestones after the user has already approved the approach. The deploy skill now verifies the version tag was actually created after a bump command and falls back to creating an annotated tag if the lightweight tag was rejected by git config — eliminating the silent failure and manual recovery step.

See #146 for full technical details.

[sebastientaggart]

Resolution

Three fixes shipped across PRs #146 and #147:

1. The start skill now resolves milestones and labels upfront so agents no longer re-prompt after the user has already approved the approach.
2. The deploy skill now verifies version tags were created and falls back to annotated tags when git config rejects lightweight ones.
3. Shell command workarounds in the submit-for-review skill were reverted in favor of documenting how to configure each agent's permission system — a new "Agent tips and tweaks" section in the docs covers Claude Code, Cursor, Codex, and Gemini.

See #146 and #147 for full technical details.

[sebastientaggart]

Note: the sync.py validation only checks first-token commands in bash code blocks, so it won't catch piped/chained commands like grep or inline prose suggestions like gpg. That's an acceptable limitation — the manifest is hand-maintained, and the validation is a safety net for the common case, not exhaustive.

[sebastientaggart]

Resolution

Skill commands no longer use shell command substitutions ($(...)) that triggered repeated permission prompts in Claude Code. The /setup skill now includes a permission audit phase that checks whether the agent's configuration covers the commands Code Cannon uses and suggests any missing allow rules — this is advisory only, so developers who prefer case-by-case approval are unaffected. A validation step in sync also catches drift between skills and the permissions manifest.

See #150 for full technical details.