Slash commands y permisos

Las /comandos de Claude Code son atajos a operaciones de la sesión: cambiar de modelo, limpiar contexto, lanzar revisiones, ejecutar Skills. Y los permisos son la frontera entre lo que el agente puede hacer solo y lo que necesita tu OK. Dominar ambos es lo que separa una herramienta cómoda de una herramienta segura.

Objetivos

• Conocer los slash commands incorporados y cuándo se usa cada uno.
• Crear un slash command propio para tu equipo.
• Entender la jerarquía de permisos (allow / deny / ask).
• Configurar settings.json para que el equipo tenga el mismo comportamiento.
• Diferenciar permission modes: bypass, default, restricted.

4.1 Slash commands incorporados

Estos comandos vienen con Claude Code y están disponibles en cualquier sesión:

4.2 Crear tu propio slash command

Puedes definir comandos específicos de tu equipo o tu proyecto. Se guardan como ficheros Markdown en:

• ~/.claude/commands/ — global (disponible en todas las sesiones).
• .claude/commands/ — del proyecto (versionado, viaja con el repo).

Cada fichero .md es un comando. El nombre del fichero, sin extensión, es el comando.

Ejemplo: /security-review

Crea .claude/commands/security-review.md:

---
description: Revisión de seguridad de los cambios pendientes
allowed-tools: Read, Glob, Grep, Bash(git diff:*), Bash(git log:*)
---

Eres un auditor de seguridad. Revisa los cambios pendientes en este repo
(diff contra origin/main) buscando:

1. Inyección SQL, command injection, XSS.
2. Secretos hardcodeados (API keys, contraseñas, tokens).
3. Validación insuficiente de input de usuario.
4. Uso de funciones criptográficas inseguras (md5, sha1, eval).
5. Logging de datos personales (PII).

Devuelve un informe estructurado con:
- Severidad (crítica / alta / media / baja).
- Fichero y línea.
- Por qué es un problema.
- Cómo arreglarlo (con código).

NO modifiques archivos. Solo lee y reporta.

A partir de ese momento, en cualquier sesión del proyecto puedes hacer:

> /security-review

Variables de entorno en commands

Los slash commands aceptan argumentos que rellenas con $ARGUMENTS:

---
description: Genera tests para el archivo dado
---

Lee el archivo $ARGUMENTS y escribe tests unitarios con vitest
hasta cubrir el 90% de las ramas.

Uso:

> /tests src/services/billing.ts

4.3 Modelo de permisos

Cuando Claude Code va a ejecutar una herramienta con efectos secundarios (Bash, Edit, Write, MCP write), el sistema decide entre tres caminos:

Las reglas se evalúan en este orden:

1. Reglas deny de cualquier nivel (siempre ganan).
2. Reglas allow de cualquier nivel.
3. Por defecto, ask.

Ejemplo: settings.json del proyecto

{
  "permissions": {
    "allow": [
      "Bash(npm:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push:*)",
      "Bash(git reset --hard:*)",
      "Bash(npm publish:*)",
      "Bash(curl * | bash)"
    ]
  }
}

La sintaxis Bash(npm:*) usa glob: matchea cualquier comando que empiece por npm. Bash(git status) es exacto, solo ese comando.

Permisos en MCP servers

Los servidores MCP (Módulo 7) exponen sus propias herramientas con prefijo mcp__<servidor>__<tool>. Puedes listarlas igual:

{
  "permissions": {
    "allow": [
      "mcp__chrome__navigate",
      "mcp__chrome__screenshot"
    ],
    "deny": [
      "mcp__github__delete_repository"
    ]
  }
}

4.4 Permission modes: bypass, default, restricted

Además de las reglas, hay tres "modos" globales que cambian el comportamiento general:

Activación en línea de comandos:

claude --permission-mode restricted

O en settings.json:

{ "permissionMode": "restricted" }

4.5 Repartir settings entre equipo y persona

Recomendación de organización en un repo de empresa:

.claude/settings.json (versionado)

Lo que TODO el equipo debe tener: modelo por defecto, allowlist de comandos seguros, denylist crítico.

{
  "model": "claude-sonnet-4-6",
  "permissions": {
    "allow": ["Bash(npm:*)","Bash(git status)","Bash(git diff:*)","Read","Glob","Grep","Edit","Write"],
    "deny": ["Bash(rm -rf:*)","Bash(git push:*)","Bash(git reset --hard:*)"]
  }
}

.claude/settings.local.json (en .gitignore)

Lo que cada persona personaliza: variables de entorno locales, hooks personales, modelo distinto si tiene plan superior.

{
  "model": "claude-opus-4-7",
  "env": {
    "DATABASE_URL": "postgres://localhost/myapp_dev"
  }
}

~/.claude/settings.json (global del usuario)

Comportamiento por defecto al entrar en cualquier proyecto: tu shell preferido, tu MCP de Chrome, tu API key de WeatherKit, etc.

4.6 Reduce los prompts de permiso (skill fewer-permission-prompts)

Si te cansa que el agente pregunte cada vez por npm test, git status, etc., usa la skill oficial:

> /fewer-permission-prompts

La skill escanea tu transcript reciente, identifica los comandos que ya has aprobado varias veces, y te propone añadir un allowlist al .claude/settings.json. Tú apruebas y lo guarda.

Ejemplo de salida:

He encontrado 12 comandos que aprobaste manualmente más de 3 veces:

  Bash(npm test)            → 8 veces
  Bash(npm run build)       → 6 veces
  Bash(git diff)            → 14 veces
  Bash(git log:*)           → 5 veces
  ...

¿Añadir todo a .claude/settings.json allow? (sí / no / selecciona)

Práctica

Test de comprensión

Resumen

• Slash commands integrados (/help, /clear, /init, /plan, /review, /cost) cubren el día a día.
• Custom commands en .claude/commands/*.md con frontmatter para permisos.
• Permisos en tres caminos: allow / deny / ask. Deny siempre gana.
• Permission modes: default, bypass, restricted. Bypass solo en sandbox.
• Reparto settings: equipo en settings.json, persona en settings.local.json.

El siguiente módulo entra en Skills: cómo encapsular conocimiento de dominio en paquetes que Claude Code puede invocar automáticamente.