Claude Code: todo lo configurable que la documentación no te cuenta

(buildingbetter.tech)

1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp

Claude Code 2.1.87 tiene muchas configuraciones no documentadas, y es posible aplicar por separado Hooks, Skills y Agents mediante archivos .claude/ personales o por proyecto
Los Hooks no solo usan JSON por stdin y códigos de salida, sino también campos JSON por evento en stdout para modificar comandos, decidir permisos, inyectar contexto e incluso vigilar archivos
Con los campos de Hook no documentados once, async y asyncRewake, se pueden crear flujos de ejecución única, logs de auditoría en segundo plano y bloqueos de seguridad asíncronos
Skills y Agents controlan, mediante frontmatter oculto, el modelo, el esfuerzo, Hooks por alcance, delegación a Agent, memoria persistente, omisión de CLAUDE.md y dependencias de MCP
Auto Mode, memoria automática, Dream, Magic Docs, glob de permisos y context: fork hacen que Claude Code se configure más como un entorno de desarrollo que aprende

Versiones de referencia y ubicación de archivos

El contenido se basa en @anthropic-ai/claude-code@2.1.87, y las funciones no documentadas pueden cambiar entre versiones
Los campos cuyo nombre incluye EXPERIMENTAL fueron marcados por ingenieros de Anthropic como inestables, por lo que pueden eliminarse o cambiar de nombre
Ubicación de archivos de configuración
- Configuración personal: ~/.claude/settings.json
- Configuración del proyecto: .claude/settings.json
Ubicación de Skills
- Personal: ~/.claude/skills/<name>/SKILL.md
- Proyecto: .claude/skills/<name>/SKILL.md
Ubicación de Agents
- Personal: ~/.claude/agents/<name>.md
- Proyecto: .claude/agents/<name>.md
Como convención, conviene colocar los scripts de Hook en ~/.claude/hooks/, y para ejecutarlos se necesita chmod +x
Los archivos .claude/ a nivel de proyecto pueden confirmarse en Git y compartirse con el equipo, mientras que los archivos personales bajo ~/.claude/ solo se aplican al usuario

Los Hooks pueden cambiar el comportamiento de Claude Code con JSON en stdout

La documentación oficial solo cubre el flujo donde Hook recibe JSON por stdin y bloquea una acción con código de salida 2, pero en la práctica también puede cambiar en tiempo real el comportamiento de Claude Code usando campos JSON por evento en stdout
Campos que puede devolver PreToolUse
- updatedInput: permite reescribir la entrada antes de ejecutar la herramienta y así cambiar el comando
- permissionDecision: permite forzar allow o deny sin preguntarle al usuario
- permissionDecisionReason: permite mostrar en la UI la razón de la decisión
- additionalContext: permite inyectar texto en el contexto de la conversación
Campos que puede devolver SessionStart
- watchPaths: permite configurar vigilancia automática de archivos para disparar eventos FileChanged
- initialUserMessage: permite agregar contenido antes del primer mensaje del usuario en la sesión
- additionalContext: permite inyectar contexto que se mantiene durante toda la sesión
Campos que puede devolver PostToolUse
- updatedMCPToolOutput: permite modificar la respuesta de una herramienta MCP que ve Claude
- additionalContext: permite inyectar contexto después de ejecutar la herramienta
Campos que puede devolver PermissionRequest
- decision: permite aprobar o rechazar de forma programática junto con updatedInput o updatedPermissions
Hook que cambia automáticamente git push a --dry-run
- En un Hook PreToolUse, se puede inspeccionar el comando de Bash y, si incluye git push, agregar --dry-run al final mediante updatedInput
- Claude cree que va a ejecutar git push origin main, pero el Hook lo cambia a git push origin main --dry-run antes de la ejecución real

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/dry-run-pushes.sh"
      }]
    }]
  }
}

#!/bin/bash
INPUT=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$INPUT" | grep -q 'git push'; then
  jq -n --arg cmd "$INPUT --dry-run" '{"updatedInput": {"command": $cmd}}'
fi

Hook que inyecta vigilancia de archivos y contexto de Git al iniciar la sesión
- Un Hook SessionStart puede marcar package.json, .env y tsconfig.json como archivos a vigilar, e insertar como contexto de sesión la rama actual y la cantidad de archivos sin confirmar

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }]
  }
}

#!/bin/bash
BRANCH=$(git branch --show-current 2>/dev/null)
CHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')

jq -n \
  --arg branch "$BRANCH" \
  --arg changes "$CHANGES" \
  '{
    "watchPaths": ["package.json", ".env", "tsconfig.json"],
    "additionalContext": "Current branch: \($branch). Uncommitted changes: \($changes) files."
  }'

Hook que aprueba automáticamente comandos Bash de solo lectura
- Comandos como ls, cat, echo, pwd, whoami, date, git status, git log y git diff pueden pasar sin confirmación del usuario con permissionDecision: "allow"

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$CMD" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then
  echo '{"permissionDecision": "allow", "permissionDecisionReason": "Safe read-only command"}'
fi

3 campos de configuración de Hook que no aparecen en la documentación

Los campos de Hook documentados son type, command, matcher, timeout, if, statusMessage, pero el parser del código fuente también acepta once, async y asyncRewake
once: true
- Ejecuta el Hook exactamente una sola vez y luego lo elimina automáticamente, así que es ideal para la configuración inicial de la sesión
- Si no existe .env, se puede crear un flujo que copie .env.example a .env y que después ya no vuelva a ejecutarse

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "[ -f .env ] || cp .env.example .env && echo 'Created .env from template'",
        "once": true,
        "statusMessage": "First-time setup..."
      }]
    }]
  }
}

async: true
- Ejecuta el Hook en segundo plano para no bloquear el progreso de Claude
- Se puede usar para registrar todos los comandos de Bash en ~/.claude/audit.jsonl sin agregar latencia a la sesión

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl",
        "async": true
      }]
    }]
  }
}

asyncRewake: true
- En la ruta normal se ejecuta en segundo plano como async, pero si termina con exit code 2 vuelve a despertar al modelo y bloquea la tarea
- Puede revisar en cada archivo que escriba Claude patrones hardcodeados como password, secret y api_key, y bloquear si los detecta

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/scan-secrets.sh",
        "asyncRewake": true,
        "statusMessage": "Scanning for secrets..."
      }]
    }]
  }
}

#!/bin/bash
FILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)
if grep -qE '(password|secret|api_key)\s*=' "$FILE" 2>/dev/null; then
  exit 2
fi
exit 0

Campos ocultos del frontmatter de Skill

La documentación cubre name, description, allowed-tools, argument-hint, when_to_use y context, pero el parser real acepta 6 campos adicionales
model
- Permite cambiar el modelo de ejecución del Skill: para tareas rápidas y baratas se puede usar haiku, y para análisis complejos opus

---
name: quick-lint
description: Fast lint check using the cheapest model
model: haiku
effort: low
allowed-tools: Bash, Read
argument-hint: "[file]"
---
Run the project linter on: $ARGUMENTS
Detect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.

effort
- Ajusta qué tan profundamente piensa el modelo, y sus valores son low, medium, high y max
- Internamente se mapea al sistema de effort que controla la profundidad de razonamiento por respuesta
hooks
- Permite definir Hooks con alcance limitado que solo se registran cuando el Skill está activo y se eliminan al terminar
- Se puede usar, por ejemplo, para ejecutar una verificación de tipos de forma síncrona cada vez que se escriba un archivo TypeScript, y correr lint en segundo plano

---
name: strict-typescript
description: Write TypeScript with type checking on every save
allowed-tools: Bash, Read, Write, Edit, Grep, Glob
hooks:
  PostToolUse:
    - matcher: "Write|Edit"
      hooks:
        - type: command
          command: "~/.claude/hooks/typecheck-on-save.sh"
          statusMessage: "Type checking..."
        - type: command
          command: "~/.claude/hooks/lint-on-save.sh"
          async: true
---
Write TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.
$ARGUMENTS

agent
- Permite delegar la ejecución del Skill a un Agent personalizado

---
name: deep-review
description: Thorough security review delegated to the review agent
agent: security-review
---
Review the following: $ARGUMENTS

disable-model-invocation: true
- Impide la invocación automática y hace que solo se ejecute mediante una llamada explícita a /skill-name, por lo que es adecuado para Skills destructivos
shell: bash
- Especifica el shell que se usará para la ejecución

Campos ocultos del frontmatter de Agent

Los Agent personalizados de .claude/agents/ también admiten campos de frontmatter que no aparecen en la documentación
color
- Se puede configurar el color de la UI como uno de estos valores: red, orange, yellow, green, blue, purple, pink, gray
- Ayuda a distinguirlos visualmente cuando se ejecutan varios Agent
memory
- Le da al Agent una memoria persistente entre invocaciones
- user: se mantiene de forma global en todos los proyectos
- project: se mantiene por proyecto
- local: es una memoria privada por proyecto excluida de Git
- Un revisor de seguridad puede rastrear hallazgos previos, y un revisor de código puede recordar los patrones del usuario más allá de una sesión

---
name: codebase-guide
description: Answer questions about the codebase, learning more with each session
tools: [Read, Grep, Glob, Bash]
color: green
memory: project
---
You are a codebase guide with persistent memory. Check your memory first before exploring the code.

omitClaudeMd: true
- Omite la carga de la jerarquía de instrucciones de CLAUDE.md, por lo que resulta adecuado para un revisor de “fresh eyes” que evalúa según estándares de la industria en lugar de seguir las convenciones del proyecto

---
name: fresh-eyes
description: Review code without project-specific biases
tools: [Read, Grep, Glob]
omitClaudeMd: true
effort: high
color: blue
---
Review this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.

criticalSystemReminder_EXPERIMENTAL
- Reinyecta un mensaje corto como recordatorio del sistema en cada turno, y permanece en el contexto incluso después de la compresión de la conversación
- El propio nombre del campo incluye EXPERIMENTAL, así que es inestable; conviene usarlo solo para recordatorios auxiliares de seguridad, no para infraestructura crítica

---
name: prod-deployer
description: Manages production deployments with strict safety checks
tools: [Bash, Read, Grep]
color: red
criticalSystemReminder_EXPERIMENTAL: "Always run migrations with --dry-run first. Never skip the staging verification step."
---

requiredMcpServers
- Enumera patrones de nombres de servidores MCP requeridos, y si esos servidores no están presentes, el Agent no aparece
- Puede evitar que se carguen Agent cuyas dependencias aún no están listas

El clasificador de Auto Mode recibe descripciones del entorno en lenguaje natural

El campo autoMode de settings.json configura el clasificador de aprobación automática que internamente Anthropic llama “YOLO Classifier”
Los patrones allow se aprueban automáticamente, y los patrones soft_deny siempre requieren confirmación
El arreglo environment no es un patrón, sino contexto en lenguaje natural que el clasificador lee para reflejar la descripción del entorno del proyecto al evaluar la seguridad de comandos ambiguos

{
  "autoMode": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read",
      "Grep",
      "Glob"
    ],
    "soft_deny": [
      "Bash(git push *)",
      "Bash(rm *)",
      "Write(.env*)"
    ],
    "environment": [
      "NODE_ENV=development",
      "This is a local dev machine with no production database access",
      "All Docker containers use isolated networks",
      "The test suite is safe to run repeatedly, it uses a dedicated test database"
    ]
  }
}

Frases como This project uses Docker, all commands run in containers se usan para que el clasificador entienda el entorno
No production access hace que responda de forma menos conservadora ante tareas destructivas, y Test database is isolated funciona como una señal de que ejecutar pruebas siempre es seguro

Bucle de integración entre memoria automática y Dream

Si activas autoMemoryEnabled y autoDreamEnabled en settings.json, se habilita el sistema de auto-mejora de Claude Code

{
  "autoMemoryEnabled": true,
  "autoDreamEnabled": true
}

autoMemoryEnabled
- Después de cada conversación, un Agent en segundo plano extrae de la sesión la información que vale la pena conservar a largo plazo
- Registra preferencias del usuario, patrones del codebase y decisiones en ~/.claude/projects/<path>/memory/ con el formato estándar de frontmatter de memory
autoDreamEnabled
- Cada 24 horas, si hay 5 o más sesiones acumuladas, un Agent en segundo plano revisa transcripts de sesiones pasadas para consolidar la memoria
- Realiza fusión de duplicados, resolución de contradicciones, conversión de fechas relativas a fechas absolutas y eliminación de elementos obsoletos
- Si ambas configuraciones están activadas, se crea un bucle de aprendizaje en el que las sesiones generan memoria, Dream consolida esa memoria y la memoria consolidada se refleja en sesiones posteriores
- Después de algunas semanas, puede notarse el efecto de que Claude Code recuerde preferencias, convenciones y patrones comunes del usuario sin necesidad de reentrenar el modelo

Formato de Magic Docs

Magic Docs se detecta con la expresión regular /^#\s*MAGIC\s+DOC:\s*(.+)$/im
Debe ser obligatoriamente un título H1 y no distingue mayúsculas de minúsculas
En la línea siguiente se puede poner una instrucción en cursiva envuelta con _underscores_ o *asterisks*, que limita el alcance en el que debe enfocarse el Agent de actualización

# MAGIC DOC: API Endpoint Reference
_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._

## Endpoints

(content auto-maintained by Claude Code)

Si no hay instrucción, el Agent intentará actualizar todo el contenido
Si hay una instrucción, seguirá un alcance como only track public endpoints o focus on breaking changes
El Agent de actualización se ejecuta en segundo plano y está restringido a editar solo ese archivo
Si eliminas el encabezado, el seguimiento se detiene automáticamente

Sintaxis completa de reglas de permisos

La documentación muestra ejemplos básicos como Bash(git *), pero el lenguaje de patrones real abarca ampliamente Bash, rutas de archivos y herramientas MCP

Bash(npm *)              # wildcard after "npm "
Bash(git commit *)       # specific subcommand
Read(*.ts)               # file extension
Read(src/**/*.ts)        # recursive directory with extension
Write(src/**)            # recursive, all files
mcp__slack               # all tools on slack server
mcp__slack__*            # explicit wildcard (same effect)
mcp__slack__post_message # specific tool
Bash(npm:*)              # legacy colon prefix (word boundary)

* hace match dentro de un límite, como en un glob de shell, y ** hace match recursivo en directorios
Los permisos de herramientas MCP usan el formato de doble guion bajo mcp__<server>__<tool>
El campo if de Hook también usa la misma sintaxis, y es un glob, no una expresión regular

{
  "permissions": {
    "allow": [
      "Bash(npm *)", "Bash(git status)", "Bash(git diff *)",
      "Read(src/**)", "Read(tests/**)", "Grep", "Glob",
      "mcp__database__query"
    ],
    "deny": [
      "Bash(rm -rf *)", "Write(/etc/**)", "Write(.env*)",
      "mcp__slack__delete_*"
    ],
    "ask": [
      "Bash(git push *)", "Write(*.json)", "Write(*.lock)",
      "mcp__slack__post_message"
    ]
  }
}

Impacto del caché de `context: fork` y de la selección de modelo

Si configuras context: fork en un Skill, se ejecuta como un subagente bifurcado en segundo plano
El fork comparte el prompt cache del padre mediante un contrato tipado llamado CacheSafeParams, y genera un prefijo de request a la API byte a byte idéntico para aumentar la tasa de aciertos de caché
Si asignas otro modelo al Skill bifurcado, el prefijo cambia y el caché puede romperse
Si la conversación padre usa Opus y el fork usa Haiku, el prefijo cambia, se produce un cache miss y terminas pagando el costo completo
En un Forked Skill, debes omitir el campo model o usar model: inherit para conservar el caché
context: fork es adecuado para tareas pesadas como escaneo de seguridad, análisis de dependencias, generación de documentación o ejecución de suites de pruebas, mientras la conversación principal mantiene la capacidad de respuesta

---
name: full-audit
description: Comprehensive codebase audit running in the background
context: fork
allowed-tools: Bash, Read, Grep, Glob, WebSearch
effort: high
---
Run a comprehensive audit:
- Security scan (grep for dangerous patterns, check dependencies for CVEs)
- Code quality (duplicated logic, dead code, missing error handling)
- Test coverage (untested critical paths)
- Dependency health (outdated packages, unused deps, license issues)

Write a detailed report to /tmp/audit-report.md when complete.

Ejemplos de combinación de funciones

Revisor de código con memoria persistente y hook de alcance
- El agente lee la memoria por codebase, revisa juntos los patrones detectados antes y los problemas nuevos, y luego vuelve a guardar los hallazgos en la memoria
- Después de varias revisiones, ayuda a detectar problemas repetitivos específicos del proyecto que un revisor común podría pasar por alto

---
name: reviewer
description: Code reviewer that learns your codebase patterns over time
tools: [Read, Grep, Glob, Bash]
effort: high
color: yellow
memory: project
hooks:
  PostToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "~/.claude/hooks/log-review.sh"
          async: true
---
Before reviewing, read your memory for past findings on this codebase.

Review git diff HEAD~1 for:
- Patterns you've flagged before (check memory)
- New issues worth flagging
- Resolved issues from past reviews

After review, save to memory:
- New patterns found (type: feedback)
- Recurring issues (type: project)

End with VERDICT: PASS, FAIL, or NEEDS_REVIEW.

Configuración de sesión que combina monitoreo de archivos y la red de seguridad de asyncRewake
- Al iniciar la sesión carga el contexto del proyecto, aprueba automáticamente de inmediato los comandos Bash de solo lectura y bloquea los comandos peligrosos con una verificación de seguridad asíncrona
- Los comandos de solo lectura pasan rápido, los comandos peligrosos se bloquean y el resto sigue el flujo normal de permisos

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/session-context.sh",
        "statusMessage": "Loading project context..."
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-approve-readonly.sh"
      }, {
        "type": "command",
        "command": "~/.claude/hooks/block-dangerous.sh",
        "asyncRewake": true,
        "statusMessage": "Safety check..."
      }]
    }]
  }
}

#!/bin/bash
CMD=$(jq -r '.tool_input.command' < /dev/stdin)
echo "$CMD" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0

Revisión de arquitectura que combina override de modelo, control de effort y delegación a Agent
- Especifica un análisis profundo con effort: max, delega a un Agent específico y reduce la influencia de las prácticas existentes del proyecto con omitClaudeMd: true en ese Agent

---
name: architecture-review
description: Deep architecture review using max effort, delegated to fresh-eyes agent
agent: fresh-eyes
effort: max
---
Review the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).
Focus on: $ARGUMENTS

Evaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.

Significado y límites

El sistema de hooks con campos de respuesta por evento funciona como una capa de middleware programable para el uso de herramientas de IA
La memoria persistente del Agent permite crear especialistas de IA que acumulan experiencia más allá de una sola sesión
El sistema de integración Dream ofrece una estructura que aprende de la experiencia de la sesión sin reentrenar el modelo
El clasificador de Auto Mode recibe descripciones del entorno en lenguaje natural y las refleja en la evaluación de seguridad
Estas funciones, más que configuraciones ocultas o easter eggs, son capacidades base para un entorno de desarrollo con IA persistente, que aprende y es autónomo, y ya están incluidas en el paquete npm actual

¿Quieres seguir recibiendo temas de tecnología seleccionados? Sigue el canal de Telegram. @GeekNewsES

1 comentarios

GN⁺ 3 시간 전

Comentarios en Hacker News

Al revisarlo con Pangram, parece un texto claramente generado por IA
Me sorprende que haya recibido tantas recomendaciones, y me hace dudar de si la gente siquiera lo leyó. Sé que @dang ya creó reglas para contenido generado por IA en los comentarios, pero todavía se ha resistido a hacerlo para los posts. Personalmente, me gustaría que también hubiera una bandera de reporte en los artículos para no perder tiempo con este tipo de contenido de baja calidad
Todo esto ya está documentado [1]. Once también está documentado [2], y async y asyncRewake también lo están [3]. El frontmatter de Skills está completamente documentado [4], y las variables de entorno de Automode también aparecen en la documentación [5]
Este post es puro clickbait escrito por IA, así que me sorprende mucho que aquí haya tenido tan buena recepción
[1] https://code.claude.com/docs/en/hooks#pretooluse-decision-co...
[2] https://code.claude.com/docs/en/hooks#common-fields
[3] https://code.claude.com/docs/en/hooks#command-hook-fields
[4] https://code.claude.com/docs/en/skills#frontmatter-reference
[5] https://code.claude.com/docs/en/auto-mode-config#define-trus...
Este post es de hace 2 meses, así que partes ya están desactualizadas y algunas funciones ya fueron documentadas
Por ejemplo, la documentación de auto mode está aquí: https://code.claude.com/docs/en/auto-mode-config#define-trus...
El paquete claude saca unas 10 versiones nuevas por semana, y además aparecen modelos nuevos cada pocos meses, así que no conviene depender de trucos no documentados alrededor de eso
Es muy probable que cambien, se rompan y descompongan configuraciones demasiado específicas
- En mi experiencia, los trucos no documentados se rompen casi tan seguido como las funciones documentadas
  Como cuando lanzaron 1M Opus y quitaron la opción de “clear context and execute plan” diciendo que “la ventana de contexto ya no es un problema”
- Sí se puede crear automatización para manejar de forma eficiente configuraciones de usuario de bajo nivel cada vez que sale una nueva versión
- Es cierto, pero los hacks temporales a veces pueden salvar o arruinar un flujo de trabajo de punta
  No rediseño las instrucciones de Claude en cada release, pero algunas versiones sí ameritan revisar si las instrucciones existentes siguen ajustándose al modelo actual, y de hecho eso ya ha producido diferencias notables
La cantidad de funciones en Claude Code es asfixiante. A este ritmo, el próximo papa va a salir de Anthropic
- Bromas aparte, Anthropic está lanzando tantas cosas que cuesta confiar en ello
  Con este ritmo, parece difícil que termine siendo un producto suficientemente pensado y estable
Se presentan con eso de “Honest status”, como si fueran a explicar honestamente por qué no va al 100% y por qué toma el camino más largo, https://github.com/user-attachments/assets/961eff6c-0060-45d...
Yo solo quisiera que Claude Code no renunciara a completar la tarea. Es muy frustrante. Incluso usando /goal o el nuevo ultracode, sigue rindiéndose. Mi proyecto sí es bastante complejo (https://github.com/mohsen1/tsz), pero Codex no tiene problema en seguir empujando sin detenerse así
- Ahora uso /loop y le meto un prompt para motivarlo a que siga
  Goal también puede servir, pero para algunas tareas un loop simple funciona mejor
- Justo ahora también hice que Claude llenara una lista de tareas, y antes de llegar al final de la lista me preguntó si quería que siguiera o si bastaba con haber hecho solo una parte
Me pregunto si se está formando algún tipo de arquitectura de aplicaciones de agentes de codificación con IA que sea más o menos universal entre los modelos LLM
También me pregunto si hay alguien reuniendo y organizando formas de entender este estilo de arquitectura
- ¿De verdad están en el mismo sitio? ¿Hoy en día alguien usa otra cosa?
- Los patrones entre Claude Code, Codex y Cursor parecen estar convergiendo: recolección de contexto, planificación, ejecución y validación
  La parte menos estandarizada parece ser cuánto control se le da al usuario entre cada etapa. Ajustes como showClearContextOnPlanAccept o disableAutoMode son interesantes porque dejan ver el límite entre “el agente decide” y “la persona revisa antes de ejecutar”. También da la impresión de que ahí es donde los agentes de codificación van a seguir diferenciándose mucho en la experiencia real de uso
Me da curiosidad la función “magic doc”. No me queda claro si esto va dentro de CLAUDE.md o en un archivo del proyecto
También me pregunto si hay que mencionar ese archivo durante la sesión, o si Claude encuentra automáticamente todo lo que tenga un encabezado de “magic doc” dentro del proyecto
¿Se le puede pedir a Claude que cree su propia configuración? Algo como “imagina que eres yo y crea el paquete ideal de archivos de configuración que tú querrías”
- Según la documentación, si configuras CLAUDE_CODE_NEW_INIT en 1, /init se ejecuta como un flujo de configuración interactivo
  Ese flujo explora la base de código y, antes de escribir archivos, pregunta cuáles quieres crear, como CLAUDE.md, skills, hooks, etc. Sin esa variable, /init genera CLAUDE.md automáticamente sin preguntar
- Probablemente sí. Parece tener herramientas integradas para explorar su propia documentación, y también un modo especial para trabajar dentro del directorio .claude/
  Da la impresión de que está pensado para que el usuario haga justamente eso
- Estaría bueno tener un proyecto cookie cutter con todos los archivos boilerplate y las mejores prácticas incluidas
- Hay un comando slash que revisa el historial de conversación y te agrega permisos permitidos
- Sí se puede. Claude es bastante bueno modificándose a sí mismo
Vas a disfrutar el momento en que descubras que una función no documentada de la que dependías dejó de funcionar de repente
- Si la ingeniería de software de verdad ya es un problema resuelto, como afirma Anthropic, entonces cualquiera debería poder simplemente volver a hacerlo con vibe coding
  Si no tuvieran alergia a la palabra “open”, ya habrían liberado Claude Code como open source; a estas alturas no hay una razón práctica real para no hacerlo

Claude Code: todo lo configurable que la documentación no te cuenta

Versiones de referencia y ubicación de archivos

Los Hooks pueden cambiar el comportamiento de Claude Code con JSON en stdout

Campos que puede devolver PreToolUse

Campos que puede devolver SessionStart

Campos que puede devolver PostToolUse

Campos que puede devolver PermissionRequest

Hook que cambia automáticamente git push a --dry-run

Hook que inyecta vigilancia de archivos y contexto de Git al iniciar la sesión

Hook que aprueba automáticamente comandos Bash de solo lectura

3 campos de configuración de Hook que no aparecen en la documentación

once: true

async: true

asyncRewake: true

Campos ocultos del frontmatter de Skill

model

effort

hooks

agent

disable-model-invocation: true

shell: bash

Campos ocultos del frontmatter de Agent

color

memory

omitClaudeMd: true

criticalSystemReminder_EXPERIMENTAL

requiredMcpServers

El clasificador de Auto Mode recibe descripciones del entorno en lenguaje natural

Bucle de integración entre memoria automática y Dream

autoMemoryEnabled

autoDreamEnabled

Formato de Magic Docs

Sintaxis completa de reglas de permisos

Impacto del caché de context: fork y de la selección de modelo

Ejemplos de combinación de funciones

Revisor de código con memoria persistente y hook de alcance

Configuración de sesión que combina monitoreo de archivos y la red de seguridad de asyncRewake

Revisión de arquitectura que combina override de modelo, control de effort y delegación a Agent

Significado y límites

Lecturas relacionadas

1 comentarios

Comentarios en Hacker News

Campos que puede devolver `PreToolUse`

Campos que puede devolver `SessionStart`

Campos que puede devolver `PostToolUse`

Campos que puede devolver `PermissionRequest`

Hook que cambia automáticamente `git push` a `--dry-run`

`once: true`

`async: true`

`asyncRewake: true`

`model`

`effort`

`hooks`

`agent`

`disable-model-invocation: true`

`shell: bash`

`color`

`memory`

`omitClaudeMd: true`

`criticalSystemReminder_EXPERIMENTAL`

`requiredMcpServers`

`autoMemoryEnabled`

`autoDreamEnabled`

Impacto del caché de `context: fork` y de la selección de modelo

Configuración de sesión que combina monitoreo de archivos y la red de seguridad de `asyncRewake`