Custom Tooling Extension

Corrección de hechos (oficial). [DOC]

1. Commands fusionados en skills. .claude/commands/deploy.md y .claude/skills/deploy/SKILL.md crean ambos /deploy y funcionan igual. La decisión ya no es "command vs skill" sino qué controles de invocación fijar (disable-model-invocation, context: fork). [DOC]
2. allowed-tools NO restringe. Pre-aprueba las tools listadas mientras la skill está activa; todas las demás tools siguen disponibles (governadas por tus permisos). Para quitar o limitar tools usa disallowed-tools o reglas permissions.deny. La whitelist no reduce el blast radius por sí sola. [DOC]

Capacidad

Enrutar y componer extensiones de Claude Code de producción entre slash commands (.claude/commands/X.md) y skills (.claude/skills/X/SKILL.md), eligiendo los controles de invocación y scope sin duplicar sus autores especializados. La capacidad es decidir el trigger (explícito vs contextual), economizar contexto con context: fork, y limitar operaciones destructivas con disallowed-tools/permissions.deny (no con allowed-tools), sin contaminar la sesión ni romper la replicabilidad del equipo. [DOC]

La implementación del command pertenece a claude-command-authoring; la implementación de la skill a claude-skill-authoring; la política de permisos a tool-permission-policy. Este router se activa cuando hay que decidir o migrar entre esas superficies, no para autoría aislada. [CONFIG]

Ownership: 0/35 páginas del audit Claude Platform. Este skill no define tools de Messages API, no procesa tool_use, no implementa server tools y no crea handlers de memory/bash/editor/computer. Esas superficies pertenecen a tool-use-design, claude-api-tool-runtime, claude-api-server-tools y claude-api-client-tools. [CONFIG]

Cuándo usarla

• Necesitas un disparo explícito por nombre (/comando arg): autoría de command. [DOC]
• Necesitas activación por contexto con ventana aislada: skill con context: fork. [DOC]
• El artefacto debe replicarse al equipo vía repo: scope project (.claude/), nunca user. [DOC]
• Una skill ejecuta operaciones que pueden mutar repo/sistema y necesitas limitar el blast radius: usa disallowed-tools o permissions.deny (no allowed-tools). [DOC]
• Quieres mover convenciones permanentes (no condicionales) a CLAUDE.md. [DOC]

No activarla para definiciones input_schema/strict/tool_choice, bucles Messages API, server tools o herramientas cliente de Claude Platform. [CONFIG]

Cómo construir

1. Clasifica el trigger. ¿Disparo explícito por el usuario? → command file. ¿Activación por contexto + economía de ventana? → skill con context: fork. (Ambos producen un /nombre equivalente.) Para comportamiento solo-explícito (que el modelo no la auto-invoque por contexto), fija disable-model-invocation: true: queda invocable por /nombre pero no entra en routing automático. [DOC]
2. Fija el scope. Project (.claude/, versionado) si debe llegar al equipo; user (~/.claude/) solo para experimentos personales que no entran a ningún repo. [DOC]
3. Declara la interfaz. argument-hint para el invocante; description como contrato de routing. [DOC]
4. Aísla el contexto. context: fork en trabajo no trivial para no inflar la sesión. [DOC]
5. Permisos de tools. allowed-tools pre-aprueba (evita prompts) las tools que la skill usa de rutina. Para impedir mutaciones declara disallowed-tools (p.ej. Write, Edit, Bash) o reglas permissions.deny; allowed-tools por sí solo NO cierra esas tools. Recuerda: un project skill requiere aceptar el diálogo de confianza del workspace antes de que allowed-tools aplique. [DOC]
6. Separa convención de capacidad. Reglas permanentes → CLAUDE.md. [DOC]
7. Valida con evals antes de mergear. [CONFIG]

Patrón correcto

# .claude/skills/release-notes/SKILL.md  (project scope, versionado)
---
name: release-notes
description: "Genera notas de versión desde git log entre dos tags; se activa al pedir changelog/release notes."
context: fork                 # aísla y economiza la ventana principal
argument-hint: "<tag-desde> <tag-hasta>"
# pre-aprueba lectura + git (evita prompts):
allowed-tools: Read, Grep, Bash
# cierra mutaciones explícitamente (allowed-tools NO restringe):
disallowed-tools: Write, Edit
---

Anti-patrón

# ANTI: user scope -> no se replica al equipo
# ~/.claude/skills/release-notes/SKILL.md
---
name: release-notes
# ANTI: sin context: fork -> la sub-tarea infla la sesión principal
# ANTI: creer que omitir allowed-tools "abre" y declararlo "cierra" el blast radius.
#        Para cerrar, usa disallowed-tools o permissions.deny.
description: "hace cosas con git"   # ANTI: description vaga, no es contrato de routing
---

Checklist de validación

• ¿Elegiste el trigger (explícito vs contextual) y el scope (project vs user)? [DOC]
• ¿Scope project si debe replicarse al equipo? (user no replica) [DOC]
• ¿context: fork para economía de contexto en trabajo no trivial? [DOC]
• ¿Las mutaciones se limitan con disallowed-tools/permissions.deny, entendiendo que allowed-tools solo pre-aprueba? [DOC]
• ¿description/argument-hint como contrato de activación e interfaz? [DOC]
• ¿Convenciones permanentes en CLAUDE.md y NO dentro de la skill? [DOC]

Katas y skills relacionadas

• Kata: katas-custom-commands-skills (ver corrección de allowed-tools ahí también).
• Relacionadas: claude-command-authoring, claude-skill-authoring, tool-permission-policy, tool-use-design.

Contract

• Aceptación: la extensión se entrega como skill/command/hook correcto con tools restringidas explícitas. [EXPLICIT]
• Límites: decide extensiones de Claude Code y sus permisos; no posee ninguna página ni tool de Claude Platform. [EXPLICIT]
• Casos borde: command vs skill mal elegido → fricción de invocación; allowed-tools no restringe (usa disallowed-tools). [EXPLICIT]
• Supuestos: commands fusionados en skills en el runtime actual [DOC]. [SUPUESTO]
• Trade-off: más superficie de extensión = más mantenimiento; preferir el artefacto más liviano que cumpla. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · scripts/ automatización local · assets/ recursos estáticos.