Channels Integration

Design, configure, or audit Claude Code channel integrations. Keep the skill focused on external events pushed into a currently running Claude Code session through MCP channel servers. [DOC]

Treat current Claude Code documentation, local claude --version, authentication mode, provider, organization settings, and plugin marketplace state as required evidence for execution advice. If any of these are unavailable, report coverage_gap instead of assuming support. [DOC][INFERENCIA]

Supporting resources:

• references/channel-contract.md - MCP channel server contract, plugin declaration, startup flags, event delivery, replies, and permission relay. [DOC]
• references/decision-matrix.md - When to use channels versus scheduled tasks, /loop, hooks, /goal, headless, routines, Remote Control, Slack, standard MCP, or agent view. [DOC][INFERENCIA]
• references/security-boundaries.md - Sender allowlists, prompt-injection boundary, permission relay authority, provider/admin gates, secrets, and local process risk. [DOC][INFERENCIA]
• assets/channel-readiness-checklist.md - Portable implementation and audit checklist. [CONFIG]
• assets/channel-decision-matrix.json - Machine-readable routing matrix for examples and reviews. [CONFIG]

Inputs Expected

• User intent: choose an integration surface, install an approved channel, build a custom channel, audit a channel design, troubleshoot delivery, or plan stateful background operation.
• Target event source: chat platform, CI, monitoring, deployment, issue tracker, internal webhook, local script, or notification system.
• Runtime evidence when execution is requested: Claude Code version, provider/authentication path, organization plan, managed settings, plugin marketplace, channel plugin name, --channels command, local MCP config, and sender allowlist state.
• Risk posture: read-only alerting, two-way chat replies, permission relay, file edits, production deploys, secrets, unattended background work, or managed enterprise environment.

Outputs Expected

• A channel design, setup plan, audit report, troubleshooting path, or integration-surface decision.
• Explicit feature gates: research preview, minimum Claude Code version, provider/authentication eligibility, and Team/Enterprise enablement.
• A delivery model: one-way event ingestion, two-way reply tool, permission relay, or stateful background/persistent session.
• A security boundary: sender allowlist, plugin allowlist, secret storage, permission mode, ask/deny rules, and untrusted input handling.
• A clear alternative recommendation when channels are not the right surface.

Procedure

Step 1 - Classify The Integration

Identify whether the external system should push an event into an open session, be queried on demand, run on a timer, run as a cloud routine, execute one scripted prompt, or steer a local session remotely. Use channels only when pushed events must land inside a session that is already running with local context. [DOC]

Step 2 - Verify Gates

Check or request claude --version, authentication mode, provider, organization settings, and plugin state. Channels are research preview. They require Claude Code v2.1.80 or later, Anthropic authentication through claude.ai or a Console API key, and explicit Team/Enterprise enablement. Do not recommend channels on Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. [DOC]

For custom or unapproved channels, check whether the user is testing locally with --dangerously-load-development-channels, or whether an organization allowlist names the plugin and marketplace. Treat preview syntax and protocol fields as version-sensitive. [DOC]

Step 3 - Map The Channel Contract

For a channel server, confirm these contract points before implementation:

• MCP server runs locally as a subprocess over stdio. [DOC]
• Server declares capabilities.experimental["claude/channel"]. [DOC]
• Server emits notifications/claude/channel for inbound events. [DOC]
• Plugin manifest declares channels[] and points each channel to a provided mcpServers key. [SUPUESTO] (el patrón aparece en un ejemplo de docs; la "vinculación" como requisito es inferida, no enunciada).
• Two-way channels expose a reply tool through standard MCP tool capabilities. [DOC]
• Permission relay declares capabilities.experimental["claude/channel/permission"] and handles request IDs as one-time approvals or denials. [DOC]

Step 4 - Design State And Session Behavior

State that events only arrive while the Claude Code session is open. For always-on use, plan a persistent terminal, claude --bg, agent view, tmux, launchd, or another supervised local process. Do not imply durable queueing, missed-event catch-up, or cloud execution unless the design uses routines, CI, Slack, or web sessions instead. [DOC][INFERENCIA]

Step 5 - Protect Boundaries

Apply assets/channel-readiness-checklist.md. Require a sender allowlist, narrow plugin allowlist, explicit trust boundary for permission relay, deny/ask permission rules for sensitive tools, and secret handling outside committed files. Treat inbound channel text as untrusted context until sender and source are verified. [DOC][INFERENCIA]

Step 6 - Choose Alternatives Deliberately

Use references/decision-matrix.md when the request asks "what should I use?" Prefer scheduled tasks or /loop for polling, hooks for deterministic lifecycle reactions, /goal for repeated turns until a condition is met, headless claude -p --bare for scripts and CI, routines for durable cloud automation, standard MCP for on-demand tool access, Remote Control for steering a running session, Slack for team mentions that spawn cloud sessions, and agent view for human-supervised background sessions. [DOC]

Step 7 - Validate

Return validation status with evidence. Include coverage_gap for unverified version, provider, authentication mode, managed settings, plugin marketplace, sender allowlist, local process supervision, permission relay behavior, or docs that could have changed since the last source check.

Quality Criteria

• Identifies whether the need is pushed event ingestion, polling, lifecycle automation, durable cloud automation, remote control, or non-interactive execution.
• States research-preview and provider/version gates before recommending channels.
• Names the exact startup surface: --channels plugin:<name>@<marketplace> or --dangerously-load-development-channels for local testing.
• Explains that .mcp.json alone is insufficient; the server must be opted in with --channels.
• Distinguishes one-way channel events, two-way reply tools, and permission relay.
• Treats channel text and remote permission replies as gated authority, not trusted by default.
• Describes statefulness: open local session required, no durable catch-up by default.
• Names a safer alternative when channels are the wrong surface.

Limits

• Do not claim channel availability without current version, auth/provider, and organization evidence.
• Do not treat research-preview behavior as stable across Claude Code releases.
• Do not use channels to bypass permissions, hooks, managed settings, or sender allowlists.
• Do not store tokens, chat IDs, owner IDs, webhook secrets, or API keys in committed files.

Contract

• Aceptación: push de evento externo descrito con su trigger y payload. [EXPLICIT]
• Límites: experimental; channels[] como manifest-array sin confirmar en docs [SUPUESTO]. [EXPLICIT]
• Casos borde: no confiar en entrega; tratar como best-effort. [EXPLICIT]
• Supuestos: RemoteTrigger/PushNotification presentes [CÓDIGO][DOC]. [SUPUESTO]
• Trade-off: integración externa vs MCP tool — push asincrónico a cambio de menos garantías. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · assets/ recursos estáticos.