Comandos de Claude Code: del uso diario al trabajo en equipo

Un comando útil para el equipo define los datos de entrada, las evidencias que hay que revisar y el formato de la respuesta. Piensa en él como una orden de trabajo guardada junto al código. Al escribir su nombre, aplicas esa orden a la tarea que tienes entre manos.

Empieza con /plan, /diff, /context y /compact. Después añade /team-pr-check a partir de las plantillas que encontrarás más abajo. La revisión de código es un buen primer caso de uso: en cada cambio vuelven a surgir las mismas preguntas sobre permisos, datos y pruebas.

Comandos de Claude Code que conviene conocer

Escríbelos al principio de un mensaje dentro de Claude Code. Los corchetes indican argumentos opcionales; los signos de menor y mayor que, argumentos obligatorios. Esta selección conserva la sintaxis de la referencia de comandos actual de Anthropic, consultada el 13 de octubre de 2026. La disponibilidad depende de la plataforma, el plan y el entorno.

Usa /compact cuando vayas a continuar con la misma tarea y /clear cuando cambies de tarea. Si sigues desarrollando una funcionalidad, una instrucción útil es /compact keep the acceptance criteria, unresolved risks, and exact test commands.

/release-notes abre el registro de cambios de Claude Code. No redacta las notas de versión de tu aplicación. Por eso el comando personalizado que aparece más abajo tiene otro nombre.

Para integrar estos controles en tu forma de trabajar, consulta las buenas prácticas de Claude Code.

Las skills incluidas también aparecen en el menú de comandos

Algunas opciones del menú de comandos con barra dan a Claude un procedimiento que debe seguir. Son skills incluidas en la herramienta, distintas de los controles fijos de la CLI:

• /code-review revisa un diff u otro objetivo compatible. /review es su alias. Al añadir --fix, solicitas modificaciones; con --comment, solicitas que publique comentarios de revisión.
• /simplify revisa el código modificado para simplificarlo y aplica correcciones.
• /verify compila y ejecuta la aplicación para comprobar su comportamiento.
• /doctor diagnostica problemas de configuración y propone soluciones.

Si quieres ver los hallazgos antes de que se hagan cambios, elige una revisión sin opciones adicionales. La sintaxis completa de estos comandos, sus requisitos y su disponibilidad figuran en las entradas de skills incluidas de la referencia de comandos.

Los comandos personalizados ahora son skills

Para crear un procedimiento nuevo, guarda un archivo de instrucciones en Markdown en .claude/skills/<name>/SKILL.md, dentro del repositorio. Inclúyelo en un commit para que el resto del equipo reciba el mismo procedimiento. Guarda los procedimientos personales en ~/.claude/skills/<name>/SKILL.md.

El formato anterior, .claude/commands/<name>.md, sigue funcionando. Ambos crean comandos /<name>. Un directorio de skill también puede contener plantillas, documentos de referencia y scripts. Es el formato más conveniente a medida que crece el procedimiento. Guía de skills de Anthropic

De dónde salen los comandos de plugins y MCP

Los plugins agrupan capacidades para reutilizarlas. Sus carpetas skills/<name>/SKILL.md crean comandos con un espacio de nombres, como /plugin-name:skill-name. Los comandos del formato anterior de plugins se guardan en commands/. Estas carpetas van en la raíz del plugin, junto al directorio .claude-plugin/ que contiene el manifiesto, no dentro de él. Usa /plugin para gestionar plugins y /reload-plugins después de hacer cambios. Componentes de un plugin

Empieza con skills del proyecto mientras el proceso pertenezca a una sola base de código. Considera crear un plugin cuando necesites mantener y distribuir el mismo proceso entre varios repositorios. La guía de los mejores plugins de Claude Code reúne paquetes existentes que conviene evaluar antes de crear otro.

Los prompts de MCP proceden de servidores conectados. MCP, el Model Context Protocol, conecta Claude Code con herramientas y datos externos. Un servidor también puede ofrecer prompts reutilizables. El menú los muestra como /servername:promptname (MCP); también puedes invocarlos con /mcp__servername__promptname. Solo aparecen cuando el servidor conectado ofrece esos prompts. Que una integración proporcione herramientas no significa que incluya todos los prompts que puedas necesitar. Documentación de prompts de MCP

Los argumentos de los prompts de MCP se separan por espacios en blanco y siguen los parámetros declarados por el servidor. El resultado del prompt se incorpora a la conversación. No des por hecho que un prompt de servidor procesa los argumentos igual que una skill local.

Crea el archivo y pásale los datos de la tarea

El frontmatter es el pequeño bloque de configuración YAML que precede a las instrucciones en Markdown. Su delimitador de apertura, ---, debe ocupar la primera línea del archivo. Estos son los campos relevantes para las plantillas de esta guía:

allowed-tools concede permisos; no limita el uso exclusivamente a esas herramientas. Todos los campos del frontmatter son opcionales, aunque se recomienda incluir description. Los archivos de comandos del formato anterior admiten los mismos campos, salvo name y paths. Referencia del frontmatter

Argumentos: $ARGUMENTS inserta toda la cadena de entrada. $0 o $ARGUMENTS[0] representa el primer argumento; $1, el segundo. Los argumentos con nombre se asignan a las posiciones en orden. Si un valor posicional contiene varias palabras, escríbelo entre comillas. argument-hint documenta las entradas, pero el procedimiento debe comprobarlas igualmente. Sustitución de argumentos

Las plantillas omiten name, de modo que el nombre lo determina la carpeta. Su frontmatter también funciona en el formato anterior de archivos de comandos. Guarda los datos estables del repositorio en la memoria del equipo de CLAUDE.md y los pasos de cada tarea específica en su skill.

Cinco comandos personalizados listos para usar en equipo

Crea cada una de las carpetas indicadas a continuación y pega su bloque en SKILL.md. Ejecuta /reload-skills para que se detecten los archivos nuevos. Son plantillas originales que puedes adaptar; no son comandos incluidos por Anthropic ni se presentan como resultados de pruebas.

El orden prioriza las comprobaciones de ingeniería que se repiten y después la comunicación. Las plantillas se apoyan, siempre que es posible, en evidencias del repositorio local. No necesitan conectarse a un gestor de incidencias ni a un servicio de PR para producir un resultado útil.

Una lista de revisión de PR para cambios que afectan a datos de clientes

Un equipo pequeño de SaaS podría usar este comando antes de solicitar una revisión humana. Plantea las mismas preguntas sobre aislamiento entre clientes, autorización y cobertura de pruebas incluso cuando quien hizo el cambio tiene prisa. Su valor está en entregar un trabajo más consistente para la revisión, con cada hallazgo vinculado a una ubicación y a un escenario de fallo.

Guárdalo como .claude/skills/team-pr-check/SKILL.md. Invócalo con /team-pr-check main para revisar la rama actual desde su ancestro común de fusión con main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

Una lista de comprobación merece la pena cuando recoge los fallos que realmente puede sufrir tu producto. Sustituye los controles genéricos por los límites que importan en tu caso, como la titularidad de las cuentas, el estado de facturación o los permisos heredados a través de los equipos.

Corregir un error reproducible empezando por una prueba

Quien haya fundado un producto y se encargue de mantenerlo en producción podría usar este comando cuando un reporte de error incluya pasos concretos para reproducirlo. El comportamiento que falla y la prueba de regresión pasan a formar parte de la orden de trabajo: entregar un parche que parece correcto deja de ser suficiente.

Guárdalo como .claude/skills/team-test-first-fix/SKILL.md. Invócalo con /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

Este procedimiento sirve para defectos reproducibles. Si se trata de un incidente intermitente en producción y faltan evidencias, empieza por investigar; no fuerces al comando a inventar una prueba que falle.

Planificar una migración antes de modificar un sistema compartido

Un equipo que vaya a cambiar un esquema de base de datos o a sustituir una API podría usar este comando para detectar dudas sobre el orden de los pasos y la compatibilidad antes de implementar nada. El resultado útil es un plan que se pueda cuestionar, sobre todo en lo relativo a la convivencia de versiones antiguas y nuevas.

Guárdalo como .claude/skills/team-migration-plan/SKILL.md. Invócalo con /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

La instrucción de planificar no cambia el modo de permisos de Claude Code. Si también quieres poner la sesión en Plan Mode, introduce /plan antes de invocar esta skill. El procedimiento escrito y los permisos de las herramientas de la sesión son controles independientes. Plan Mode

Notas de versión para tu producto

Una persona encargada de publicar versiones podría usar este comando para convertir un rango definido de cambios en un borrador dirigido a los clientes. Reduce el trabajo de explicar qué implican los commits para los usuarios y exige evidencias para cada afirmación.

Guárdalo como .claude/skills/team-release-notes/SKILL.md. Invócalo con /team-release-notes previous-release HEAD, sustituyendo previous-release por una etiqueta o un commit existente.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

Un rango de código demuestra qué cambió en el repositorio. No demuestra qué clientes recibieron el cambio. Confirma el estado del despliegue antes de publicar el borrador.

Un registro semanal de cambios para el equipo

Una persona al frente del equipo de ingeniería podría usar este comando para preparar una actualización semanal destinada a producto y soporte. Separa el trabajo integrado en la rama de las versiones cuya publicación está verificada, para no anunciar por accidente algo que todavía depende de una bandera de funcionalidad.

Guárdalo como .claude/skills/team-weekly-changelog/SKILL.md. Invócalo con /team-weekly-changelog START_DATE END_DATE main, sustituyendo las fechas por marcas de tiempo ISO que incluyan la zona horaria. El intervalo incluye el inicio y excluye el final.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Mantén separados las notas de versión y los informes semanales. Una versión tiene unos límites de código definidos y se dirige a los clientes. Un informe semanal abarca un periodo y puede incluir trabajo útil que todavía no se ha publicado.

¿Cuándo merece la pena conservar un comando?

Mide el trabajo recurrente que rodea al modelo, no lo impresionante que parezca su primera respuesta.

El valor semanal se calcula así: ejecuciones × (tiempo anterior de preparación y corrección − tiempo nuevo de preparación y corrección) × costo por hora del equipo − gasto adicional en el modelo − tiempo de mantenimiento valorado a ese mismo costo por hora. Usa tus propias mediciones. Un prompt más largo que genere más trabajo de revisión puede hacerte perder dinero aunque dé la impresión de automatizar más.

La partida que más probablemente cambie es el tiempo que los desarrolladores sénior dedican a explicar el mismo proceso y a completar entregas que llegan a medias. El procedimiento también necesita mantenimiento cuando cambian la arquitectura o el proceso de publicación.

Un comando guardado también cuenta como uso del modelo cuando Claude lo ejecuta. /usage muestra estimaciones del costo de tokens e información sobre el uso del plan; una estimación del costo de API en pantalla no es una factura de suscripción. Documentación de costos de Anthropic

Dos oportunidades de producto alrededor de estos comandos

Las plantillas son herramientas internas útiles. Convertirlas en un producto exige una ventaja más difícil de replicar que guardar un prompt.

La oportunidad más sólida: revisiones adaptadas a cada repositorio

Un equipo pequeño de software podría pagar por un paquete de revisión que se mantenga actualizado y conozca sus áreas de mayor riesgo: qué tablas pertenecen a una cuenta, qué acciones afectan a la facturación y qué pruebas deben acompañar a cada cambio.

La consulta de palabras clave de DataForSEO para Google en Estados Unidos y en inglés arrojó 1,300 búsquedas mensuales estimadas de «ai code review» el 13 de octubre de 2026. Eso indica interés en la tarea, no demanda de un plugin concreto de Claude Code. Consulta de palabras clave de DataForSEO

La versión mínima que se podría vender combinaría una lista de comprobación del proyecto, notas de arquitectura de apoyo y un conjunto de errores anteriores para evaluarla. Antes de distribuirla como plugin, haz que produzca hallazgos respaldados por evidencias al revisar esos ejemplos.

El obstáculo es la competencia: Claude Code ya incluye funciones de revisión y CodeRabbit vende herramientas de revisión de código. Un prompt genérico de revisión aporta poca diferenciación. Yo solo elegiría esta oportunidad si tuviera acceso al historial de fallos de un equipo concreto y hubiera alguien responsable de mantener actualizadas las comprobaciones.

Una oportunidad menor: comunicar versiones con evidencias

Un equipo de producto podría usar un flujo de trabajo con mantenimiento continuo que convierta los cambios del repositorio en notas de versión para clientes y en un informe interno para soporte, con referencias a las fuentes y una comprobación explícita del estado del despliegue.

La misma consulta de palabras clave arrojó 70 búsquedas mensuales estimadas de «release notes generator». Es una señal de búsqueda modesta, así que empezaría con un servicio o un flujo de trabajo interno antes de desarrollar un software independiente. Consulta de palabras clave de DataForSEO

La versión mínima podría generar borradores a partir de un rango de Git elegido y con el formato habitual del equipo. Lo difícil es relacionar los cambios con las banderas de funcionalidad, los despliegues y la disponibilidad real para los clientes. El comando puede ordenar las evidencias; no puede fabricar las que el equipo no registra.

Los límites que importan en el código de un negocio

Un comando estandariza las instrucciones. Las pruebas, la revisión y los controles de publicación siguen determinando si el resultado es aceptable. Usa las cinco plantillas como procedimientos iniciales y revisa sus cambios junto con los del código de la aplicación.

El contenido completo de una skill se carga cuando se utiliza, así que mantén el procedimiento conciso y guarda las referencias detalladas en archivos de apoyo. Las skills personales pueden tener prioridad sobre las del proyecto con el mismo nombre; en sesiones locales de terminal, también pueden ocultar comandos integrados. Usa nombres distintivos y revisa el origen cuando otras personas del equipo obtengan un comportamiento diferente. Carga y prioridad de skills

Configura por separado las reglas reales de permisos de las herramientas. Una frase como «solo revisar» le indica a Claude lo que quieres; no impone una restricción del sistema operativo. Permisos de Claude Code

Por dónde empezar el lunes

Incluye /team-pr-check en el repositorio primero. Sustituye sus puntos genéricos por las comprobaciones que debería haber superado el último cambio problemático. Ejecútalo sobre un cambio ya terminado cuyo resultado conozcas, compara los hallazgos con el problema real y ajusta el procedimiento antes de convertirlo en una práctica habitual del equipo. Añade los comandos de notas de versión e informes semanales cuando sus formatos de salida estén acordados.

Si quieres conectar estos flujos de trabajo con los sistemas de tu negocio, desarrollo automatizaciones con IA a partir de las comprobaciones que tu equipo realmente necesita.