Revert command substitution workaround and add agent permission docs

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

@@ -35,13 +35,7 @@ If the current branch matches any of the above, **abort immediately** and say:
 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>
+cd "$(git rev-parse --show-toplevel)"
 ```
 
 Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
@@ -197,13 +191,7 @@ Wait for the review to complete and report its 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
+cd "$(git rev-parse --show-toplevel)" && make -n <target> 2>/dev/null
 ```
 
 If `make -n` exits non-zero, **stop** and say:
@@ -366,4 +354,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: 9a2a2201 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: codex | hash: 238dcd17 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

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

@@ -30,13 +30,7 @@ If the current branch matches any of the above, **abort immediately** and say:
 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>
+cd "$(git rev-parse --show-toplevel)"
 ```
 
 Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
@@ -192,13 +186,7 @@ Wait for the review to complete and report its 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
+cd "$(git rev-parse --show-toplevel)" && make -n <target> 2>/dev/null
 ```
 
 If `make -n` exits non-zero, **stop** and say:
@@ -361,4 +349,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: 0696458e | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: claude | hash: 462fa2e7 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

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

@@ -36,13 +36,7 @@ If the current branch matches any of the above, **abort immediately** and say:
 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>
+cd "$(git rev-parse --show-toplevel)"
 ```
 
 Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
@@ -198,13 +192,7 @@ Wait for the review to complete and report its 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
+cd "$(git rev-parse --show-toplevel)" && make -n <target> 2>/dev/null
 ```
 
 If `make -n` exits non-zero, **stop** and say:
@@ -367,4 +355,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: 807ac0ec | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: cursor | hash: 5e083f10 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

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

@@ -35,13 +35,7 @@ If the current branch matches any of the above, **abort immediately** and say:
 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>
+cd "$(git rev-parse --show-toplevel)"
 ```
 
 Then verify the make target exists before running it. Extract the target name from `make check` (e.g. `make check` → `check`) and run:
@@ -197,13 +191,7 @@ Wait for the review to complete and report its 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
+cd "$(git rev-parse --show-toplevel)" && make -n <target> 2>/dev/null
 ```
 
 If `make -n` exits non-zero, **stop** and say:
@@ -366,4 +354,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: gemini | hash: b7032894 | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->
+<!-- generated by CodeCannon/sync.py | skill: submit-for-review | adapter: gemini | hash: 78fffcae | DO NOT EDIT — run CodeCannon/sync.py to regenerate -->

docs/index.md

@@ -104,6 +104,53 @@ If your project still uses the previous repo URL or folder name:
 2. Rename `.agentgate.yaml` to `.codecannon.yaml`.
 3. Run `CodeCannon/sync.py --force` once if needed so generated file headers match the new provenance marker.
 
+## Agent tips and tweaks
+
+Code Cannon skills are agent-agnostic, but each agent has its own quirks. This section collects per-agent configuration tips that smooth out the experience.
+
+### Claude Code
+
+**Reduce approval prompts.** Claude Code prompts for permission on shell commands that contain command substitutions (`$(...)`) or certain patterns. Pre-approve the commands Code Cannon uses by adding a `permissions` block to `.claude/settings.json` (project-level, committed) or `.claude/settings.local.json` (personal, git-ignored):
+
+```json
+{
+  "permissions": {
+    "defaultMode": "acceptEdits",
+    "allow": [
+      "Bash(git *)",
+      "Bash(gh *)",
+      "Bash(make *)",
+      "Bash(python3 *)",
+      "Bash(./sync.py *)",
+      "Bash(mkdir *)",
+      "Bash(mktemp *)"
+    ],
+    "deny": [
+      "Bash(git push --force)",
+      "Bash(git push --force *)",
+      "Bash(git reset --hard)",
+      "Bash(git reset --hard *)",
+      "Bash(rm -rf *)",
+      "Bash(sudo *)"
+    ]
+  }
+}
+```
+
+`defaultMode: "acceptEdits"` auto-approves file edits and common filesystem ops. `allow` rules pre-approve matching bash commands (wildcards supported). `deny` rules always win — dangerous operations still prompt. Adjust the `allow` list to match your project's tooling.
+
+### Cursor
+
+Cursor does not prompt for shell commands by default, so no permission configuration is needed. Skills work out of the box.
+
+### Codex
+
+Configure via the `codex` CLI's `--full-auto` flag or sandbox settings. Codex runs in a sandboxed environment, so approval prompts are less common but network access may need to be explicitly enabled for `gh` commands.
+
+### Gemini CLI
+
+Configure via `.gemini/settings.json` or the `--auto-approve` flag. Consult Gemini CLI documentation for the latest permission options.
+
 ## Further reading
 
 - [Branching models](branching.md) — trunk, two-branch, and three-branch workflows explained

skills/submit-for-review.md

@@ -38,13 +38,7 @@ If the current branch matches any of the above, **abort immediately** and say:
 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>
+cd "$(git rev-parse --show-toplevel)"
 ```
 
 Then verify the make target exists before running it. Extract the target name from `{{CHECK_CMD}}` (e.g. `make check` → `check`) and run:
@@ -216,13 +210,7 @@ Wait for the review to complete and report its verdict.
 Before merging, verify the merge target exists. Move to the repo root, extract the target name from `{{MERGE_CMD}}` (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
+cd "$(git rev-parse --show-toplevel)" && make -n <target> 2>/dev/null
 ```
 
 If `make -n` exits non-zero, **stop** and say: