Release v0.5.1

.agents/skills/start/SKILL.md

@@ -213,7 +213,7 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-descriptive-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from.
@@ -278,7 +278,7 @@ git checkout dev && git pull origin dev
 Find and check out the existing branch, or create a new one linked to the issue:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state.
@@ -309,8 +309,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 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.
+- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or 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.py | skill: start | adapter: codex | hash: a1701c1d | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: codex | hash: 7aa119f7 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.agents/skills/submit-for-review/SKILL.md

@@ -32,7 +32,31 @@ If the current branch matches any of the above, **abort immediately** and say:
 
 ## Step 2 — Type-check gate
 
-Run:
+First, move to the repository root so the command resolves against the correct Makefile / project config:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above:
+
+```
+cd <repo-root>
+```
+
+Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
+
+```
+make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command. Do not proceed.
+
+If the target exists, run:
 ```
 make check
 ```
@@ -47,12 +71,11 @@ Do not proceed until `make check` passes cleanly.
 
 ## Step 3 — Identify linked issue
 
-Check for a linked issue by inspecting the branch name (should follow `feature/<name>` linked via `gh issue develop`) or by running:
-```
-gh pr view --json number,body 2>/dev/null
-```
+Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/<number>-<description>` (e.g. `feature/42-fix-login`).
 
-If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user.
+Parse the number from the branch name returned in Step 1. If the branch name matches `feature/<digits>-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user:
+
+> "Could not extract an issue number from branch name `<branch>`. The PR will not include an issue reference. Was this branch created outside of `/start`?"
 
 ---
 
@@ -171,6 +194,24 @@ Wait for the review to complete and report its verdict.
 
 ## Step 8 — Act on verdict
 
+Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above and check the target:
+
+```
+cd <repo-root> && make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed.
+
 Merge command (used by all paths below): `make merge`
 
 ---
@@ -325,4 +366,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.py | skill: submit-for-review | adapter: codex | hash: 7da4e9fb | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: codex | hash: 9a2a2201 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.claude/commands/start.md

@@ -208,7 +208,7 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-descriptive-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from.
@@ -273,7 +273,7 @@ git checkout dev && git pull origin dev
 Find and check out the existing branch, or create a new one linked to the issue:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state.
@@ -304,8 +304,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 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.
+- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or 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.py | skill: start | adapter: claude | hash: 3761be9e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: claude | hash: 1ef4856c | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.claude/commands/submit-for-review.md

@@ -27,7 +27,31 @@ If the current branch matches any of the above, **abort immediately** and say:
 
 ## Step 2 — Type-check gate
 
-Run:
+First, move to the repository root so the command resolves against the correct Makefile / project config:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above:
+
+```
+cd <repo-root>
+```
+
+Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
+
+```
+make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command. Do not proceed.
+
+If the target exists, run:
 ```
 make check
 ```
@@ -42,12 +66,11 @@ Do not proceed until `make check` passes cleanly.
 
 ## Step 3 — Identify linked issue
 
-Check for a linked issue by inspecting the branch name (should follow `feature/<name>` linked via `gh issue develop`) or by running:
-```
-gh pr view --json number,body 2>/dev/null
-```
+Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/<number>-<description>` (e.g. `feature/42-fix-login`).
 
-If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user.
+Parse the number from the branch name returned in Step 1. If the branch name matches `feature/<digits>-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user:
+
+> "Could not extract an issue number from branch name `<branch>`. The PR will not include an issue reference. Was this branch created outside of `/start`?"
 
 ---
 
@@ -166,6 +189,24 @@ Wait for the review to complete and report its verdict.
 
 ## Step 8 — Act on verdict
 
+Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above and check the target:
+
+```
+cd <repo-root> && make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed.
+
 Merge command (used by all paths below): `make merge`
 
 ---
@@ -320,4 +361,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.py | skill: submit-for-review | adapter: claude | hash: f9e7a62e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: claude | hash: 0696458e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.cursor/rules/start.mdc

@@ -214,7 +214,7 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-descriptive-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout dev` on its own does not influence which branch the new feature branch is cut from.
@@ -279,7 +279,7 @@ git checkout dev && git pull origin dev
 Find and check out the existing branch, or create a new one linked to the issue:
 
 ```bash
-gh issue develop <number> --base dev --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<number>-<short-name> --checkout
 ```
 
 > `--base` is required: `gh issue develop` reads the default base from the GitHub API, not from local working state.
@@ -310,8 +310,8 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 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.
+- `gh issue create` must use `--title` and `--body-file` flags. Never pass body content inline or 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.py | skill: start | adapter: cursor | hash: 1c0ca80d | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: start | adapter: cursor | hash: 9614896e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

.cursor/rules/submit-for-review.mdc

@@ -33,7 +33,31 @@ If the current branch matches any of the above, **abort immediately** and say:
 
 ## Step 2 — Type-check gate
 
-Run:
+First, move to the repository root so the command resolves against the correct Makefile / project config:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above:
+
+```
+cd <repo-root>
+```
+
+Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
+
+```
+make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make check` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command. Do not proceed.
+
+If the target exists, run:
 ```
 make check
 ```
@@ -48,12 +72,11 @@ Do not proceed until `make check` passes cleanly.
 
 ## Step 3 — Identify linked issue
 
-Check for a linked issue by inspecting the branch name (should follow `feature/<name>` linked via `gh issue develop`) or by running:
-```
-gh pr view --json number,body 2>/dev/null
-```
+Extract the issue number from the branch name. Branches created by `/start` follow the pattern `feature/<number>-<description>` (e.g. `feature/42-fix-login`).
 
-If a linked issue number is identifiable, note it for the PR body. If not identifiable, proceed without it but mention this to the user.
+Parse the number from the branch name returned in Step 1. If the branch name matches `feature/<digits>-...`, use the extracted number as the linked issue. If the branch name does not contain a leading number after `feature/`, proceed without an issue reference but warn the user:
+
+> "Could not extract an issue number from branch name `<branch>`. The PR will not include an issue reference. Was this branch created outside of `/start`?"
 
 ---
 
@@ -172,6 +195,24 @@ Wait for the review to complete and report its verdict.
 
 ## Step 8 — Act on verdict
 
+Before merging, verify the merge target exists. Move to the repo root, extract the target name from `make merge` (e.g. `make merge` → `merge`), and run:
+
+```
+git rev-parse --show-toplevel
+```
+
+Then `cd` into the path returned above and check the target:
+
+```
+cd <repo-root> && make -n <target> 2>/dev/null
+```
+
+If `make -n` exits non-zero, **stop** and say:
+
+> "`make merge` failed — the make target does not exist in the root Makefile. Add it and retry, or run `/setup` to reconfigure."
+
+Do not improvise a replacement command (e.g. do not fall back to `gh pr merge`). Do not proceed.
+
 Merge command (used by all paths below): `make merge`
 
 ---
@@ -326,4 +367,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.py | skill: submit-for-review | adapter: cursor | hash: f7cf15c3 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: cursor | hash: 807ac0ec | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->