Stop committing capability claims about specific agent backends; phrase skills conditionally

[sebastientaggart]

Problem to Fix

Code Cannon's documentation and adapter configs assert which features each supported agent does and does not have. Those assertions have gone stale.

docs/adapters.md states that sub-agent spawning is unavailable in Cursor, Codex CLI, and Gemini CLI. The notes: blocks in adapters/cursor/config.yaml, adapters/codex/config.yaml, and adapters/gemini/config.yaml each repeat the same claim, along with the instruction that the review step must therefore be performed manually by pasting a prompt into a new session.

All three claims are now false. Every one of those agents has since shipped project-scoped, file-defined subagents, each with its own model configuration that defaults to inheriting the parent session. The claims were accurate when written and became wrong within about a year, without anything in this repo changing.

The /review skill already handles this correctly. Its Step 2 branches on "if sub-agent spawning is supported" versus "if sub-agent spawning is not supported" — it asks the running agent about its own capabilities rather than consulting a table written months earlier. That phrasing has never gone stale. The enumerations elsewhere are what rotted.

Why it Matters

The stale claims actively mislead. A Gemini or Codex user reading docs/adapters.md is told to do manual work the tool no longer requires, and the adapter notes tell them the same thing a second time. The one place that gets it right is the place that avoided making a claim at all.

There is a general lesson here worth encoding rather than just patching. The agent landscape is changing monthly, and any committed statement about what a specific backend can do is a maintenance liability with no expiry date on it — nothing fails, no test breaks, the file simply becomes wrong and stays wrong until somebody happens to notice. Capability-conditional phrasing has no such decay: it is correct before a feature exists, correct after, and correct during the window where some users have it and some do not.

This came out of researching whether Code Cannon should offer per-task model tiering. The research concluded it should not (see #181), but it surfaced this as the genuinely fragile thing already in the repo.

General Approach

Remove the capability claims rather than updating them. Updating them just resets a clock that will run out again.

In docs/adapters.md, drop the per-adapter "Limitation: X does not support sub-agent spawning" paragraphs and the corresponding column content in the support table. Where a skill's behaviour genuinely depends on a backend feature, describe the conditional behaviour instead of naming which backends fall on which side.

In the three adapter config.yaml notes: blocks, remove the sub-agent claims and the manual-fallback instructions. Keep the invocation mechanics — how a user triggers a rule or skill on that agent, what the trigger syntax is, where the files land. Those are slow-moving facts about how the integration works, not fast-moving facts about what the vendor shipped last month. Establish that split explicitly so future adapter notes follow it.

Sweep the skill bodies for any other place that names a specific backend's capabilities and convert it to the conditional form the /review skill already uses. Add the rule to AGENTS.md alongside the existing skill-design guidance, so it applies to new skills and new adapters without needing to be rediscovered.

Deliberately out of scope: adding a replacement capability matrix anywhere, in any form. A corrected table is the same liability with a later expiry date.

Complexity

Verification / QA effort: light

The changes are prose in documentation, adapter notes, and skill bodies. No engine changes. Verification is reading the result for any remaining backend-specific capability claim, plus a sync run to confirm the regenerated adapter output carries the corrected notes.

Acceptance Criteria

• No file in docs/, adapters/*/config.yaml, or skills/ asserts that a named backend does or does not support sub-agent spawning.
• Adapter notes: blocks describe invocation mechanics only; the split between mechanics and feature availability is stated where future contributors will find it.
• Any skill behaviour that depends on a backend feature is expressed conditionally, in the form already used by the /review skill's Step 2.
• AGENTS.md records the rule: never commit capability claims about a backend; phrase capability-conditionally instead.
• No replacement capability matrix is introduced.
• ./sync.py --force is run and the regenerated adapter output is committed alongside the source changes.