[sebastientaggart]

What changed

Removes committed claims about which agent backends can or cannot do something, and replaces backend-naming branches in skills with capability-conditional phrasing.

• docs/adapters.md — dropped the "can spawn a review sub-agent natively" sentence and the "Limitation: these tools do not support sub-agent spawning" paragraph. Added a short "Feature availability" section explaining why the docs do not say which agent has which feature. The "Adding a new adapter" step now asks for invocation mechanics only.
• adapters/agents/config.yaml — notes cut to the trigger sentence; a comment above notes: states the mechanics-only rule.
• Skills (review, submit-for-review, review-agent, setup) — removed the "(e.g. Claude Code)" / "(Codex, Cursor, Gemini)" parentheticals; the bare conditionals remain. setup Phase 2 now branches on whether the harness reads its allowlist from .claude/settings.json rather than on agent name.
• AGENTS.md — new "Backend capability claims" subsection: the rule, the mechanics-vs-availability split for adapter notes, and no capability matrix.
• Regenerated .claude/skills/ and .agents/skills/ via ./sync.py --force.

Why

The claims were accurate when written and went stale without anything in this repo changing. Conditional phrasing does not decay: the running agent takes whichever branch is true for it at the time.

Notes

• The issue named the cursor, codex, and gemini adapter configs; those are now bare aliases, so the claim lived once in adapters/agents/config.yaml.
• Not touched: the per-agent permission notes in docs/index.md (outside the sub-agent scope of the issue), and file-location mentions such as the "read natively by" table.

Test plan

• make check passes
• make test passes (212 tests)
• Grep of docs/, adapters/, skills/ for sub-agent claims tied to a named backend returns none

Closes #217

[sebastientaggart]

[low] This rule ("never commit a statement about what a specific agent backend can or cannot do — in skills, adapter configs, or docs") is already violated by files this PR leaves untouched, so the repo is inconsistent with its own policy on merge:

• config.schema.yaml:84 — REVIEW_EFFORT description still says "(e.g. Claude Code's /code-review)"; the same parenthetical was removed from setup/SKILL.md and review-agent/SKILL.md here.
• templates/codecannon.yaml:48 — "native review engine (Claude Code /code-review)", shipped to every consumer project.
• docs/index.md:148-158 — "Cursor does not prompt for shell commands by default", Codex --full-auto / sandbox behaviour, Gemini --auto-approve. This is the exact claim deleted from setup Phase 2.5 ("Cursor doesn't prompt, and Codex/Gemini permission systems vary"), and the rewritten skill now points agents at these docs ("the docs cover them separately").

Scenario: an agent or contributor following the new section greps for the reference phrasing, finds the schema/template still naming Claude Code as the backend with a native reviewer, and either copies that pattern back into a skill or trusts a stale claim the PR set out to remove.

[sebastientaggart]

[low] The new condition is answerable from the wrong evidence. "If your harness reads its permission allowlist from .claude/settings.json" asks the agent a fact about its own harness, but the file it names is one the claude adapter commits into the repo (permissions_file), so it exists in any project that lists both claude and agents.

Scenario: a multi-adapter project, /setup run from a non-Claude harness on a smaller model. The agent sees .claude/settings.json present, takes this branch instead of Otherwise, and either prints Agent permissions: all skill commands pre-approved (false for that harness — it will still prompt) or tells the user to add Bash(<cmd>:*) rules to .claude/settings.local.json, which that harness never reads. The old **Claude Code:** label could not be mis-taken this way.

Phrasing the condition on the harness rather than the file's presence closes it, e.g. "If your harness's own permission allowlist is the permissions.allow array in .claude/settings.json (the file existing in the repo is not evidence of this)".

[sebastientaggart]

Code Cannon review

Sensitive-area gate: not triggered — the diff is prose in docs, adapter notes, and skill bodies; no authentication, payment, secrets, production-config, or destructive-operation surface is touched.

[WARNING] The new "Backend capability claims" rule in AGENTS.md is already contradicted by files this PR leaves untouched: config.schema.yaml:84 ("e.g. Claude Code's /code-review"), templates/codecannon.yaml:48 ("native review engine (Claude Code /code-review)"), and the per-agent permission claims in docs/index.md:148-158, which the rewritten setup skill now points agents at.

[WARNING] skills/github-agile/setup/SKILL.md:246 — the condition "If your harness reads its permission allowlist from .claude/settings.json" can be answered from the wrong evidence. The claude adapter commits that file, so it exists in any project listing both claude and agents; a weaker model on another harness may see the file, take this branch, and report on or recommend edits to a settings file its harness never reads. The condition should say that the file existing is not evidence.

Verdict: APPROVE

[sebastientaggart]

[medium] Dropping the (Claude Code) anchor widens this branch to any harness that has something called /code-review, but the body of the branch is still written for one specific implementation: /code-review {{REVIEW_EFFORT}} --comment, the low/medium/high positional, and "that positional is only for the ultra cloud path".

Scenario: an agent on another harness has a user-authored or vendor /code-review skill with a different argument contract. It truthfully takes this branch, passes medium --comment, and the skill either ignores the effort arg, treats medium as a review target, or does not post findings to the PR. The inline fallback (which is the path that harness should have taken) is skipped, so the review labor is degraded while Step 8 still routes on an APPROVE verdict.

The condition should test the contract, not the name — e.g. "If a native /code-review skill is available that accepts an effort level and --comment", with anything else falling through to the inline path.

[sebastientaggart]

[low] The hardcoded prefix list (git, gh, make, python3, ./sync.py, mkdir, mktemp) does not match what the skills actually run. permissions.yaml commands: is cp, gh, git, gpg, grep, make, mkdir, mktemp, python3, test, which — so cp, gpg, grep, test, and which are missing here (and ./sync.py is not in the canonical list).

Scenario: a user on a non-Claude agent pre-approves exactly these seven prefixes as instructed and still gets prompted mid-skill on grep/test/which/cp/gpg. This is the only permission guidance left for those agents after this PR removed the per-agent sections, so it should point at CodeCannon/permissions.yaml (commands: key) rather than restating a list that has already drifted. (The Claude Code JSON example above has the same pre-existing drift.)

[sebastientaggart]

[low] "the docs cover them separately" is no longer true after this same PR. docs/index.md replaced the Cursor / Codex / Gemini sections with "Other agents", which says "this page does not describe them".

Scenario: an agent on a non-.claude/settings.json harness skips the audit silently on the strength of this clause; if the user asks where the permission guidance is, the skill points at docs that explicitly decline to give it. Either drop the clause or reword it to match what the docs now offer (pre-approve the commands: prefixes from CodeCannon/permissions.yaml using the agent's own mechanism). Regenerate with make sync after editing.

[sebastientaggart]

Code Cannon review (second pass)

Sensitive-area gate: not triggered — the diff is prose in docs, adapter notes, config comments, and skill bodies; no authentication, payment, secrets, production-config, or destructive-operation surface is touched.

[WARNING] skills/github-agile/submit-for-review/SKILL.md:187 — with the "(Claude Code)" anchor removed, the branch now matches any harness that has something named /code-review, while the branch body still assumes one specific contract (an effort-level argument and --comment). A harness with a differently shaped skill would take this branch, mis-invoke it, and skip the inline fallback. The condition should test the contract rather than the name.

[WARNING] docs/index.md:150 — the new "Other agents" paragraph hardcodes seven command prefixes that do not match permissions.yaml: it omits cp, gpg, grep, test, and which, and lists ./sync.py, which is not there. It should point at permissions.yaml instead of restating the list.

[WARNING] skills/github-agile/setup/SKILL.md:252 — "the docs cover them separately" is no longer true: docs/index.md now says it does not describe other agents' permission systems. Drop or reword the clause.

[NOTE] Backend-naming lines outside this diff remain: the auto-mode classifier note in the deploy skill and its doc page, the "works without prompts across Claude Code, Gemini CLI, Cursor, and Codex" sentence in the prompt-avoidance blocks of the start and submit-for-review skills, and the Cursor trigger line in templates/AGENTS.md.template.

Verdict: APPROVE

[sebastientaggart]

Code Cannon review (third pass)

Sensitive-area gate: not triggered — the diff is prose in docs, adapter notes, config comments, and skill bodies; no authentication, payment, secrets, production-config, or destructive-operation surface is touched.

[NOTE] The submit-for-review skill now takes the inline review path when a /code-review skill exists but has a different interface. The REVIEW_EFFORT descriptions in the config schema, the config template, and the setup skill still say only "a /code-review skill"; on such a harness REVIEW_EFFORT is silently ignored, which is the safe direction.

Verdict: APPROVE