Feature Reference

The feature reference routes authors to exact Skillset contracts, workflow references, support vocabulary, and maintainer evidence.

The feature reference explains how authored source maps to provider targets, which features are portable, which are provider-native, and which boundaries are not implemented. Feature prose remains human-owned; each delimited support matrix is rendered from the typed registry and checked for drift.

Start with the page matching the source or workflow you are using. To compare support across every provider, open the generated feature support matrix.

Use these pages alongside the authored provider reference. Provider pages explain target-level judgment; feature pages own exact authoring shape, defaults, output, errors, examples, and caveats.

Feature and Workflow Pages

Activation Probes: target-aware manual harness prompts generated inside skillset test runs.
Agents: portable project agents, Claude and Cursor plugin agents, Codex project agents, and skill-local policy boundaries.
Apps: Codex plugin .app.json pass-through and why there is no apps.source feature key.
Build Scopes: build mode, destination scopes, preview safety, diff/list/explain behavior, and lock semantics.
Changes: pending change entries, source coverage, compact refs, groups, and append-only history boundaries.
CI: the skillset check --ci aggregate check, mechanical drift rebuilds, PR-comment reports, and the --include ci workflow scaffold.
Commands: Claude and Cursor plugin command pass-through, provider-native wiring, and Codex unsupported boundaries.
Dependencies: plugin dependency declarations, Claude rendering, Codex fallback notices, and provenance.
Dev Watch: default-preview skillset dev for first-author source diagnostics, generated-output drift, and explicit write mode.
Distributions: post-build distribution planning, destination reports, and build/distribution/activation boundaries.
Executables: Claude plugin bin/ conventional discovery, bin.source, and Codex and Cursor unsupported diagnostics.
Feature Source Pointers: direct feature-key source pointers, conventional discovery, and future component ownership.
Hooks: native aggregate hook emission, adaptive hook units, target validation, and activation boundaries.
Interactive CLI: when prompts appear, how they inherit command safety, and how automation avoids them.
LSP Servers: Claude plugin .lsp.json pass-through, manifest wiring, and future validation boundaries.
Marketplaces: curated provider catalogs, external plugin references, readiness states, and check/update boundaries.
MCP Servers: plugin .mcp.json, mcp.source, manifest wiring, and structured validation.
Monitors: Claude experimental monitor pass-through, manifest wiring, and Codex unsupported boundaries.
Operational Reports: globally retained immutable receipts, UUID/path retrieval, bundle validation, and producer-migration boundaries.
Output Safety: managed output ownership, unmanaged neighbor handling, reversible backups, and restore.
Output Styles: Claude output style directory pass-through and manifest wiring.
Plugins: plugin source identity, manifest rendering, companion paths, and plugin boundaries.
Reconcile Generated Edits: skillset reconcile for a managed generated file that was edited, choosing source or output authority with a preview, and refusing unsafe reverse mappings; CI source writeback remains future work.
Releases And Changelogs: release state, generated changelog renderings, version planning, and package-tool interop.
Resources: shared resource declarations, link rewriting, executable-script linting, and lock hashing.
Rules: source-root rules/ rendering to Claude rules, Codex AGENTS.md, and Cursor .mdc rules, with preprocessing and collision safety.
Runtime Activation Readiness: registry-backed activation requirements, deterministic summary semantics, and the boundary between rendering, observation, and proof.
Settings: the one project-local SessionStart entry Skillset composes, and why build never touches user-level provider settings.
Skills: standalone and plugin-bound skill frontmatter, target rendering, versions, metadata, and generated sidecars.
Supports: compatibility metadata, support ranges, source significance, and release severity boundaries.
Provider Source: explicit provider-native source islands, Codex .rules pass-through, and leakage rules.
Tests and Evals: deterministic skillset test, runtime probes, skill evals, and generated run-output boundaries.
Themes: Claude experimental theme pass-through, manifest wiring, and Codex unsupported boundaries.
Tools Policy: portable tool policy, Claude tool-rule rendering, provider metadata, and target-native provider blocks.
Version Audit: read-only version-locus audit across source, release state, generated output, and future destinations.

Maintainer References

Feature Registry owns typed feature IDs, support claims, documentation links, and evidence requirements.
Hook Guardrails documents repository and agent-runtime check integration.
Render Results defines the per-build result vocabulary used by adapters and reports.
Runtime Adapters records runtime, distribution, and harness evidence separately from compiler targets.
Workbench Check defines parser, schema, diagnostic, fixture, and optional static-analysis internals.

Support Vocabulary

The feature reference uses related but separate vocabularies. Feature entry status describes whether Skillset owns a feature at all. Target support status describes whether a target can represent that feature. Runtime support uses the same status values as target support for runtime, distribution, and harness records. Render results use a separate build-result vocabulary for what happened to a specific source unit in a specific build.

Feature Entry Status

Status	Meaning
`implemented`	Parsed, validated, rendered or reported, tested, and documented in the current compiler.
`planned`	Accepted design with no parser/render support yet.
`reserved`	Recognized vocabulary that fails until behavior and provenance exist.
`deferred`	Intentionally not rendered or implemented yet; documented reason.
`future`	Outside the implemented contract but tracked as a possible later design.
`unsupported`	Known not to be supported as a Skillset source feature.

Target Support Status

Status	Meaning
`native`	The target has a native documented surface for the feature.
`pass_through`	Skillset can safely copy or preserve target-native source for that target.
`transformed`	Skillset can render the source intent into a different target-native shape.
`metadata_only`	Skillset can preserve the information in metadata, sidecars, locks, or reports, but the target does not enforce it directly.
`degraded`	Skillset can render a useful fallback that is weaker than native target support and must carry a reason.
`externally_managed`	The behavior belongs to install, activation, distribution, marketplace state, or another external system.
`shimmed`	Runtime behavior can work through deliberate compatibility instructions or harness material, but is not target-enforced.
`not_applicable`	The feature is a Skillset workflow or source-management surface rather than a target runtime feature.
`planned`	Target support is accepted but not implemented.
`future`	Target support is possible later but outside the implemented contract.
`unsupported`	The target cannot represent the feature faithfully through a portable render and must carry a reason.
`lossy`	A possible target render would drop required meaning or behavior and must carry a reason.

Unsupported and lossy render fails loudly by default. The implemented warn, skip, and force policies soften only those results while preserving visible diagnostics and lock or status provenance; failed render results still block.

Render-Result Status

Render-result statuses are build-result facts, not registry capability statuses. A target support row that says native usually produces a rendered render result when a source unit is built; a row that says pass_through usually produces target_native; and a row that says unsupported may produce unsupported, intentionally_skipped, or no render result when the source unit is outside the current build scope. See Render Results for the full render-result table.

Registry Linkage

The typed registry lives in packages/core/src/feature-registry.ts. Generated blocks are the canonical feature-ID and support surface; one page may explain several related registry entries. Cross-command references such as Interactive CLI, Runtime Activation Readiness, and Reconcile Generated Edits are reader references without invented registry IDs.

The registry owns feature status, target support, documentation links, render owners, validation owners, and evidence references. The authored page explains how to use and interpret those facts without reproducing the exhaustive inventory.

Future-Only Features

These are tracked as future/reserved unless a later issue promotes them:

Reviewed settings suggestion workflow: Skillset may eventually propose or review target settings changes, but skillset build must not mutate user-level Claude, Codex, or Cursor config.
Model and reasoning alias profiles: shared aliases such as review, fast, or deep remain deferred; use target-native model and effort fields where supported.
First-class sets: grouped marketplaces, bundles, and curated collections remain future vocabulary; the implemented contract keeps build scopes and entity selectors separate.