Skip to content

Use gh --body-file - stdin heredoc to preserve Bash(gh:*) permission match #86

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
sebastientaggart merged 1 commit into from
Apr 9, 2026
Merged

Use gh --body-file - stdin heredoc to preserve Bash(gh:*) permission match #86

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 3 additions & 5 deletions .agents/skills/deploy/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,7 +169,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
```bash
gh pr create --base main --head dev \
--title "Release vX.Y.Z" \
--body "$(cat <<'EOF'
--body-file - <<'EOF'
Release vX.Y.Z

PRs included:
Expand All @@ -179,7 +179,6 @@ PRs included:
Closes #14
Closes #15
EOF
)"
```

Note the PR number from the output.
Expand Down Expand Up @@ -215,15 +214,14 @@ Create the release:
```bash
gh release create <version-tag> \
--title "<version-tag>" \
--notes "$(cat <<'EOF'
--notes-file - <<'EOF'
## Changes

- #<issue> — <PR title> (PR #<pr-number>)
[... one line per PR included in this release ...]

**Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag>
EOF
)"
```

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.
Expand All @@ -237,4 +235,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: 2a98511e | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: codex | hash: 0e47902b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
12 changes: 6 additions & 6 deletions .agents/skills/submit-for-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,14 +111,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de

Then create the PR with explicit title and body (never use an interactive editor):
```
gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF'
<description of what changed and why>

<Closes #N OR Issue #N, based on target above>
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 redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags).

Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames.

If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top.
Expand Down Expand Up @@ -227,15 +228,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is
```
gh issue create \
--title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \
--body "$(cat <<'EOF'
--body-file - \
[--label "<pool-selected labels>"] <<'EOF'
Follow-up from PR #<merged-pr-number> — auto-proposed from the code review.

**Finding:** <full finding text, prefix included>

See the review comment on the PR for context.
EOF
)" \
[--label "<pool-selected labels>"]
```

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.
Expand All @@ -261,4 +261,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: 6957b622 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: codex | hash: 61513e5d | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
8 changes: 3 additions & 5 deletions .claude/commands/deploy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -164,7 +164,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
```bash
gh pr create --base main --head dev \
--title "Release vX.Y.Z" \
--body "$(cat <<'EOF'
--body-file - <<'EOF'
Release vX.Y.Z

PRs included:
Expand All @@ -174,7 +174,6 @@ PRs included:
Closes #14
Closes #15
EOF
)"
```

Note the PR number from the output.
Expand Down Expand Up @@ -210,15 +209,14 @@ Create the release:
```bash
gh release create <version-tag> \
--title "<version-tag>" \
--notes "$(cat <<'EOF'
--notes-file - <<'EOF'
## Changes

- #<issue> — <PR title> (PR #<pr-number>)
[... one line per PR included in this release ...]

**Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag>
EOF
)"
```

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.
Expand All @@ -232,4 +230,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: claude | hash: f84c747b | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: claude | hash: b1efee29 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
12 changes: 6 additions & 6 deletions .claude/commands/submit-for-review.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,14 +106,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de

Then create the PR with explicit title and body (never use an interactive editor):
```
gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF'
<description of what changed and why>

<Closes #N OR Issue #N, based on target above>
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 redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags).

Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames.

If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top.
Expand Down Expand Up @@ -222,15 +223,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is
```
gh issue create \
--title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \
--body "$(cat <<'EOF'
--body-file - \
[--label "<pool-selected labels>"] <<'EOF'
Follow-up from PR #<merged-pr-number> — auto-proposed from the code review.

**Finding:** <full finding text, prefix included>

See the review comment on the PR for context.
EOF
)" \
[--label "<pool-selected labels>"]
```

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.
Expand All @@ -256,4 +256,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: claude | hash: d5d59df8 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: claude | hash: 2aa076dc | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
8 changes: 3 additions & 5 deletions .cursor/rules/deploy.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -170,7 +170,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
```bash
gh pr create --base main --head dev \
--title "Release vX.Y.Z" \
--body "$(cat <<'EOF'
--body-file - <<'EOF'
Release vX.Y.Z

PRs included:
Expand All @@ -180,7 +180,6 @@ PRs included:
Closes #14
Closes #15
EOF
)"
```

Note the PR number from the output.
Expand Down Expand Up @@ -216,15 +215,14 @@ Create the release:
```bash
gh release create <version-tag> \
--title "<version-tag>" \
--notes "$(cat <<'EOF'
--notes-file - <<'EOF'
## Changes

- #<issue> — <PR title> (PR #<pr-number>)
[... one line per PR included in this release ...]

**Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag>
EOF
)"
```

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.
Expand All @@ -238,4 +236,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: cursor | hash: bb0fe2f1 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: cursor | hash: 96c1037f | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
12 changes: 6 additions & 6 deletions .cursor/rules/submit-for-review.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,14 +112,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de

Then create the PR with explicit title and body (never use an interactive editor):
```
gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF'
<description of what changed and why>

<Closes #N OR Issue #N, based on target above>
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 redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags).

Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames.

If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top.
Expand Down Expand Up @@ -228,15 +229,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is
```
gh issue create \
--title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \
--body "$(cat <<'EOF'
--body-file - \
[--label "<pool-selected labels>"] <<'EOF'
Follow-up from PR #<merged-pr-number> — auto-proposed from the code review.

**Finding:** <full finding text, prefix included>

See the review comment on the PR for context.
EOF
)" \
[--label "<pool-selected labels>"]
```

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.
Expand All @@ -262,4 +262,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: cursor | hash: 71f7fe12 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: cursor | hash: 7fefc571 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
8 changes: 3 additions & 5 deletions .gemini/skills/deploy/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,7 +169,7 @@ Wait for the user to type "release" or an explicit confirmation. Any other respo
```bash
gh pr create --base main --head dev \
--title "Release vX.Y.Z" \
--body "$(cat <<'EOF'
--body-file - <<'EOF'
Release vX.Y.Z

PRs included:
Expand All @@ -179,7 +179,6 @@ PRs included:
Closes #14
Closes #15
EOF
)"
```

Note the PR number from the output.
Expand Down Expand Up @@ -215,15 +214,14 @@ Create the release:
```bash
gh release create <version-tag> \
--title "<version-tag>" \
--notes "$(cat <<'EOF'
--notes-file - <<'EOF'
## Changes

- #<issue> — <PR title> (PR #<pr-number>)
[... one line per PR included in this release ...]

**Full changelog:** https://github.com/<owner>/<repo>/compare/<previous-tag>...<version-tag>
EOF
)"
```

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.
Expand All @@ -237,4 +235,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: gemini | hash: adfc11de | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: deploy | adapter: gemini | hash: cde00382 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
12 changes: 6 additions & 6 deletions .gemini/skills/submit-for-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,14 +111,15 @@ Use `Issue #<number>` as the issue reference — the issue stays open until `/de

Then create the PR with explicit title and body (never use an interactive editor):
```
gh pr create --base <target-branch> --title "<title>" --body "$(cat <<'EOF'
gh pr create --base <target-branch> --title "<title>" --body-file - <<'EOF'
<description of what changed and why>

<Closes #N OR Issue #N, based on target above>
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 redirection is not command substitution — the matcher sees a clean `gh pr create …` invocation and `Bash(gh:*)` matches. Apply this pattern to every multi-line `--body` / `--notes` in skills (`gh pr create`, `gh issue create`, `gh issue comment`, and `gh release create` all accept `-` for their `*-file` flags).

Add `--reviewer` to the `gh pr create` command above using the handles from `@sebastientaggart`. Before passing them, strip any leading `@` from each comma-separated handle (e.g. `@alice,@org/team` becomes `alice,org/team`) — the `gh` CLI requires bare usernames.

If a CODEOWNERS file exists, both apply: CODEOWNERS triggers automatic review requests from GitHub; the `--reviewer` flag adds the explicitly configured handles on top.
Expand Down Expand Up @@ -227,15 +228,14 @@ Accept: comma-separated numbers, `all`, or `none`/`skip`/empty. If the input is
```
gh issue create \
--title "<finding text with [WARNING]/[NOTE]/[CRITICAL] prefix stripped, trimmed to a standalone sentence>" \
--body "$(cat <<'EOF'
--body-file - \
[--label "<pool-selected labels>"] <<'EOF'
Follow-up from PR #<merged-pr-number> — auto-proposed from the code review.

**Finding:** <full finding text, prefix included>

See the review comment on the PR for context.
EOF
)" \
[--label "<pool-selected labels>"]
```

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.
Expand All @@ -261,4 +261,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: gemini | hash: 39738177 | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
<!-- generated by CodeCannon/sync.sh | skill: submit-for-review | adapter: gemini | hash: c5b1249c | DO NOT EDIT — run CodeCannon/sync.sh to regenerate -->
Loading