Agent integrations

Anything that speaks MCP can read a repowise index. This page is about how deeply each agent is wired, which is a different question, and the one every breadth claim in this space gets wrong.

Tiers

The tier is derived from the code, never declared. A descriptor reaches Full only by naming both a hook adapter and a transcript adapter, so no document can claim a depth the integration does not have.

• Full. MCP tools, a managed instructions file, skills, slash commands, hook-level interception of tool calls, and transcript mining after the fact. Every surface repowise has.
• Good. MCP tools, and a managed instructions file or skills where the host reads them. No hook-level interception and no transcript mining. The agent can ask repowise questions; repowise cannot see or annotate what the agent does in between.
• Paste-config. repowise agents print-config <id> emits the MCP server snippet and we write nothing. Zero code and zero maintenance per host.

The matrix

Yes means repowise wires it. Plugin means the host's own plugin ships it and repowise does not write it. No means the surface does not exist for that agent.

Agent	Tier	MCP	Hooks	Skills	Commands	Instructions	Transcripts
Claude Code	Full	Yes	Yes	Plugin	Plugin	Yes	Yes
Codex CLI	Full	Yes	Yes	Plugin	Yes	Yes	Yes
VS Code	Good	Yes	No	No	No	No	No
Cursor	Good	Yes	No	No	No	Yes	No
OpenCode	Good	Yes	No	No	No	Yes	No
Hermes	Good	Yes	No	No	No	Yes	No

Target ids for --target=: claude-code, codex, vscode, cursor, opencode, hermes.

What Good tier does not include

VS Code, Cursor, OpenCode and Hermes sit at Good, and the honest version of that is worth stating plainly. These agents get the MCP tools and the config repowise writes. They do not get hook-level interception: repowise never sees a tool call before it runs, never rewrites a noisy command, and never annotates a result afterwards. Nor is there transcript mining, so nothing learns from the session after it ends.

That is a real integration and it is most of the value. It is not the same product Full-tier agents get, and breadth that overclaims depth is worse than narrower breadth.

Paste-config

Every other MCP host is served without writing a descriptor for it. Print the server entry and paste it into whatever config that host reads:

repowise agents print-config claude-code   # prints, writes nothing

Ask for the target id whose host is closest to yours rather than editing a snippet by hand. The shapes genuinely differ, and not only in their wrapper: hosts disagree about the top-level key, about whether each entry carries a type field, about whether the invocation is one array or a command plus a separate argument list, and about the file format itself, so codex prints TOML and hermes prints YAML where the others print JSON. claude-code is the plain mcpServers JSON most hosts read and is the right default when yours is not listed below. Hosts people ask about most, none of which repowise writes config for today:

Cline, Windsurf, Zed, Continue, Gemini CLI, JetBrains AI Assistant, Amp.

print-config takes one of the target ids above; there is no descriptor to name for a host at this tier, which is the point of the tier.

The MCP surface

repowise registers seventeen MCP tools. A single-repo server advertises ten of them by default, and workspace mode adds one more automatically for eleven. A further six are off by default, enabled through the mcp.tools config block or --tools +name. The lean profile trims the default surface to six tools (seven in workspace mode) for agents on a tight context budget.

Per-tool detail: MCP_TOOLS.md.

Adding an agent

Adding an agent takes one descriptor file and one registry line.

1. Write packages/cli/src/repowise/cli/agent_targets/targets/<id>.py exporting a TARGET that satisfies the AgentTarget protocol in types.py. vscode.py is the smallest working example, at one install method and one config file.
2. Add one line to _TARGET_MODULES in registry.py. Order there is the order agents appear in prompts, in --target=all and in listings, so keep it stable.
3. Run python scripts/gen_agent_matrix.py to add the row here.

There is no third file for anything derived. The tier, this matrix and the repowise agents listing all read the descriptor, and the contract tests in tests/unit/cli/test_agent_targets.py are parameterized over the registry, so a new target inherits them.

The README badge rows are the exception: a brand colour and a logo per agent are not derivable, and the README is not generated, so a new agent needs a badge added by hand and the count above them updated. That is checked rather than trusted. tests/unit/cli/test_agent_matrix.py fails when the badge rows and the registry disagree, and names what to add.

Declare only what the agent genuinely has. derive_tier reads the adapter names, so a descriptor that names a hook adapter it has not implemented publishes a Full-tier claim on this page.