diff --git a/.agents/skills/submit-for-review/SKILL.md b/.agents/skills/submit-for-review/SKILL.md index 31d60a8..d3a5d30 100644 --- a/.agents/skills/submit-for-review/SKILL.md +++ b/.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 +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 && make -n 2>/dev/null +cd "$(git rev-parse --show-toplevel)" && make -n 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. - + diff --git a/.claude/commands/submit-for-review.md b/.claude/commands/submit-for-review.md index 0cfa625..3301719 100644 --- a/.claude/commands/submit-for-review.md +++ b/.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 +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 && make -n 2>/dev/null +cd "$(git rev-parse --show-toplevel)" && make -n 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. - + diff --git a/.cursor/rules/submit-for-review.mdc b/.cursor/rules/submit-for-review.mdc index 0e647df..29a2dfe 100644 --- a/.cursor/rules/submit-for-review.mdc +++ b/.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 +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 && make -n 2>/dev/null +cd "$(git rev-parse --show-toplevel)" && make -n 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. - + diff --git a/.gemini/skills/submit-for-review/SKILL.md b/.gemini/skills/submit-for-review/SKILL.md index 6503e61..d2dfef2 100644 --- a/.gemini/skills/submit-for-review/SKILL.md +++ b/.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 +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 && make -n 2>/dev/null +cd "$(git rev-parse --show-toplevel)" && make -n 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. - + diff --git a/docs/index.md b/docs/index.md index 74b590c..b120926 100644 --- a/docs/index.md +++ b/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 diff --git a/skills/submit-for-review.md b/skills/submit-for-review.md index a2a2564..7dd5d95 100644 --- a/skills/submit-for-review.md +++ b/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 +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 && make -n 2>/dev/null +cd "$(git rev-parse --show-toplevel)" && make -n 2>/dev/null ``` If `make -n` exits non-zero, **stop** and say: