Regenerate start skill adapter files after body-file conversion

.agents/skills/start/SKILL.md

@@ -98,12 +98,16 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
-  [--milestone "<resolved milestone>"]
+  [--milestone "<resolved milestone>"] \
+  --body-file - <<'EOF'
+<structured markdown body — see sections below>
+EOF
 ```
 
+> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc avoids this — the matcher sees a clean `gh …` invocation and `Bash(gh:*)` matches.
+
 Resolve labels and milestone using the resolution steps in the Parsing section above:
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
@@ -148,9 +152,11 @@ Show the user: `Created issue #<number>: <title>`
 Then immediately post agent implementation notes as a comment:
 
 ```bash
-gh issue comment <number> --body "## Agent Implementation Notes
+gh issue comment <number> --body-file - <<'EOF'
+## Agent Implementation Notes
 
-<full technical plan: exact files to change, approach, key decisions, edge cases>"
+<full technical plan: exact files to change, approach, key decisions, edge cases>
+EOF
 ```
 
 ### Step 4 — Create feature branch
@@ -264,4 +270,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 `--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: 8f527994 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: codex | hash: 5603cf1a | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.claude/commands/start.md

@@ -93,12 +93,16 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
-  [--milestone "<resolved milestone>"]
+  [--milestone "<resolved milestone>"] \
+  --body-file - <<'EOF'
+<structured markdown body — see sections below>
+EOF
 ```
 
+> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc avoids this — the matcher sees a clean `gh …` invocation and `Bash(gh:*)` matches.
+
 Resolve labels and milestone using the resolution steps in the Parsing section above:
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
@@ -143,9 +147,11 @@ Show the user: `Created issue #<number>: <title>`
 Then immediately post agent implementation notes as a comment:
 
 ```bash
-gh issue comment <number> --body "## Agent Implementation Notes
+gh issue comment <number> --body-file - <<'EOF'
+## Agent Implementation Notes
 
-<full technical plan: exact files to change, approach, key decisions, edge cases>"
+<full technical plan: exact files to change, approach, key decisions, edge cases>
+EOF
 ```
 
 ### Step 4 — Create feature branch
@@ -259,4 +265,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 `--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: claude | hash: 70ba0327 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: claude | hash: 3c1bac69 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.cursor/rules/start.mdc

@@ -99,12 +99,16 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
-  [--milestone "<resolved milestone>"]
+  [--milestone "<resolved milestone>"] \
+  --body-file - <<'EOF'
+<structured markdown body — see sections below>
+EOF
 ```
 
+> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc avoids this — the matcher sees a clean `gh …` invocation and `Bash(gh:*)` matches.
+
 Resolve labels and milestone using the resolution steps in the Parsing section above:
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
@@ -149,9 +153,11 @@ Show the user: `Created issue #<number>: <title>`
 Then immediately post agent implementation notes as a comment:
 
 ```bash
-gh issue comment <number> --body "## Agent Implementation Notes
+gh issue comment <number> --body-file - <<'EOF'
+## Agent Implementation Notes
 
-<full technical plan: exact files to change, approach, key decisions, edge cases>"
+<full technical plan: exact files to change, approach, key decisions, edge cases>
+EOF
 ```
 
 ### Step 4 — Create feature branch
@@ -265,4 +271,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 `--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: cursor | hash: 563587df | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: cursor | hash: fad7e3ef | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

.gemini/skills/start/SKILL.md

@@ -98,12 +98,16 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
-  [--milestone "<resolved milestone>"]
+  [--milestone "<resolved milestone>"] \
+  --body-file - <<'EOF'
+<structured markdown body — see sections below>
+EOF
 ```
 
+> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc avoids this — the matcher sees a clean `gh …` invocation and `Bash(gh:*)` matches.
+
 Resolve labels and milestone using the resolution steps in the Parsing section above:
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
@@ -148,9 +152,11 @@ Show the user: `Created issue #<number>: <title>`
 Then immediately post agent implementation notes as a comment:
 
 ```bash
-gh issue comment <number> --body "## Agent Implementation Notes
+gh issue comment <number> --body-file - <<'EOF'
+## Agent Implementation Notes
 
-<full technical plan: exact files to change, approach, key decisions, edge cases>"
+<full technical plan: exact files to change, approach, key decisions, edge cases>
+EOF
 ```
 
 ### Step 4 — Create feature branch
@@ -264,4 +270,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 `--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: gemini | hash: 8d797a55 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
+<!-- generated by CodeCannon/sync.sh | skill: start | adapter: gemini | hash: 064b9454 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->

skills/start.md

@@ -141,12 +141,16 @@ Run `gh issue create` with explicit flags (do NOT open an interactive editor):
 ```bash
 gh issue create \
   --title "<standalone full sentence — must make sense with no context>" \
-  --body "<structured markdown body — see sections below>" \
   --assignee @me \
   [--label "<resolved labels>"] \
-  [--milestone "<resolved milestone>"]
+  [--milestone "<resolved milestone>"] \
+  --body-file - <<'EOF'
+<structured markdown body — see sections below>
+EOF
 ```
 
+> **Why `--body-file -` + stdin heredoc?** Claude Code's permission matcher refuses to extend any `Bash(gh:*)` allow rule over a command containing `$(...)` substitution, so `--body "$(cat <<'EOF' ...)"` triggers a Yes/No prompt on every run with no "Allow always" option. Piping the body in on stdin via heredoc avoids this — the matcher sees a clean `gh …` invocation and `Bash(gh:*)` matches.
+
 Resolve labels and milestone using the resolution steps in the Parsing section above:
 - **Labels**: use the value from three-tier label resolution. If non-empty, add `--label "<value>"` to the command. If empty (no flag, empty pool, creation not allowed), omit `--label` entirely.
 - **Milestone**: use the value from three-tier milestone resolution. If non-empty, add `--milestone "<value>"` to the command. If empty (no flag, no config default, no open milestones), omit `--milestone` entirely.
@@ -191,9 +195,11 @@ Show the user: `Created issue #<number>: <title>`
 Then immediately post agent implementation notes as a comment:
 
 ```bash
-gh issue comment <number> --body "## Agent Implementation Notes
+gh issue comment <number> --body-file - <<'EOF'
+## Agent Implementation Notes
 
-<full technical plan: exact files to change, approach, key decisions, edge cases>"
+<full technical plan: exact files to change, approach, key decisions, edge cases>
+EOF
 ```
 
 ### Step 4 — Create feature branch