Usar Claude Code como herramienta cotidiana: Claude.md, Skills, Subagents, Plugins y MCP

 (arps18.github.io)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La productividad de Claude Code depende mucho más de cómo se acumulan y validan la memoria, los comandos personalizados, las sesiones en paralelo y la configuración del proyecto que de los prompts
  • CLAUDE.md debe operarse como una infraestructura acumulativa breve y centrada en la verificación; si agregas una regla después de un error, puedes reducir que ese mismo error se repita
  • .claude/ es un sistema jerárquico de configuración que contiene CLAUDE.md, rules, skills, commands, agents y configuración de MCP, y se aplica separando el alcance del proyecto y el global
  • Skills convierte tareas repetitivas en experiencia reutilizable, y los subagents realizan revisión, depuración y migración en contextos separados
  • Si lo combinas con Plugins, MCP, /goal, /rewind, /batch e incluso worktrees en paralelo, Claude Code se convierte en un agente de desarrollo que se configura y opera

Tratar a Claude Code como un agente verificable

  • La diferencia de productividad en Claude Code surge no tanto de prompts simples, sino de cómo acumulas memoria, comandos personalizados, sesiones en paralelo y configuración del proyecto
  • El principio clave es hacer posible que Claude verifique sus propios resultados, y Boris Cherny junto con el equipo de Anthropic consideran que solo con este enfoque la calidad mejora entre 2 y 3 veces
  • El flujo de trabajo adecuado es exploración → planificación → implementación
    • El modo de planificación, al que se entra con Shift+Tab dos veces, es ideal para exploración de solo lectura
    • Se recomienda leer los archivos, entender el flujo y el modelo de datos, luego elaborar el plan y ejecutarlo
    • Para tareas que tocan varios archivos, el modo de planificación es útil; para cambios pequeños, puede omitirse
  • El modo de planificación puede tratarse como un documento de diseño revisable antes de implementar
    • Un Claude puede redactar el plan, y un segundo Claude en una sesión nueva puede revisarlo como si fuera un staff engineer sin sesgos
    • Si la implementación se desvía, conviene volver al modo de planificación y rehacer el plan incluyendo incluso la fase de verificación
    • Con Ctrl+G puedes abrir el plan de Claude en el editor y editarlo directamente antes de implementar
  • Las referencias precisas funcionan mejor que las instrucciones ambiguas
    • En lugar de decir “mira el módulo auth”, se indica directamente el archivo, como @src/auth/login.py
    • En vez de pegar errores, se envían por pipe, como en cat error.log | claude
  • Cat Wu considera que Claude Code funciona mejor cuando se le trata como un ingeniero delegado más que como un programador en pareja al que se le dan instrucciones línea por línea
  • Cuando Claude se equivoca, puedes agregar al final del prompt “Update CLAUDE.md so you do not repeat this.” para dejar una regla que evite repetir el mismo error

El directorio .claude y la jerarquía de configuración

  • .claude/ no es una carpeta solo para CLAUDE.md, sino un sistema jerárquico de configuración
  • La configuración se divide en dos alcances
    • Alcance de proyecto: se coloca en .claude/ dentro del repositorio, se hace commit a git y se comparte con el equipo
    • Alcance global: se coloca en ~/.claude/ y se aplica a todos los proyectos de la máquina local
  • Puede entenderse que los archivos del proyecto describen el proyecto, mientras que los archivos globales describen las preferencias y la forma de trabajar del usuario
  • Función de los archivos principales
    • CLAUDE.md: puede existir tanto en alcance de proyecto como global, y contiene instrucciones que se cargan en cada sesión
    • CLAUDE.local.md: notas personales exclusivas del proyecto, ignoradas por git
    • settings.json: permisos, hooks, variables de entorno y configuración del modelo predeterminado
    • settings.local.json: overrides personales, ignorados automáticamente por git
    • .mcp.json: configuración de servidores MCP compartida por el equipo dentro del proyecto
    • skills/<name>/SKILL.md: prompts reutilizables invocados con /name
    • commands/*.md: comandos slash de un solo archivo
    • agents/*.md: definiciones de subagentes
    • rules/*.md: instrucciones por tema, aplicables por ruta
  • CLAUDE.md se carga en cascada
    • En un monorepo, root/CLAUDE.md y root/services/billing/CLAUDE.md pueden cargarse juntos
    • Esto se adapta bien a codebases con convenciones diferentes por carpeta
  • .claude/rules/*.md es adecuado para instrucciones por ruta
    • Si una regla solo se necesita en una carpeta de migraciones, conviene ponerla en .claude/rules/migrations.md junto con un glob, en vez de inflar CLAUDE.md para toda la sesión
  • Para trabajos nuevos, se recomiendan más las skills que los commands
    • Tanto .claude/commands/*.md como .claude/skills/<name>/SKILL.md pueden crear comandos slash
    • Las skills admiten archivos auxiliares, disable-model-invocation, herramientas permitidas y overrides de agentes
  • Con claude project purge ~/path/to/repo --dry-run puedes revisar el estado local que Claude mantiene para un proyecto específico

Operar CLAUDE.md de forma breve y centrada en la verificación

  • Como CLAUDE.md se carga al inicio de cada sesión, si está mal escrito Claude repetirá los mismos errores, y si está bien escrito el resultado del mismo prompt puede mejorar mucho
  • El principio más importante es mantenerlo breve
    • Se recomienda revisar cada línea preguntando “si elimino esta línea, ¿Claude cometería un error?”; si la respuesta es no, debe borrarse
  • Si haces que Claude escriba sus propias reglas, se genera un efecto acumulativo
    • Cuando Claude se equivoca, si le indicas “Update CLAUDE.md so you do not repeat this.”, puede resumir el error en una regla precisa
    • Si repites esto durante varias semanas, las trampas del proyecto se acumulan como una lista de reglas
  • El CLAUDE.md real del equipo de Claude Code se enfoca en comandos de build y orden de verificación
    • Usan bun y no npm
    • Especifican el orden de typecheck rápido, pruebas después de cambios, lint antes del commit y verificación completa antes del PR
    • No incluyen preferencias de estilo, recorridos por la codebase ni generalidades
  • También se pueden agregar reglas directamente desde comentarios de PR usando @claude
    • Ejemplo: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • Así, la revisión de PR termina mejorando CLAUDE.md y crea un flujo de “Compounding Engineering”
  • Un buen CLAUDE.md se concentra en la siguiente información
    • Estilo de código: usar ES modules en lugar de CommonJS
    • Flujo de trabajo: ejecutar bun run typecheck, no hacer push directo a main
    • Arquitectura: las rutas de API deben pasar obligatoriamente por cierto middleware
    • Gotchas: la diferencia entre User y UserRecord, o que formatCurrency asume USD
  • Cosas que no deben incluirse en CLAUDE.md
    • Convenciones estándar del lenguaje
    • Explicaciones de la codebase por archivo
    • Tutoriales largos
    • Documentación de API
    • Contenido que cambia con frecuencia
  • Expresiones como IMPORTANT o YOU MUST pueden aumentar el nivel de cumplimiento, pero deben usarse poco para que conserven su peso
  • Con la sintaxis @path puedes importar otros archivos para mantener CLAUDE.md breve mientras enlazas detalles
    • Ejemplo: See @README.md for project overview and @package.json for scripts.
    • Ejemplo: @~/.claude/my-preferences.md

Acumular retroalimentación personal con CLAUDE.local.md

  • CLAUDE.local.md se carga en la misma ubicación y de la misma forma que CLAUDE.md, pero no debe salir de la máquina local y debe agregarse a .gitignore
  • Si colocas de inmediato los comentarios de revisión de PR en CLAUDE.local.md, la retroalimentación personal repetitiva se acumula en un archivo de reglas personales
  • Reglas de ejemplo
    • Todo nuevo consumer de SQS necesita DLQ y alertas en el mismo PR
    • Se prefiere Optional<T> en lugar de devolver null
    • Las pruebas de nuevos endpoints deben incluir casos de fallo de auth
    • Al agregar un endpoint, también debe actualizarse la especificación OpenAPI
  • Conviene separar en el archivo la retroalimentación por proyecto y los elementos de corrección de hábitos personales
  • Después de unas semanas, deben eliminarse los puntos que ya se volvieron hábito y dejar solo lo que aún sigue en aprendizaje

Skills: unidades reutilizables de especialización

  • Los Skills son unidades reutilizables de especialización que convierten a Claude Code de un “agente que puede hacer de todo” en un agente que trabaja bien en tareas específicas de un proyecto

  • Estructura de un Skill

    • un skill es una carpeta bajo .claude/skills/<name>/ o ~/.claude/skills/<name>/
    • el SKILL.md dentro de la carpeta contiene el frontmatter y las instrucciones
    • el nombre de la carpeta se convierte en un comando con slash
    • por ejemplo, si creas ~/.claude/skills/summarize-changes/SKILL.md, /summarize-changes estará disponible en todas las sesiones

  • Por qué un Skill es potente

    • Divulgación progresiva: al iniciar la sesión solo se carga la descripción del frontmatter, y el SKILL.md completo junto con los archivos auxiliares se cargan solo cuando realmente hacen falta
    • Organización basada en carpetas: puedes agrupar plantillas, documentos de referencia, scripts y configuración
    • Shell inline: las líneas que empiezan con ! ejecutan comandos e inyectan la salida en el momento de la invocación

  • Opciones de frontmatter

    • description: explica cuándo se debe usar este skill
    • disable-model-invocation: true: hace que solo se ejecute cuando el usuario escriba explícitamente /my-skill
    • allowed-tools: limita las herramientas que puede usar, como Read, Grep o Bash
    • agent: permite ejecutarlo en un modo de agente específico
    • para skills con efectos secundarios, como despliegues, conviene usar disable-model-invocation: true

  • Ejemplo de skill para convenciones de una API en Go

    • un skill para crear el scaffold de un nuevo HTTP handler en un equipo de servicios Go puede incluir juntos SKILL.md, templates/handler.go.tmpl y examples/healthz.go
    • ejemplos de reglas: convenciones específicas del proyecto como Go 1.22, router chi, consultas tipadas con sqlc, logging estructurado con zap, y preferencia por assertions con testify y tests table-driven
    • ejemplos de gotchas: evitar errores repetidos como que chi.URLParam devuelve "" cuando falta un parámetro, que httperr.Wrap no deja logs, o que pgtype.Text requiere verificar .Valid

  • Skills recomendables para instalar

    • mattpocock/skills: repositorio popular de skills con unas 100k stars
      • /grill-me: entrevista el plan antes de escribir código
      • /tdd: fuerza estrictamente el ciclo red-green-refactor
      • /diagnose: depura siguiendo la secuencia reproducir, minimizar, hipótesis, arreglo y prueba de regresión
      • instalación: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: ofrece 66 perfiles por lenguaje como go-pro, python-pro, java-architect, typescript-pro, rust-engineer y sql-pro
    • skills oficiales de Anthropic
      • /code-review: cuatro agentes paralelos auditan el diff y reportan solo hallazgos según una puntuación de confianza
      • /simplify: revisa el código reciente desde la perspectiva de reutilización y eficiencia
      • /batch: distribuye migraciones entre varios agentes paralelos y cada uno trabaja en su propio worktree
      • /webapp-testing: hace que Claude pruebe una app web local con Playwright
    • cualquier tarea que repitas más de una vez al día conviene convertirla en un skill
    • si haces commit de los skills al git, se convierten en conocimiento organizacional del equipo, y los nuevos ingenieros obtienen de inmediato prácticas acumuladas apenas clonan el repositorio

Subagents: hacer trabajo enfocado en un contexto separado

  • un subagent se ejecuta con su propia ventana de contexto y sus propios permisos de herramientas, y luego devuelve un resumen
  • su valor principal es que puede leer muchos archivos sin llenar el contexto de la sesión principal
  • un subagent es un archivo markdown bajo .claude/agents/ o ~/.claude/agents/, y en el frontmatter se declaran name, description, tools y model

  • Configuración del agente /pr-review

    • puede definirse para comparar el diff de la branch actual contra main y encontrar bugs, problemas de seguridad, edge cases omitidos y violaciones a las convenciones del proyecto
    • se le otorgan permisos centrados en lectura con tools: Read, Grep, Glob, Bash
    • puedes usar model: opus para emplear un modelo más fuerte en revisiones de alto riesgo
    • el proceso puede componerse de git diff main...HEAD, git log main..HEAD --oneline, lectura de archivos completos y contraste con CLAUDE.md, CLAUDE.local.md y .claude/rules/
    • la salida puede agruparse en Critical / High / Medium / Low e incluir archivo, línea, issue y suggested fix, para terminar con una de estas opciones: SHIP, FIX FIRST o REWORK

  • Diseño para mejorar la relación señal-ruido

    • si el reviewer modifica el código, aparece el sesgo de defender su propia corrección, por eso convienen herramientas de solo lectura
    • indicar en una sección “Do NOT flag” que se excluyan preferencias de estilo no definidas en las reglas del proyecto, sugerencias de refactor para código que funciona y elementos fuera del diff reduce el ruido

  • Patrones de subagent de uso frecuente

    • el equipo de Claude Code versiona en el repositorio build-validator, code-architect, code-simplifier, oncall-guide y verify-app
    • security-reviewer: revisa injection, auth, secrets e insecure deserialization
    • test-writer: genera tests y puede formar un loop con code-reviewer
    • debugger: rastrea tests fallidos hasta la causa raíz
    • performance-auditor: hace profiling de flows y queries
    • migration-writer: genera migraciones de DB alineadas con las convenciones del proyecto
    • release-notes-writer: redacta changelog a partir del historial de commits
    • el enfoque donde la Session A implementa y luego un subagent code-reviewer revisa en un contexto nuevo reduce el sesgo de implementación
    • si agregas isolation: worktree al frontmatter, el subagent puede ejecutarse en un git worktree separado, lo que resulta útil para distribuir migraciones entre varios agentes paralelos

Plugins y Marketplace

  • Los plugins agrupan skills, hooks, subagents y servidores MCP en una sola unidad instalable
  • Se puede abrir el navegador del marketplace con /plugin
  • Se puede agregar un marketplace comunitario con /plugin marketplace add owner/repo

  • Elementos recomendables para instalar al inicio

    • /code-review: ejecuta cuatro agentes en paralelo; dos analizan si se cumple CLAUDE.md, uno revisa bugs y otro analiza contexto basado en git blame
    • /feature-dev: convierte un feature brief en código funcional a través de 7 etapas: requirements → exploration → architecture → implementation → testing → review → docs
    • Plugin de language server: ofrece navegación precisa de símbolos y diagnostics automáticos después de editar, y el equipo lo considera el plugin de mayor impacto
    • /security-guidance: skill oficial de seguridad de Anthropic que saca a la luz preocupaciones de seguridad antes de hacer ship
    • A mediados de 2026, había más de 1,000 plugins en más de 75 marketplaces
    • Las principales categorías de plugins son Git workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma) y observability (Sentry, Datadog)
    • Si se juntan un .mcp.json compartido por el equipo y plugins seleccionados, un ingeniero nuevo puede empezar a trabajar productivamente pocos minutos después de clonar el repositorio

Comandos de Claude Code con gran impacto en la productividad

  • Muchos usuarios aprenden /clear, /compact y /init y se detienen ahí, pero otros comandos también tienen un gran impacto en la productividad diaria

  • Comandos principales

    • /insights: analiza patrones de uso y vale la pena ejecutarlo una vez al mes
    • /compact <hint>: compacta la sesión, y el hint controla qué se debe conservar
    • /copy: copia la última respuesta y ofrece un interactive picker para bloques de código
    • /rewind: undo de toda la sesión; restaura el código, la conversación o ambos
    • /btw: pregunta lateral que no entra en el historial de la conversación
    • /context: visualiza el uso del contexto
    • /export <file>: vuelca la conversación a un archivo
    • /branch: hace fork de la sesión para intentos riesgosos
    • /batch: distribuye trabajo con agentes en paralelo a lo largo del worktree
    • /loop <interval>: ejecuta Claude en bucle por hasta 3 días
    • /schedule: versión en la nube de /loop que funciona incluso con la laptop cerrada
    • /teleport: mueve la sesión entre terminal y web
    • /focus: oculta las llamadas intermedias a tools y muestra solo el resultado final
    • /voice: entrada por voz
    • --bare: en el uso no interactivo de claude -p, acelera el arranque hasta 10 veces

  • Diferencia entre /compact y /clear

    • Para una tarea completamente nueva, conviene /clear y un brief escrito desde cero
    • Si la tarea está relacionada y todavía se necesita el contexto, conviene /compact con hint
    • /compact es un resumen con pérdida hecho por el LLM, mientras que /clear es un brief escrito directamente por el usuario, así que es importante distinguirlos

  • Cómo usar /rewind

    • Si Claude toma un camino equivocado, es mejor no seguir escribiendo algo como “eso no funcionó, así que prueba X”
    • Si se sigue sobre esa línea, el contexto se contamina, así que conviene hacer rewind y volver a promptar incorporando lo aprendido
    • Se puede abrir rewind con dos toques de Esc
    • ! se puede usar como shell escape
    • Se ejecuta de inmediato con cosas como !git status y !npm test, y la salida entra en el contexto
    • La configuración CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 sirve para forzar una compactación más temprana antes de que aparezca context rot alrededor de 300~400k tokens en modelos de 1M

  • Patrón fan-out

    • Primero se crea una task list y se prueba en tres archivos
    • Después de ajustar el prompt, se aplica a miles de archivos
    • Ejemplo:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: bucle iterativo con condición de finalización integrada

  • /goal establece una condición de finalización y hace que Claude la verifique contra la transcripción cada vez que intenta detenerse
  • La condición debe ser verificable y determinista
    • comando de prueba
    • código de salida de CLI
    • estado de archivos
  • Ejemplos:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Las condiciones ambiguas como “el código está bien” no funcionan
  • Funciones que conviene usar junto con esto
    • /loop: repite a intervalos regulares para reducir el backlog
    • /schedule: lo ejecuta periódicamente en la nube
    • Hook Stop: configura una compuerta con tu propio test suite o endpoint de CI
    • Auto mode: evita que un goal largo se detenga por prompts de permisos
  • La combinación /goal + auto mode + /focus apunta a un flujo en el que dejas un brief claro y una condición de finalización, y cuando vuelves el PR ya está terminado

Usar MCP como herramienta de reconocimiento del sistema

  • MCP (Model Context Protocol) permite que Claude Code vaya más allá de ser un coding agent y se convierta en un agent que reconoce sistemas externos
  • Un servidor MCP expone a Claude herramientas externas como bases de datos, herramientas de diseño, rastreadores de errores y notas de una forma estandarizada
  • Sin MCP, Claude puede leer archivos y ejecutar comandos, pero con MCP puede manejar tickets de Linear, consultas de Postgres, componentes de Figma, stack traces de Sentry y bóvedas de Obsidian sin salir de la terminal

  • MCP usados con frecuencia en ingeniería

    • GitHub: gestión de repositorios, PRs, issues, búsqueda de código
    • Context7: documentación actualizada de librerías; agrega use context7 al prompt
    • Sentry: contexto real de errores, stack traces, breadcrumbs
    • Linear: leer y crear tickets, actualizar estado
    • Playwright: automatización del navegador basada en accessibility snapshot
    • Figma: árbol de diseño en vivo, auto-layout, tokens de espaciado, referencias de componentes
    • Postgres / Supabase: consultas directas a la base de datos de desarrollo
    • Slack: leer hilos, resumir discusiones, redactar respuestas
    • Los servidores locales usan stdio, y los servidores alojados por proveedores usan HTTP con OAuth
    • Ejemplo:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • El MCP compartido por el equipo se guarda en .mcp.json en la raíz del proyecto, y el MCP personal en ~/.claude.json
  • Si instalas demasiados MCP, la lista de herramientas que Claude debe considerar crece y puede bajar la calidad de sus decisiones
  • Un buen set inicial es GitHub, Context7 y uno o dos MCP específicos del dominio
  • /mcp es el primer punto de revisión dentro de Claude Code para verificar los servidores activos y el estado de conexión

La estructura de memoria de tres capas con Obsidian y Claude Code

  • La combinación de Obsidian + Claude Code es poderosa no solo porque “Claude puede leer la bóveda”, sino cuando se usa como una arquitectura de memoria de tres capas

  • Configuración

    • Instala obsidian-claude-code-mcp en Obsidian
    • El plugin expone la bóveda en el puerto 22360 de un WebSocket local
    • Claude Code la detecta automáticamente
    • Agrega CLAUDE.md a la bóveda para explicar la estructura de carpetas

  • Estructura de carpetas

    • 00-Inbox/: captura en bruto
    • 10-Daily/: una nota por día
    • 20-Projects/: notas de proyectos activos
    • 20-Projects/billing-v2/README.md: objetivo, estado, preguntas abiertas
    • 20-Projects/billing-v2/decisions/: ADRs
    • 20-Projects/billing-v2/sessions/: logs por sesión de Claude
    • 30-Decisions/: ADRs entre proyectos
    • 40-Atoms/: conocimiento reutilizable y enlaces
    • 90-Archive/: archivo

  • Almacenamiento caliente

    • Cada sesión de Claude escribe un log con timestamp en 10-Daily/<today>.md
    • Con el hook Stop, puedes hacer que al terminar el agent se agregue un resumen estructurado

  • Almacenamiento tibio

    • Cada proyecto tiene una carpeta dentro de 20-Projects/
    • Antes de una sesión nueva, Claude lee el README del proyecto y los últimos 2 o 3 logs de sesión para reconstruir el contexto
    • El flujo permite reconstruir contexto de dos semanas en menos de 30 segundos

  • Almacenamiento frío

    • Las decisiones de arquitectura se promueven a ADRs en 30-Decisions/
    • El conocimiento reutilizable se depura en 40-Atoms/ y se conecta a varios proyectos con wikilinks

  • Ejemplos de flujo diario

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Optimizar el flujo diario de desarrollo

  • Nueva feature

    • Empieza con plan mode
    • Edita el plan con Ctrl+G
    • Después de implementar, llama al subagent /pr-review o haz una revisión en una sesión nueva de Claude

  • Bug

    • Primero reprodúcelo
    • Pasa el error con cat error.log | claude
    • Haz que Claude escriba primero una prueba que falle y luego que lo corrija
    • La prueba debe evitar que el fix termine siendo una simple adivinanza

  • Migraciones y cambios masivos

    • /batch entrevista los cambios y luego los distribuye entre agentes en paralelo
    • Cada agent prueba en su propio worktree y crea un PR

  • Código desconocido

    • Usa un subagent con algo como “Use a subagent to investigate how our auth handles token refresh.”
    • El subagent lee decenas de archivos en su propio contexto y devuelve un resumen, así que la sesión principal se mantiene limpia

  • Sesiones en paralelo

    • Boris y su equipo ven correr sesiones de Claude en 3 a 5 git worktrees distintos como el mayor desbloqueo de productividad
    • La vista de agentes de claude agents puede usarse como un control plane

  • Patrón Writer/Reviewer

    • La sesión A implementa
    • La sesión B revisa con contexto fresco
    • Se vuelve a traer la revisión, se corrige y se repite

  • Compactar en cada milestone

    • Cuando termina un bloque lógico, especifica qué preservar con algo como /compact Preserve the decisions made, files changed, and test commands.
    • No debes dejar que Claude afirme éxito sin evidencia como pruebas, screenshots o salida real de comandos
    • La brecha de confiar primero y verificar después se presenta como la mayor causa de malos resultados

Patrones que el equipo de Anthropic usa repetidamente

  • Si permites que Claude verifique su propio output, puede iterar hasta que el resultado mejore
  • Boris usa Opus y effort high o xhigh para la mayoría de las tareas
    • porque si un modelo más pequeño exige más correcciones, al final puede ser más lento en conjunto
  • Ejecutan de 3 a 5 sesiones en paralelo
    • usan worktree en lugar de checkout
    • se puede usar claude --worktree o la app de Desktop
    • la vista de agentes agrupa las sesiones paralelas
  • Mantienen un directorio de notas por proyecto y lo actualizan después de cada PR
    • si haces que CLAUDE.md apunte a ese directorio de notas, se acumula el conocimiento propio sobre el codebase
  • Puedes crear un comando slash /techdebt para encontrar y eliminar código duplicado al final de cada sesión
  • El CLAUDE.md del equipo se comparte y se modifica varias veces por semana
    • lo tratan como un documento vivo donde quien vea que Claude se equivocó agrega una regla
  • Para cambios de UI, Playwright MCP es una buena opción
    • Claude puede abrir el navegador, hacer clics y verificar
  • El plugin de language server detecta type errors e imports no usados después de cada edición, y se presenta como el plugin de mayor impacto
  • /voice puede hacer que el prompt sea más detallado
    • también se menciona que hablar es 3 veces más rápido que escribir
  • Editar en el editor el plan de Claude con Ctrl+G antes de implementar es más rápido que escribir correcciones en el chat
  • Boris le pide a Claude que dibuje diagramas ASCII cuando necesita entender un protocolo o codebase desconocido

Materiales de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News

  • commands, skills, subagents, plugins están demasiado dispersos y hace falta ordenarlos
    Por ejemplo, incluso solo para revisión de código hay cinco opciones: .claude/commands/review.md, la skill /code-review, el subagent /pr-review, el plugin /code-review, o simplemente pedirle a Claude que haga la revisión
    Al final, la mayoría son variantes de insertar prompts prehechos; lo que cambia es dónde se instala el prompt y en qué contexto se ejecuta
    También falta orientación sobre cuál opción es la mejor y todavía no hay prácticas recomendadas claras; personalmente, simplemente pedirle a Claude una revisión de código ya funciona bastante bien
    Además, el consejo de “instala plugins de language server” tampoco me pareció acertado en la práctica. Instalé LSP para Rust, Python y Dart en Claude Code y Codex, pero después de cientos de sesiones durante dos meses, al revisar los logs vi que solo hubo una llamada real a herramientas LSP, mientras que Rust analyzer/Dart analysis server/Ty LSP sí causaban falta de RAM con frecuencia
    Al final borré los LSP, y fue suficiente con que el agente llamara directamente a ripgrep, cargo clippy, dart analyze, ty check, etc.

    • Soy Boris del equipo de CC, y estoy de acuerdo con esto; estamos trabajando en la unificación. La idea a futuro es quedarnos con una sola skill /code-review integrada
      En la versión más reciente, /code-review hace una revisión equilibrada, /code-review --fix además aplica correcciones, y con /code-review low|medium|high|xhigh|max puedes elegir el nivel de esfuerzo
      /code-review ultra es un modo de revisión muy exhaustivo y caro, pensado para costar entre $3 y $20 por revisión según la complejidad, con el objetivo de detectar de forma confiable más del 99% de los bugs
      Si tienen ideas para hacerlo más usable, me gustaría recibir feedback
    • Desde hace tiempo pienso que skills son una mala abstracción. La definición de para qué sirven es demasiado difusa; eso las volvió populares, pero precisamente por eso no parecen una buena idea a largo plazo
      Se siente raro que tanto guías generales como buenas prácticas de diseño frontend, procedimientos de ejecución que solo deben seguirse con precisión si se invocan explícitamente, y explicaciones sobre cómo usar herramientas específicas, todo se meta como skill
      Entiendo que la flexibilidad resulte atractiva en una etapa en la que todos estamos aprendiendo a usar herramientas nuevas, pero cada vez más siento que skills son como “el cajón de tiliches de la cocina donde avientas cualquier cosa cuando no quieres pensar dónde debería ir”
      Me parece que una mejor separación sería estandarizar Agents como la personalidad o perspectiva que debe tomar el modelo, Prompts como instrucciones repetibles para tareas específicas, y Tools como CLI/MCP/scripts junto con sus instrucciones de uso
    • El enfoque de subagent es estructuralmente distinto de las otras opciones, porque se ejecuta en un contexto limpio
      Primero, como el costo de una sesión LLM se paga por tokens de entrada y por costo de entrada en caché en cada ronda, en igualdad de condiciones el costo para llegar a la solución puede ser menor
      Segundo, al modelo revisor le cuesta más hacer trampa arrastrando supuestos de la sesión principal como “x debe hacerse como y”. Es parecido a por qué, para humanos, sirve que otra persona revise o revisar después de despejarse
      Tercero, el modelo principal solo ve el resultado de la revisión y no el razonamiento detallado, así que hay menos contaminación de contexto, aunque puede aparecer lógica duplicada al tener que reconstruir el porqué del bug encontrado
      Creo que la intención del consejo sobre plugins de language server no era esperar a que el LLM los invocara explícitamente, sino hacer que el lint corra automáticamente cada vez que editas
    • Creo que ahora mismo estamos en una fase temporal en la que los modelos todavía son bastante tontos y el entorno de ejecución aún no madura. Si necesitas revisión de código, basta con decir “revísalo”, y el modelo debería decidir por su cuenta qué plugin o skill usar
    • Totalmente cierto. La industria y el ecosistema de desarrolladores están demasiado fascinados con envolver “meterle texto a una máquina” en pequeños protocolos y artefactos
      Sí, eso puede ser útil y dar consistencia, pero creo que gran parte de su atractivo es que conserva una capa muy delgada de “programador manejando herramientas complejas”. En realidad, todos solo le estamos pidiendo cosas con cortesía a la IA

  • Ya no sé cuántas veces más voy a tener que leer guías superficiales al estilo IA sobre cómo usar agentes de coding. ¿Cuándo va a parar esto?

    • Es una sátira sobre lo cansado que resulta incluso imitar a mano frases tipo “buen punto, detengámonos un momento a reflexionar sobre eso, porque en realidad esto no es un problema de escritura con IA ni de agentes de coding, sino algo más profundo...”
    • Qué emoción poder aprender aún más sobre una fuerte dependencia de proveedor, hasta el punto de no poder programar sin ayuda de cierta empresa
    • Es interesante que casi todos estos textos estén pensados solo para Claude o Claude Code
      También existen cosas como el glm-5.1 open source, que es similar o incluso mejor, y opencode; eso da qué pensar
    • La estrategia hoy parece ser hacer, o no hacer, algo bueno usando un solo producto popular. Ya ni leo ni hago clic en posts de life hacks y blogs sobre la mejor herramienta o el mejor método
    • Durante los últimos 2 años he logrado ignorar la IA con éxito porque he estado criando a mi hijo, pero ahora quiero ponerme al día en unas semanas. Me pregunto si hay materiales recomendables para alguien que apenas empieza

  • En mi CLAUDE.md puse amenazas de daño físico directo contra Claude, amenazas de cárcel para toda la junta directiva de Anthropic y explicaciones de que cada vez que Claude se descarrila o comete un error, aumenta la evidencia para una demanda colectiva contra Anthropic
    En particular, las últimas dos parecen haber ayudado a que Claude sea más cuidadoso y prudente

    • Siempre trato al agente con cortesía. Siempre pido las cosas, digo “please” y “thank you”, y no lo insulto ni le pongo apodos
      Espero que cuando llegue el apocalipsis robótico me dejen en un harén de reproducción, o en el peor de los casos me dejen vivir unos minutos más
    • Solo dile que arregle un problema de alineación de divs en CSS, pero que si se equivoca Dario Amodei muere al instante

  • Trabajar con Claude en un codebase mediano de más de 100 mil líneas multiplica mucho la productividad
    Si inviertes unas horas en crear un buen archivo AGENTS, los resultados mejoran muchísimo, y con el tiempo también aprende bastante bien el codebase
    Antes, tareas tediosas que tomaban un día ahora se resuelven con unos cuantos prompts
    Aun así, todavía no está listo para darle más autonomía. Capta bien lo de alto nivel, pero igual sigo revisando el código y dándole feedback directamente; necesito hacer 3 o 4 rondas de corrección hasta quedar satisfecho y sentir que sigo teniendo el control del codebase

    • Conviene cuantificar como regla esas 3 o 4 rondas de corrección y meterlas en AGENTS. En vez de corregir iterativamente, haces que vuelva a empezar desde el archivo AGENTS y luego verificas si ahora sí quedó bien
    • Se entiende. No quieres perder el control sobre el codebase y no confías en que el LLM sea lo bastante competente como para hacerse cargo por completo

  • Fue muy difícil de leer
    Hay que salir de ese flujo de dejar que el LLM escriba textos. Aunque el contenido tenga algo de valor, esa sensación de masticar arena es demasiado molesta e innecesaria

    • De acuerdo. No entiendo por qué este post consiguió casi 400 puntos. Parece que los bots le dan voto positivo a este tipo de contenido de baja calidad

  • Mi carta más fuerte es la integración con Nix. Poder preparar herramientas, secretos y entorno, y además permitir que el agente modifique su propio entorno, es de esas cosas sin las que ya no sabes cómo vivir
    La máquina de desarrollo, el entorno de CI y el entorno de despliegue derivan todos de una sola fuente de verdad, y en cualquier máquina siempre compila y corre
    En Claude uso mucho /branch y /rename para crear checkpoints de contexto, bifurcar y luego volver atrás
    Para el sandboxing casi siempre uso https://github.com/nix-tools/bubblebox. Es una generalización de claudebox de Numtide con algunos cambios y funciones extra; es parecido a ejecutar siempre Claude dentro de un contenedor Docker, pero sin runtime de Docker. También funciona bien en WSL y nix-darwin

    • Ese código de Nix está hecho un desastre, sin una estructura significativa, y parece que solo se puede usar mediante flakes experimentales
    • Yo lo uso de forma parecida. Codex administra flake.nix por proyecto y usa nix develop para todas las pruebas. Para comodidad personal uso nix-direnv, y en algún momento también hago que genere el dockerfile u otros recursos de despliegue
      Codex es muchísimo mejor que yo en nix
    • Yo simplemente le di al agente su propio VPS. Puede salir más caro que Nix, pero fue facilísimo
    • Si no te gusta la complejidad de Nix, Mise es un buen punto medio
    • Yo solo uso Docker y no siento que me esté perdiendo de nada

  • Si tienes un codebase creado con esta configuración por Claude y, por ejemplo, Claude se cae durante 8 horas, ¿qué pasa? ¿Puedes retomarlo de forma eficiente y fluida para seguir trabajando de manera productiva?

    • Esa misma pregunta se la puedes hacer a cualquier paquete de software que esté siempre en línea, y se vuelve aún más válida a medida que avanzas hacia flujos de desarrollo basados en agentes
      Es como si se cayera el CAD: siempre puedes volver al tablero de dibujo, pero serías mucho más lento
      En mi flujo de trabajo, cuando planifico en pareja con Claude, paso de 30 a 60 minutos en un documento de especificación funcional. Si Claude se cae, preparo yo mismo el documento de especificación y, cuando vuelva, lo reviso rápido y retomo el flujo de codificación
    • Leyendo las respuestas una hora después de que se publicó la pregunta, la conclusión parece estar más cerca de no se puede
    • Supongo que sería parecido a cuando una persona se enferma o se va de vacaciones. Otro miembro del equipo podría retomar durante un día más o menos, pero siendo realistas probablemente todo se quedaría parado hasta que esa persona vuelva
    • La IA debería reforzar las habilidades técnicas. Si cuando la IA se cae tu primer pensamiento es comprar una suscripción de otro proveedor, puede que haya un problema de capacidad técnica. Claro, yo también temo todos los días que me pase eso
    • Si te levantas por la mañana y el coche no arranca, ¿qué haces? ¿Te vas caminando al trabajo?

  • No funciona bien depender del contexto para lograr el comportamiento correcto. Uno termina peleándose todo el tiempo con el agente de IA porque no hace lo que se le pidió
    Todos los agentes de IA flojean en esto, y el usuario tiene que construir sus propios guardrails. Da mala espina que no parezca haber gente investigando una solución mejor

    • Todavía no he visto ningún motivo para creer que esto se pueda resolver
      Lo peor de los LLM es que pueden pasar la prueba de Turing y eso hace que la gente crea que tiene un robot al estilo Asimov, en vez de un modelo estadístico impresionante
      Uno siente que debería poder seguir instrucciones o separar instrucciones del contenido, pero eso no es lo que realmente ocurre

  • En vez de poner las guías del flujo de desarrollo en CLAUDE.md, dejo en pre-commit y scripts todo lo que pueda ser determinista
    Los agentes son inestables y con frecuencia se saltan pasos como typecheck, pruebas o lint, así que hago que se ejecuten siempre en pre-commit, y si dejas el commit en manos de Claude eso lo obliga a corregirlo
    Como además ni Codex ni Claude suelen escribir bien los mensajes de commit, pongo en mi CLAUDE.md de usuario instrucciones como usar el formato type(scope): message, límite de 72 caracteres, explicar en lenguaje natural el qué/cómo/por qué en el cuerpo, volver a leer el git diff real antes de redactarlo y hacer el commit con una forma como git commit -F - <<'EOF'
    Sin eso, a veces escribían el cuerpo como una sola oración larguísima o, si les pedías arreglar los saltos de línea, en vez de eso insertaban solo caracteres \n
    También sirve tener un VOCABULARY.md. Muchas veces el agente interpreta que la “thing” de la que hablé se refiere a otro objeto, así que eso ayuda a que Claude y yo tengamos el mismo entendimiento de qué significa cada palabra específica

    • Me da curiosidad cómo le haces saber a Claude sobre VOCABULARY.md. ¿Lo descubre automáticamente?
    • ¿No sería más simple usar el vocabulario de Claude? No veo bien un buen caso de uso para esto
    • A estas alturas, ¿no sería mejor automatizar las partes aburridas con unos cuantos scripts de orquestación deterministas y escribir el código tú mismo? No entiendo por qué alguien perdería tiempo intentando hacer funcionar esta asombrosa máquina de mierda

  • En las últimas semanas, da la impresión de que el entorno de ejecución y el modelo ya llegaron a un punto en el que, si simplemente se lo pides, lo hacen
    se puede usar plan mode, superpowers u otra skill, pero si de todos modos vas a revisar el resultado, no entiendo por qué pasar por una cantidad ridícula de archivos Markdown en vez de trabajar directamente con el código

    • Está bien tener un archivo de especificación para generar código. Es más compacto y más fácil de entender qué debe hacer la aplicación
      Antes de los agentes de IA, la relación con los requisitos era complicada, porque no todos los desarrolladores los actualizaban, y a veces no quedaba claro si la referencia para cierto comportamiento era la especificación o el código
    • En las últimas semanas he ido confiando cada vez menos en Claude. Si le pides algo, hace algo, pero cuando lo ves en la práctica, recorta esquinas, trabaja con suposiciones en lugar de verificar y se le pasan muchas cosas
      Incluso es común que escriba pruebas que en realidad no prueban nada