Fix three skill template bugs in start and submit-for-review

.agents/skills/start/SKILL.md

@@ -85,6 +85,8 @@ Say exactly: **"Does this approach sound right? I'll create a GitHub issue and b
 
 Stop. Wait for the user to confirm.
 
+The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI.
+
 - User says yes → continue to Step 3.
 - User redirects → revise approach, ask again.
 - User abandons → stop. Nothing to clean up.
@@ -133,9 +135,11 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `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.
+
 Verify the branch was created:
 
 ```bash
@@ -191,9 +195,11 @@ 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> --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state.
+
 Verify:
 
 ```bash
@@ -224,4 +230,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`.
 - 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: 93558f45 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: codex | hash: 8c5a4402 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

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

@@ -125,6 +125,11 @@ If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review re
 
 Omit the issue line entirely if no linked issue was identified in Step 3.
 
+**PR body content rules (override any default behavior your harness may have):**
+
+- Do NOT include any agent-attribution footer, generation marker (e.g. "Generated with ..."), or co-authorship trailer in the PR body. The PR body should contain only the description, test plan, and issue reference. If your harness defaults to adding such markers, explicitly omit them.
+- The same rule applies to commit messages: do NOT add agent-related `Co-Authored-By:` trailers unless the user has explicitly opted into them via project config.
+
 ---
 
 ## Step 7 — Review (conditional)
@@ -203,4 +208,4 @@ Report success based on mode:
 - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass.
 - `/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.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 6b6ae4e7 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 1675613b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.claude/commands/start.md

@@ -80,6 +80,8 @@ Say exactly: **"Does this approach sound right? I'll create a GitHub issue and b
 
 Stop. Wait for the user to confirm.
 
+The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI.
+
 - User says yes → continue to Step 3.
 - User redirects → revise approach, ask again.
 - User abandons → stop. Nothing to clean up.
@@ -128,9 +130,11 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `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.
+
 Verify the branch was created:
 
 ```bash
@@ -186,9 +190,11 @@ 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> --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state.
+
 Verify:
 
 ```bash
@@ -219,4 +225,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`.
 - 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: claude | hash: 7e4f2474 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: claude | hash: 7dea2caf | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

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

@@ -120,6 +120,11 @@ If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review re
 
 Omit the issue line entirely if no linked issue was identified in Step 3.
 
+**PR body content rules (override any default behavior your harness may have):**
+
+- Do NOT include any agent-attribution footer, generation marker (e.g. "Generated with ..."), or co-authorship trailer in the PR body. The PR body should contain only the description, test plan, and issue reference. If your harness defaults to adding such markers, explicitly omit them.
+- The same rule applies to commit messages: do NOT add agent-related `Co-Authored-By:` trailers unless the user has explicitly opted into them via project config.
+
 ---
 
 ## Step 7 — Review (conditional)
@@ -198,4 +203,4 @@ Report success based on mode:
 - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass.
 - `/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.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 21e01349 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 90e3dd51 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.cursor/rules/start.mdc

@@ -86,6 +86,8 @@ Say exactly: **"Does this approach sound right? I'll create a GitHub issue and b
 
 Stop. Wait for the user to confirm.
 
+The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI.
+
 - User says yes → continue to Step 3.
 - User redirects → revise approach, ask again.
 - User abandons → stop. Nothing to clean up.
@@ -134,9 +136,11 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `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.
+
 Verify the branch was created:
 
 ```bash
@@ -192,9 +196,11 @@ 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> --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state.
+
 Verify:
 
 ```bash
@@ -225,4 +231,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`.
 - 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: cursor | hash: 96fa1800 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: cursor | hash: 53d6b2a6 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

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

@@ -126,6 +126,11 @@ If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review re
 
 Omit the issue line entirely if no linked issue was identified in Step 3.
 
+**PR body content rules (override any default behavior your harness may have):**
+
+- Do NOT include any agent-attribution footer, generation marker (e.g. "Generated with ..."), or co-authorship trailer in the PR body. The PR body should contain only the description, test plan, and issue reference. If your harness defaults to adding such markers, explicitly omit them.
+- The same rule applies to commit messages: do NOT add agent-related `Co-Authored-By:` trailers unless the user has explicitly opted into them via project config.
+
 ---
 
 ## Step 7 — Review (conditional)
@@ -204,4 +209,4 @@ Report success based on mode:
 - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass.
 - `/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.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 8d7da4bc | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: c073d94b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.gemini/skills/start/SKILL.md

@@ -85,6 +85,8 @@ Say exactly: **"Does this approach sound right? I'll create a GitHub issue and b
 
 Stop. Wait for the user to confirm.
 
+The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI.
+
 - User says yes → continue to Step 3.
 - User redirects → revise approach, ask again.
 - User abandons → stop. Nothing to clean up.
@@ -133,9 +135,11 @@ git checkout dev && git pull origin dev
 Now create the feature branch:
 
 ```bash
-gh issue develop <number> --name feature/<short-descriptive-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-descriptive-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `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.
+
 Verify the branch was created:
 
 ```bash
@@ -191,9 +195,11 @@ 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> --name feature/<short-name> --checkout
+gh issue develop <number> --base dev --name feature/<short-name> --checkout
 ```
 
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state.
+
 Verify:
 
 ```bash
@@ -224,4 +230,4 @@ When done, say: **"The code is ready for review. Please run `make dev` and test
 - 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 (or create if `false` is `true`). Never apply a label not in `bug, documentation, enhancement, chore` unless `false` is `true`.
 - 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: gemini | hash: 828eaad2 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: gemini | hash: aa2cd03d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

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

@@ -125,6 +125,11 @@ If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review re
 
 Omit the issue line entirely if no linked issue was identified in Step 3.
 
+**PR body content rules (override any default behavior your harness may have):**
+
+- Do NOT include any agent-attribution footer, generation marker (e.g. "Generated with ..."), or co-authorship trailer in the PR body. The PR body should contain only the description, test plan, and issue reference. If your harness defaults to adding such markers, explicitly omit them.
+- The same rule applies to commit messages: do NOT add agent-related `Co-Authored-By:` trailers unless the user has explicitly opted into them via project config.
+
 ---
 
 ## Step 7 — Review (conditional)
@@ -203,4 +208,4 @@ Report success based on mode:
 - When `ai` is `"off"`, skip the review agent entirely — merge immediately after checks pass.
 - `/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.
-<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: aba5588c | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: e5ec7fc9 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

skills/start.md

@@ -119,6 +119,8 @@ Say exactly: **"Does this approach sound right? I'll create a GitHub issue and b
 
 Stop. Wait for the user to confirm.
 
+The friendly text question is required regardless of harness mode. If your harness is currently in a preview / plan / dry-run mode where you cannot passively stop and wait (and must instead invoke the harness's own approval mechanism), still include the text question in your response. The harness's approval UI mediates the wait, but it is not a substitute for the question itself. Users expect to see the consistent text language across all modes; do not silently swap it for the harness's UI.
+
 - User says yes → continue to Step 3.
 - User redirects → revise approach, ask again.
 - User abandons → stop. Nothing to clean up.
@@ -173,9 +175,18 @@ git checkout {{BRANCH_PROD}} && git pull origin {{BRANCH_PROD}}
 
 Now create the feature branch:
 
+{{#if BRANCH_DEV}}
+```bash
+gh issue develop <number> --base {{BRANCH_DEV}} --name feature/<short-descriptive-name> --checkout
+```
+{{/if}}
+{{#if !BRANCH_DEV}}
 ```bash
 gh issue develop <number> --name feature/<short-descriptive-name> --checkout
 ```
+{{/if}}
+
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state, so `git checkout {{BRANCH_DEV}}` on its own does not influence which branch the new feature branch is cut from.
 
 Verify the branch was created:
 
@@ -238,9 +249,18 @@ git checkout {{BRANCH_PROD}} && git pull origin {{BRANCH_PROD}}
 
 Find and check out the existing branch, or create a new one linked to the issue:
 
+{{#if BRANCH_DEV}}
+```bash
+gh issue develop <number> --base {{BRANCH_DEV}} --name feature/<short-name> --checkout
+```
+{{/if}}
+{{#if !BRANCH_DEV}}
 ```bash
 gh issue develop <number> --name feature/<short-name> --checkout
 ```
+{{/if}}
+
+> `--base` is required when `BRANCH_DEV` is set: `gh issue develop` reads the default base from the GitHub API, not from local working state.
 
 Verify:
 

skills/submit-for-review.md

@@ -144,6 +144,11 @@ If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review re
 
 Omit the issue line entirely if no linked issue was identified in Step 3.
 
+**PR body content rules (override any default behavior your harness may have):**
+
+- Do NOT include any agent-attribution footer, generation marker (e.g. "Generated with ..."), or co-authorship trailer in the PR body. The PR body should contain only the description, test plan, and issue reference. If your harness defaults to adding such markers, explicitly omit them.
+- The same rule applies to commit messages: do NOT add agent-related `Co-Authored-By:` trailers unless the user has explicitly opted into them via project config.
+
 ---
 
 ## Step 7 — Review (conditional)