Add commit signing detection and configuration to the setup skill

[sebastientaggart]

Problem to Fix

When a project enforces signed commits (via branch protection rules or team policy), AI agents creating commits during the workflow may fail on push because the local git configuration doesn't have commit signing enabled. The agent recovers, but the retry wastes time and tokens.

Why it Matters

Every failed-then-retried commit costs tokens and slows down the workflow. Projects that require signed commits hit this on every feature branch, making it a recurring tax rather than a one-time hiccup.

General Approach

Add a step to the setup skill that detects whether commit signing is already configured, asks the user if their project requires it, and configures the local git settings accordingly. This fixes the problem at the git layer so all existing and future skills benefit automatically without any template changes.

Complexity

Verification / QA effort: moderate
Setup is interactive and has a few branches to verify: already configured, not configured but wanted, not configured and not wanted, missing signing key.

Acceptance Criteria

• The setup skill detects existing commit/tag signing configuration and skips if already enabled
• If signing is not configured, the user is asked whether their project requires it
• If yes, the setup skill verifies a signing key exists and enables commit.gpgsign and tag.gpgsign at the repo level
• If no signing key is found, the user is guided to configure one before proceeding
• No changes to skill templates or config placeholders are required

[sebastientaggart]

Agent Implementation Notes

File to change: skills/setup.md

Approach:

Add a new section to the setup flow (after repo detection, before workflow configuration) that handles commit signing:

1. Detection — Check git config --get commit.gpgsign (local then global). If already true, report it and skip.

2. Prompt — If not configured, ask: "Does this project require signed commits? (yes/no)"

   • If no → skip, move on.
   • If yes → proceed to key verification.

3. Key verification — Check git config --get user.signingkey. If empty, check gpg.format to determine signing method (SSH vs GPG):

   • If SSH format: suggest git config user.signingkey ~/.ssh/id_ed25519.pub (or similar)
   • If GPG format: suggest gpg --list-secret-keys to find the key
   • If no format set: ask which method they use
   • Do not proceed until a signing key is confirmed.

4. Configuration — Run:

   • git config commit.gpgsign true
   • git config tag.gpgsign true
   • Report what was set.

Key decisions:

• Set at repo level (not global) so it doesn't affect other projects
• Check both local and global config — if global already enables signing, no repo-level override needed
• Tag signing is included since the Makefile and deploy skill create tags
• No changes to .codecannon.yaml, config.schema.yaml, or any skill templates — this is purely a git config setup step

Edge cases:

• User has global signing enabled but no local config → detection should find it via git config --get (which checks both levels)
• User has signing key but not commit.gpgsign → just needs the boolean enabled
• User has no signing key at all → must configure one first; don't blindly enable signing or commits will fail

[sebastientaggart]

Resolution

The setup skill now detects whether commit signing is configured and offers to enable it during onboarding. Projects that require signed commits will have this configured upfront, preventing agents from creating unsigned commits that fail on push and waste tokens recovering.

See #144 for full technical details.