LightbridgeLab · sebastientaggart · Apr 11, 2026 · Apr 11, 2026
diff --git a/.agents/skills/checkpoint/SKILL.md b/.agents/skills/checkpoint/SKILL.md
@@ -0,0 +1,93 @@
+---
+name: checkpoint
+description: Code Cannon: Commit and push WIP without review or merge
+---
+
+> **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 `/checkpoint` does
+
+`/checkpoint` is a lightweight save point — commit and push work-in-progress to the remote without triggering type-checks, reviews, PR creation, or merge. Use it to persist progress during long coding sessions or before context-switching.
+
+---
+
+## Step 1 — Verify branch
+
+```bash
+git branch --show-current
+```
+
+Protected branches (not a feature branch):
+- `main`
+- `dev`
+
+If the current branch matches any of the above, **abort immediately** and say:
+
+> "You are on `<branch>`. `/checkpoint` must be run from a feature branch."
+
+---
+
+## Step 2 — Check for changes
+
+```bash
+git status --porcelain
+```
+
+If the output is empty (no staged, unstaged, or untracked changes), say:
+
+> "Nothing to checkpoint — working tree is clean."
+
+Stop. Do not create an empty commit.
+
+---
+
+## Step 3 — Stage and commit
+
+```bash
+git add -A
+git commit -m "WIP: <message>"
+```
+
+**Commit message rules:**
+- Always prefix with `WIP: ` so these commits are visually distinct in `git log`.
+- If `$ARGUMENTS` is provided, use it as `<message>` (e.g. `WIP: add auth middleware`).
+- If `$ARGUMENTS` is empty, auto-generate from the diff summary (e.g. `WIP: update auth.ts, add login tests`). Keep it under 72 characters.
+- Do not commit `.env` files, secrets, or build artifacts. If `git status` shows such files, add them to `.gitignore` or exclude them from staging before committing.
+
+---
+
+## Step 4 — Push
+
+```bash
+git push -u origin HEAD
+```
+
+If the push fails because the remote branch does not exist yet, the `-u` flag handles creation. If it fails for another reason, report the error and stop.
+
+---
+
+## Step 5 — Report
+
+Count the files in the commit:
+
+```bash
+git diff --stat HEAD~1
+```
+
+Say:
+
+> "Checkpoint saved. N file(s) committed and pushed to `<branch>`. Run `/submit-for-review` when ready to open a PR."
+
+---
+
+## Hard rules
+
+- Never create a PR.
+- Never trigger a review.
+- Never merge.
+- Never apply labels or modify issues.
+- Never run `make check` — checkpoints are not quality gates.
+- Do not prompt for confirmation — `/checkpoint` is a quick save, not a ceremony.
+<!-- generated by CodeCannon/sync.sh | skill: checkpoint | adapter: codex | hash: a5c7187c | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
diff --git a/.agents/skills/deploy/SKILL.md b/.agents/skills/deploy/SKILL.md
@@ -166,7 +166,15 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
 
 ## Step 6 — Create PR: `dev` → `main`
 
-Use your file-writing tool (not Bash) to create `/tmp/cc_release_pr_body.md`:
+First, create a temp directory for this invocation:
+
+```bash
+mkdir -p /tmp/CodeCannon && mktemp -d /tmp/CodeCannon/XXXXXX
+```
+
+Note the returned path (e.g. `/tmp/CodeCannon/a8f3b2`). Use this path for all temp files in this invocation.
+
+Then use your file-writing tool (not Bash) to create `<tmpdir>/release_pr_body.md`:
 
 ```markdown
 Release vX.Y.Z
@@ -184,7 +192,7 @@ Then create the PR (do NOT use `--body`, `--body-file -`, or heredocs):
 ```bash
 gh pr create --base main --head dev \
   --title "Release vX.Y.Z" \
-  --body-file /tmp/cc_release_pr_body.md
+  --body-file <tmpdir>/release_pr_body.md
 ```
 
 Note the PR number from the output.
@@ -215,7 +223,7 @@ git describe --abbrev=0 <version-tag>^ 2>/dev/null
 
 If no previous tag exists, omit the "Full changelog" line.
 
-Use your file-writing tool (not Bash) to create `/tmp/cc_release_notes.md`:
+Use your file-writing tool (not Bash) to create `<tmpdir>/release_notes.md` (same temp directory from Step 6):
 
 ```markdown
 ## Changes
@@ -231,7 +239,7 @@ Then create the release (do NOT use `--notes`, `--notes-file -`, or heredocs):
 ```bash
 gh release create <version-tag> \
   --title "<version-tag>" \
-  --notes-file /tmp/cc_release_notes.md
+  --notes-file <tmpdir>/release_notes.md
 ```
 
 Format each PR line as `- #<linked-issue> — <PR title> (PR #<N>)`. If a PR had no linked issue, omit the `#<issue>` prefix and use just the PR title.
@@ -245,4 +253,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.sh | skill: deploy | adapter: codex | hash: 6d8dd3bb | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: codex | hash: 1a6fd564 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
diff --git a/.agents/skills/start/SKILL.md b/.agents/skills/start/SKILL.md
@@ -68,6 +68,35 @@ After parsing flags, determine the active milestone in this order:
 
 ---
 
+## Pre-check: Existing feature branch
+
+Before entering Case A or Case B, check the current branch:
+
+```bash
+git branch --show-current
+```
+
+If already on a `feature/*` branch and `$ARGUMENTS` is **not** a number (i.e. this is new work, not a resume):
+
+Say:
+
+> **"You're already on `feature/<name>`. Would you like to create a GitHub issue linked to this branch and start coding? Or switch to the base branch first? (yes to continue here / no to abort)"**
+
+Stop. Wait for the user to respond.
+
+- **Yes** → proceed to **Case A**, but **skip Step 4** (branch creation) entirely. The current branch is used as-is. In Step 3, after creating the issue, link it to the existing branch by running:
+  ```bash
+  gh issue develop <number> --base <base-branch> --name <current-branch-name>
+  ```
+  This links the issue to the branch in GitHub without creating or checking out a new branch. If `gh issue develop` fails because the branch already exists on the remote, that is fine — the link may already be established. Continue to Step 5.
+- **No / abort** → stop. Tell the user to switch to the base branch and run `/start` again.
+
+If already on a `feature/*` branch and `$ARGUMENTS` **is** a number → proceed to **Case B** normally (it handles branch checkout itself).
+
+If on any other branch → proceed to Case A or Case B as determined by the `$ARGUMENTS` check above.
+
+---
+
 ## Case A: New work (text description)
 
 ### Step 1 — Investigate
@@ -95,7 +124,15 @@ The friendly text question is required regardless of harness mode. If your harne
 
 Create the issue in two steps — **this exact sequence is mandatory**:
 
-**Step 3a — Write the body to a temp file.** Use your file-writing tool (Write in Claude Code, equivalent in other agents) to create `/tmp/cc_issue_body.md` with the structured markdown body (see sections below). Do NOT use Bash/shell to write this file. Do NOT use heredocs, `cat`, or `echo`. The file-writing tool bypasses shell parsing entirely.
+**Step 3a — Create a temp directory and write the body file.** Run:
+
+```bash
+mkdir -p /tmp/CodeCannon && mktemp -d /tmp/CodeCannon/XXXXXX
+```
+
+Note the returned path (e.g. `/tmp/CodeCannon/a8f3b2`). Use this path for all temp files in this invocation.
+
+Then use your file-writing tool (Write in Claude Code, equivalent in other agents) to create `<tmpdir>/issue_body.md` with the structured markdown body (see sections below). Do NOT use Bash/shell to write this file. Do NOT use heredocs, `cat`, or `echo`. The file-writing tool bypasses shell parsing entirely.
 
 **Step 3b — Run `gh issue create`** with `--body-file` pointing to the temp file:
 
@@ -105,7 +142,7 @@ gh issue create \
   --assignee @me \
   [--label "<resolved labels>"] \
   [--milestone "<resolved milestone>"] \
-  --body-file /tmp/cc_issue_body.md
+  --body-file <tmpdir>/issue_body.md
 ```
 
 > **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.
@@ -153,7 +190,7 @@ Show the user: `Created issue #<number>: <title>`
 
 Then immediately post agent implementation notes as a comment.
 
-Use your file-writing tool (not Bash) to create `/tmp/cc_issue_comment.md`:
+Use your file-writing tool (not Bash) to create `<tmpdir>/issue_comment.md` (same temp directory from Step 3a):
 ```markdown
 ## Agent Implementation Notes
 
@@ -162,7 +199,7 @@ Use your file-writing tool (not Bash) to create `/tmp/cc_issue_comment.md`:
 
 Then post it (do NOT use `--body` or heredocs — same rule as Step 3):
 ```bash
-gh issue comment <number> --body-file /tmp/cc_issue_comment.md
+gh issue comment <number> --body-file <tmpdir>/issue_comment.md
 ```
 
 ### Step 4 — Create feature branch
@@ -271,9 +308,9 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - Do not write or edit any source file before `git branch --show-current` shows `feature/*`.
 - Do not use `make branch` — always use `gh issue develop` so the branch is linked to the issue in GitHub.
 - Do not commit during `/start` — commits happen in `/submit-for-review`.
-- If already on a feature branch when `/start` is invoked, warn the user before creating another branch.
+- If already on a feature branch when `/start` is invoked with new work (Case A), prompt the user to either continue on the current branch (skipping branch creation) or abort. See **Pre-check: Existing feature branch** above.
 - `gh issue create` must use `--title` and `--body` flags. Never open an interactive editor.
 - 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.sh | skill: start | adapter: codex | hash: 7ba07088 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: codex | hash: a1701c1d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md
@@ -111,7 +111,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de
 
 Then create the PR in two steps — **this exact sequence is mandatory**:
 
-First, use your file-writing tool (Write in Claude Code, equivalent in other agents) to create `/tmp/cc_pr_body.md`. Do NOT use Bash/shell to write this file.
+First, create a temp directory for this invocation:
+
+```bash
+mkdir -p /tmp/CodeCannon && mktemp -d /tmp/CodeCannon/XXXXXX
+```
+
+Note the returned path (e.g. `/tmp/CodeCannon/a8f3b2`). Use this path for all temp files in this invocation.
+
+Then use your file-writing tool (Write in Claude Code, equivalent in other agents) to create `<tmpdir>/pr_body.md`. Do NOT use Bash/shell to write this file.
 
 ```markdown
 <description of what changed and why>
@@ -122,7 +130,7 @@ First, use your file-writing tool (Write in Claude Code, equivalent in other age
 Then create the PR (do NOT use `--body`, `--body-file -`, heredocs, or `$(cat ...)`):
 
 ```
-gh pr create --base <target-branch> --title "<title>" --body-file /tmp/cc_pr_body.md
+gh pr create --base <target-branch> --title "<title>" --body-file <tmpdir>/pr_body.md
 ```
 
 > **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.
@@ -226,7 +234,7 @@ If no linked issue was found, skip silently.
 
 Read the issue body (from Step 3 or via `gh issue view <number>`) to recall the original problem description. Then post a comment summarizing what was done:
 
-Use your file-writing tool (not Bash) to create `/tmp/cc_resolution_comment.md`:
+Use your file-writing tool (not Bash) to create `<tmpdir>/resolution_comment.md` (same temp directory from Step 6):
 
 ```markdown
 ## Resolution
@@ -239,7 +247,7 @@ See #<PR-number> for full technical details.
 Then post it (do NOT use `--body` or heredocs):
 
 ```
-gh issue comment <number> --body-file /tmp/cc_resolution_comment.md
+gh issue comment <number> --body-file <tmpdir>/resolution_comment.md
 ```
 
 **Resolution writing rules:**
@@ -275,7 +283,7 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is
 
 **Create the selected issues.** For each selected finding, run `gh issue create` with explicit flags:
 
-Use your file-writing tool (not Bash) to create `/tmp/cc_followup_body.md` for each finding:
+Use your file-writing tool (not Bash) to create `<tmpdir>/followup_body.md` for each finding (same temp directory from Step 6):
 
 ```markdown
 Follow-up from PR #<merged-pr-number> — auto-proposed from the code review.
@@ -291,7 +299,7 @@ Then create the issue (do NOT use `--body` or heredocs):
 gh issue create \
   --title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \
   [--label "<pool-selected labels>"] \
-  --body-file /tmp/cc_followup_body.md
+  --body-file <tmpdir>/followup_body.md
 ```
 
 Label resolution for each follow-up issue: use the pool-based selection tier from `/start` — pick 1–3 labels from `bug, documentation, enhancement, chore` that genuinely fit the finding. If `bug, documentation, enhancement, chore` is empty or no pool label fits, omit `--label`. Do not attempt per-invocation flag resolution (there is no flag here) and never create new labels from follow-ups, even if label creation is enabled for the project.
@@ -317,4 +325,4 @@ If a single `gh issue create` call fails, report the failure for that finding an
 - `/submit-for-review` merges only to `dev` — never directly to `main`.
 - If `make merge` fails for any reason, report it and stop — do not attempt workarounds.
 - The follow-up issue offer in Step 9 runs only after a successful merge and only when the review produced non-blocking findings. Never prompt the user for follow-ups when the review blocked the merge — those findings should be fixed, not ticketed.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: d09ab40d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 7da4e9fb | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
diff --git a/.claude/commands/checkpoint.md b/.claude/commands/checkpoint.md
@@ -0,0 +1,88 @@
+Code Cannon: Commit and push WIP without review or merge
+
+---
+
+## What `/checkpoint` does
+
+`/checkpoint` is a lightweight save point — commit and push work-in-progress to the remote without triggering type-checks, reviews, PR creation, or merge. Use it to persist progress during long coding sessions or before context-switching.
+
+---
+
+## Step 1 — Verify branch
+
+```bash
+git branch --show-current
+```
+
+Protected branches (not a feature branch):
+- `main`
+- `dev`
+
+If the current branch matches any of the above, **abort immediately** and say:
+
+> "You are on `<branch>`. `/checkpoint` must be run from a feature branch."
+
+---
+
+## Step 2 — Check for changes
+
+```bash
+git status --porcelain
+```
+
+If the output is empty (no staged, unstaged, or untracked changes), say:
+
+> "Nothing to checkpoint — working tree is clean."
+
+Stop. Do not create an empty commit.
+
+---
+
+## Step 3 — Stage and commit
+
+```bash
+git add -A
+git commit -m "WIP: <message>"
+```
+
+**Commit message rules:**
+- Always prefix with `WIP: ` so these commits are visually distinct in `git log`.
+- If `$ARGUMENTS` is provided, use it as `<message>` (e.g. `WIP: add auth middleware`).
+- If `$ARGUMENTS` is empty, auto-generate from the diff summary (e.g. `WIP: update auth.ts, add login tests`). Keep it under 72 characters.
+- Do not commit `.env` files, secrets, or build artifacts. If `git status` shows such files, add them to `.gitignore` or exclude them from staging before committing.
+
+---
+
+## Step 4 — Push
+
+```bash
+git push -u origin HEAD
+```
+
+If the push fails because the remote branch does not exist yet, the `-u` flag handles creation. If it fails for another reason, report the error and stop.
+
+---
+
+## Step 5 — Report
+
+Count the files in the commit:
+
+```bash
+git diff --stat HEAD~1
+```
+
+Say:
+
+> "Checkpoint saved. N file(s) committed and pushed to `<branch>`. Run `/submit-for-review` when ready to open a PR."
+
+---
+
+## Hard rules
+
+- Never create a PR.
+- Never trigger a review.
+- Never merge.
+- Never apply labels or modify issues.
+- Never run `make check` — checkpoints are not quality gates.
+- Do not prompt for confirmation — `/checkpoint` is a quick save, not a ceremony.
+<!-- generated by CodeCannon/sync.sh | skill: checkpoint | adapter: claude | hash: cc7e9e00 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->