Add checkpoint skill, fix temp file collisions, and support starting on existing branches

[sebastientaggart]

Problem to Fix

When two agents or terminal sessions run CodeCannon skills at the same time, they write to the same temporary files and can corrupt each other's work. There is also no way to save progress without triggering the full pull request and review ceremony, and no way to start coding on a branch that was created outside the normal workflow.

Why it Matters

These gaps block developers from using save points during long coding sessions and prevent future multi-agent workflows from functioning correctly. The temp file collision is a latent bug that can produce incorrect GitHub issues or PRs if two sessions overlap.

General Approach

Three independent improvements:

1. Temp file isolation — Move all temporary files from a shared global directory to a project-local .cc_tmp/ directory, so each working copy has its own temp space.
2. Checkpoint skill — Add a new /checkpoint command that commits and pushes work-in-progress without creating a PR, running reviews, or merging. Uses a WIP: commit prefix.
3. Start on existing branch — Modify /start to detect when the user is already on a feature branch and offer to create a linked GitHub issue and begin coding, instead of warning and stopping.

Complexity

Verification / QA effort: moderate
Each change is small but touches multiple skill files and must be validated across all four agent adapters after sync.

Acceptance Criteria

• All temp file references in skills use .cc_tmp/ instead of /tmp/cc_*
• Running make sync produces adapter output with the updated paths
• A new /checkpoint skill exists and generates correctly for all adapters
• /checkpoint commits with WIP: prefix, pushes, and does not create a PR or trigger review
• /start gracefully handles being invoked on an existing feature/* branch
• make check passes with no unresolved placeholders

[sebastientaggart]

Agent Implementation Notes

Phase 0: Temp file isolation

Replace all /tmp/cc_*.md references with .cc_tmp/*.md (project-relative) in:

• skills/start.md — /tmp/cc_issue_body.md → .cc_tmp/issue_body.md, /tmp/cc_issue_comment.md → .cc_tmp/issue_comment.md
• skills/submit-for-review.md — /tmp/cc_pr_body.md → .cc_tmp/pr_body.md, /tmp/cc_resolution_comment.md → .cc_tmp/resolution_comment.md, /tmp/cc_followup_body.md → .cc_tmp/followup_body.md
• skills/deploy.md — /tmp/cc_release_notes.md → .cc_tmp/release_notes.md, /tmp/cc_release_pr_body.md → .cc_tmp/release_pr_body.md

Each skill needs a mkdir -p .cc_tmp step before writing temp files. Add .cc_tmp/ to .gitignore guidance.

Phase 1: /checkpoint skill

Create skills/checkpoint.md. Steps: verify on feature/* branch, check for changes, git add -A, commit with WIP: prefix, push. Never create PR, trigger review, or merge.

Phase 2: /start existing branch detection

When already on a feature/* branch: prompt user to create a linked issue and start coding (skip branch creation), or abort. The gh issue develop call should link the issue to the existing branch.

Post-implementation

Run ./CodeCannon/sync.sh to regenerate all adapters. Create a follow-up issue for Phases 3-5 (worktree launcher, conflict detection, status swarm awareness).

[sebastientaggart]

Resolution

Added a new /checkpoint command that lets developers save work-in-progress without going through the full review and merge process. Also fixed an issue where running multiple skills in the same session could cause temp file conflicts, and updated /start to gracefully handle being run when already on a feature branch instead of erroring out.

See #113 for full technical details.

[sebastientaggart]

Resolution

Temp files used by skills during issue creation, PR creation, and deployment now go into unique directories under /tmp/CodeCannon/ instead of sharing fixed filenames, preventing corruption when multiple agents or sessions run simultaneously. A new /checkpoint command lets developers save work-in-progress without triggering the full review and merge ceremony. The /start command now handles being invoked on an existing feature branch gracefully instead of just warning.

See #125 for full technical details.