#Targets and capability map

Use this page to answer what to author, which output to select, and where the limits are. For a first working tool, start with Quick start. For the precise, versioned host behavior, use the generated matrices rather than assuming every host implements the same plugin interface.

#All built-in output targets

These are the five built-in values of targets in agent-bundle.config.ts. They select what the compiler emits, not an account, a model, or a running development session.

Omitting targets selects portable alone. Explicit selection replaces that default:

import { 
const defineConfig: (config: AgentBundleConfig | ConfigFactory) => AgentBundleConfig | ConfigFactorydefineConfig } from 'agent-bundle/config';

export default 
function defineConfig(config: AgentBundleConfig | ConfigFactory): AgentBundleConfig | ConfigFactorydefineConfig({
  
AgentBundleConfig.plugin: AgentBundlePluginConfigplugin: { 
AgentBundlePluginConfig.name: stringname: 'project-tools', 
AgentBundlePluginConfig.description?: string | undefineddescription: 'Tools for this project.' },
  
AgentBundleConfig.targets?: string[] | undefinedtargets: ['claude', 'codex', 'cursor'],
});

To select different projections for one build, repeat --target. Run this only after installing the intended framework package in the project:

npx --no-install agent-bundle build --target claude --target codex

A combination is valid only when its actual components can coexist. Different bytes at the same path, or a component accidentally discovered by another host, are build errors, not permission to overwrite one projection with another. Reordering the target list does not resolve a conflict. See composition rules.

Project creation offers the same targets the compiler registers, amp included. It refuses only the combination the compiler would: the MCP starter's compiler-owned local server is rejected under Amp's skill-scoped MCP contract (amp.mcp.generated-local), so an Amp project starts from another template. See the current installation guide for the nested install root and reload procedure.

#The authoritative capability matrices

The following pages are generated from the same pinned capability records used by the adapters. They include the source documents, observed versions, detailed restrictions, and reasons for omissions. Do not maintain a second checklist of native support in a plugin repository.

A capability judgment is scoped to a feature and its recorded evidence:

Runtime verification is a separate axis. A record may describe an implemented adapter while account-dependent activation remains unverified. Amp is the current example: experimental, contract-verified, runtime-unverified. Absence of an account is not evidence that that host cannot perform the operation. Conversely, successful file placement is not proof that the host enabled the plugin or invoked a tool.

#What the framework can build

This is an authoring map, not a promise that every target accepts every component. The host matrices and the actual build's inspection decide availability.

Advanced custom/command/remote MCP servers, native metadata, native hook documents, prebuilt payloads, and bundler overrides remain supported where documented. They are escape hatches for real integration needs, not setup required for a normal tool.

#Compatible clients are not additional targets

The host matrix's Recorded third-party clients section describes readers of an existing output format. Its client names are not additional values for targets. A research issue for a host is also not an installed adapter.

Read each client's tier and surface rows together. A skills-only reader may not read plugin.json. A reader of mcp.json may not expand the path tokens needed to start its server. An installation command may register a directory rather than copy it. A higher-priority manifest may redirect component paths; a per-file MCP override need not shadow unrelated Skills. Conditional components are absent from a plugin that never authored them.

Use the dated source links in the generated client records for those details. A generic statement that a client supports plugins is not enough to claim compatibility with this exact artifact. Hosts without a current implemented/recorded path are not advertised here as supported targets.

#Build, development, and display are separate

Third-party adapters registered through the advanced TargetRegistry build alone under the current composite contract. They do not automatically inherit the built-in targets' discovery isolation guarantees.

#Check your own plugin

Run separate inspection focuses; do not combine them into one invocation:

npx --no-install agent-bundle inspect --json
npx --no-install agent-bundle inspect --routes --json
npx --no-install agent-bundle inspect --hooks --json
npx --no-install agent-bundle inspect --state --json
npx --no-install agent-bundle validate

After building, inspect and validate the deliverable without rediscovering source:

npx --no-install agent-bundle inspect --artifact artifact --json
npx --no-install agent-bundle validate --artifact artifact

For event routes, use supported config.requires capability declarations when the requirement is semantic, or explicit host selection when the behavior is intentionally native-specific. Do not claim support by dropping a blocking decision, fabricating context, or broadening approval. See the event guide for mutually exclusive declarations and unavailable-capability diagnostics.

Keep the generated INSTALL.md with the deliverable and follow its actual host/root/scope instructions. A successful compile, a packed-process test, a native install, and an authenticated agent turn establish different things; document which ones were actually exercised.