Cómo configurar un entorno completo para programar con agentes

Primeros pasos para programar con IA prepara lo básico para trabajar con un agente: el archivo de instrucciones, las reglas de permisos, las skills y la revisión del diff. Cuando el proyecto crece, se añaden dos piezas más. Los subagentes revisores revisan cada cambio desde un contexto propio, y los agentes de trabajo reciben piezas acotadas de una tarea grande.

El punto 2 describe un prompt que configura todo eso en su proyecto: instrucciones, permisos, skills, cuatro revisores y seis agentes de trabajo. Cópielo con el botón «Copiar prompt» del panel «Configurar entorno».

Cada pieza tiene un coste. La descripción de cada skill y de cada subagente se envía en todas las peticiones de la sesión, y cada revisión lanza varios modelos. En un proyecto pequeño, o en las primeras semanas con un agente, lo básico de primeros pasos basta. Añada las piezas de este entorno cuando una tarea se repita.

Las mediciones se hicieron el 26 de septiembre de 2026 con Claude Code 2.1.283, git 2.49.0, Node.js 24.19.0 y npm 11.8.0. Todo el código está reconstruido para el artículo.

1. Qué son los subagentes y cómo repartir la revisión

Un subagente es un agente especializado que trabaja en su propia ventana de contexto, con sus propias instrucciones y herramientas. No ve la conversación principal, y al terminar solo devuelve un resumen¹. Por eso sirve para revisar: el revisor no recibe el razonamiento de quien escribió el cambio.

Se define en un archivo Markdown, en .claude/agents/ para el proyecto o en ~/.claude/agents/ para todos sus proyectos¹:

---
name: revisor-calidad
description: Revisa si un cambio se va a poder mantener. Úsalo sobre el diff antes de confirmar.
tools: Read, Grep, Glob, Bash
model: sonnet
---

Tu pregunta es una: ¿este cambio se va a poder sostener?
Busca funciones que el proyecto ya tiene y el cambio reimplementa,
imports sin usar o que cruzan una capa, y funciones que
hacen varias cosas a la vez.
Cada hallazgo lleva archivo:línea, el fallo concreto y qué ejecutaste para comprobarlo.
Cero hallazgos es un resultado válido.

Qué hace cada campo:

• name y description: son obligatorios. La descripción decide cuándo el agente principal le pasa el trabajo¹.
• tools: las herramientas permitidas. Un revisor no necesita editar, así que no recibe Edit ni Write.
• model: el modelo que usa; con inherit, toma el de la sesión.
• El cuerpo: sus instrucciones, que sustituyen a las instrucciones por omisión de Claude Code.

La documentación recomienda que cada subagente se centre en una sola tarea¹. Por eso una revisión útil se reparte entre cuatro subagentes, con una pregunta cada uno:

1. El de seguridad pregunta si el cambio permite a alguien hacer o ver algo que no debería.
2. El de calidad pregunta si el cambio deja el código mejor o peor, en duplicación, imports y estructura.
3. El de errores y tipos pregunta si algún error puede pasar sin que nadie se entere. También pregunta si los tipos permiten un estado que no debería existir.
4. El de pruebas no juzga el diseño. Ejecuta la suite, los tipos y el linter, mide si las pruebas fallarían al romper el código y ejecuta lo que el de seguridad necesita comprobar.

Un revisor útil se distingue por lo que exige a cada hallazgo, y varias fuentes públicas lo especifican. La guía de auditoría de Cloudflare solo acepta un hallazgo de seguridad si nombra quién cruza qué frontera de confianza y qué resultado concreto produce. Además, solo da gravedad a lo confirmado².

El revisor de seguridad de Anthropic solo reporta lo que considera explotable con más de un 80 % de confianza. Además, descarta de forma explícita categorías que suelen ser ruido³. ECC obliga a citar la línea exacta, a leer las funciones que llaman al código revisado y a aceptar que una revisión sin hallazgos es válida⁴. La guía de revisión de Google pide no aceptar cambios que empeoren la salud del código del sistema⁵.

Cada subagente consume tokens con su propio modelo, y el campo model decide cuál. Si ni la llamada ni la definición lo fijan, Claude Code usa el modelo de la variable CLAUDE_CODE_SUBAGENT_MODEL. Si esa variable no existe, usa el de la conversación principal¹. Así, si la conversación usa el modelo mayor, los subagentes sin modelo propio también lo usan. Un revisor que busca en archivos no necesita el mismo modelo que uno que razona sobre autorización, así que cada definición fija el suyo.

Si varios subagentes editan a la vez el mismo directorio, uno puede sobrescribir los cambios de otro. Un árbol de trabajo (worktree) de git lo evita: es otro directorio del mismo repositorio, con su propia rama. Cada subagente trabaja en el suyo, y el agente principal fusiona las ramas de una en una. En Claude Code se activa con isolation: worktree en la definición del subagente. Por omisión, el árbol parte de la rama principal del remoto, no de la rama actual⁶.

Los seis agentes de trabajo se reparten del mismo modo, cada uno con su nivel de modelo:

1. explorador localiza y explica código, con un modelo pequeño.
2. arquitecto diseña el cambio y lo divide en piezas, con el modelo mayor.
3. implementador resuelve una pieza en su propio árbol de trabajo, con un modelo intermedio.
4. resolutor-compilacion deja en verde la compilación, los tipos y el linter con el cambio mínimo, con un modelo intermedio.
5. documentador pone al día la documentación, con un modelo pequeño.
6. limpiador quita código muerto y duplicación cuando se le pide, con un modelo intermedio.

Solo el agente principal los lanza, y fusiona sus ramas de una en una.

Un workflow es un guion que lanza decenas de subagentes por fases. Claude Code avisa cuando un workflow programa más de 25 agentes. También admite una guía de tamaño que fija un objetivo de menos de 5, de 10 o de 50 agentes⁷.

Cómo hacerlo.

1. Cree .claude/agents/revisor-calidad.md con el ejemplo.
2. Láncelo nombrándolo: @agent-revisor-calidad revisa el diff actual¹.

El prompt del punto 2 crea los cuatro revisores, los seis agentes de trabajo y la skill revisar-cambio, que lanza la revisión.

Cómo comprobarlo. Introduzca a propósito dos fallos de calidad, una utilidad que ya existe reimplementada y un import sin usar, y lance el revisor. Si no los señala, sus instrucciones no bastan.

2. Cómo configurar el entorno completo con un prompt

Todo lo anterior se puede configurar a mano, archivo por archivo. También puede hacerlo el agente con un prompt, en cualquier harness que lo reciba. Cópielo con el botón «Copiar prompt» del panel «Configurar entorno» y péguelo en una sesión abierta en la raíz del proyecto. El agente sigue once fases:

1. Reconoce el proyecto sin escribir nada. Averigua en qué harness se ejecuta, qué modelos ofrece y en qué nivel está cada uno, y el lenguaje del proyecto. También busca las órdenes reales de pruebas, linter, tipos y auditoría, y cómo autentica y autoriza el proyecto.
2. Propone y espera. Presenta los archivos que va a crear y el modelo de cada subagente, y se detiene hasta que usted confirma. Incluye también las herramientas opcionales recomendadas, cada una con lo que envía fuera de la máquina.
3. Escribe AGENTS.md con las órdenes comprobadas, las convenciones, un apartado opcional de vocabulario del dominio y qué skill o agente usar en cada situación.
4. Bloquea la lectura de secretos con la regla de permisos de su harness, y lo comprueba intentando leer .env.
5. Crea cuatro skills de método. aclarar le hace preguntas por rondas antes de construir, con la respuesta que recomienda en cada una. El agente busca en el código lo que se puede averiguar, y las decisiones son suyas. pruebas-primero y depurar fijan el ciclo de la prueba que falla y la búsqueda de la causa raíz. orquestar decide cuántos subagentes lanzar y con qué nivel de modelo. También decide cuándo usar árboles de trabajo y workflows.
6. Crea los cuatro revisores del punto 1. El de seguridad lleva un archivo de contexto del proyecto y nueve listas por dominio, que carga según lo que toque el cambio. El de calidad comprueba además si el cambio hace lo que se pidió, con lo que falta y lo que sobra. El de errores y tipos busca fallos silenciosos, bloques catch que ocultan errores, valores de respaldo engañosos, estados imposibles y conversiones forzadas.
7. Crea los seis agentes de trabajo del punto 1, cada uno con su nivel de modelo.
8. Crea la skill revisar-cambio, que lanza en paralelo los revisores de seguridad, calidad y errores, deja el de pruebas para el final y compone el veredicto.
9. Propone ajustes opcionales: el modelo por omisión de los subagentes, el tamaño de los workflows, la rama base de los árboles de trabajo y tres hooks. Los hooks formatean el código, protegen los archivos sensibles y bloquean órdenes destructivas como git push --force, git reset --hard o rm -rf.
10. Propone tres herramientas y dos colecciones de skills, todas opcionales: graphify, claude-council, archify, las skills de Matt Pocock y gstack. Pregunta antes de instalar cada una.
11. Comprueba y cierra. Siembra en una rama temporal un fallo para cada revisor, comprueba que cada uno detecta el suyo y borra la rama. Después pide al arquitecto el plan de una tarea de ejemplo y repite la comprobación de las herramientas instaladas.

La configuración base, de la fase 1 a la 9, tarda de 15 a 20 minutos en un proyecto pequeño. En la ejecución medida tardó 14: 5 para reconocer el proyecto y proponer, 2 de espera hasta la respuesta y 7 para crear los archivos.

Con las cinco herramientas opcionales y las comprobaciones de la fase 11, la ejecución completa tardó 29 minutos. La diferencia tiene dos causas. gstack compila sus binarios y descarga su navegador, lo que lleva unos 5 minutos. La comprobación de los revisores lleva unos 8. Lanza los cuatro revisores sobre los fallos sembrados, y el de pruebas muta el código para ver si alguna prueba lo detecta.

En esa comprobación, cada revisor señaló el fallo sembrado para él, y el de seguridad confirmó la inyección ejecutándola. El revisor de pruebas demostró además que una prueba sembrada seguía en verde con la función rota.

El prompt se ejecutó una vez, y los fallos los siembra el propio agente que escribió los revisores. La comprobación demuestra que cada revisor se lanza, lee el cambio y responde con el formato pedido. No mide cuántos fallos encuentra en un proyecto real, ni los que el prompt no nombra.

En un proyecto de ejemplo en Node.js, con las cinco herramientas opcionales instaladas, el prompt dejó esta estructura. .claude/agents guarda los diez subagentes: los cuatro revisores y los seis agentes de trabajo. .claude/skills guarda dieciséis skills: las nueve del prompt, la de graphify y seis de Matt Pocock. Lo que se instala en su carpeta personal (archify, gstack y claude-council) aparece abajo, plegado, con su ruta en ~/.claude.

El prompt no toca el código de la aplicación. Si la configuración requiere instalar una dependencia, un plugin o un servidor MCP, el agente primero lo propone con su origen y su motivo. Después espera su confirmación.

Cómo comprobarlo. Las skills y los subagentes nuevos se registran al abrir la sesión, así que ciérrela y vuelva a abrirla. Entonces /revisar-cambio aparece al escribir /, y la lectura de .env devuelve el bloqueo. git status --porcelain muestra solo los archivos que el agente propuso en la fase 2.

3. Qué aporta cada pieza y de dónde sale

Sin esta configuración, el agente empieza cada sesión sin conocer las órdenes del proyecto y puede leer un .env sin preguntar. Además, revisa su trabajo con el mismo sesgo con el que lo escribió, y sus subagentes usan el modelo de la sesión (punto 1). Cada pieza del prompt resuelve uno de esos problemas:

• AGENTS.md fija los hechos del proyecto (las órdenes comprobadas, el vocabulario y las convenciones) para que el agente no tenga que deducirlos en cada sesión.
• La regla de secretos y los hooks convierten los límites en reglas que aplica el harness. La lectura de .env y las órdenes destructivas se bloquean aunque el modelo las intente.
• Las skills de método dan un procedimiento para cada tipo de tarea. Con ellas, el agente aclara antes de construir, ve fallar la prueba antes de escribir el código y busca la causa antes de arreglar. También reparte el trabajo con el número de agentes y el modelo adecuados.
• Los revisores reparten la revisión en cuatro preguntas, cada una en un contexto propio y sin el razonamiento de quien escribió el cambio.
• Los agentes de trabajo reciben piezas acotadas de una tarea grande, cada una con el nivel de modelo que necesita.

Las ideas vienen de nueve fuentes públicas:

1. La guía de auditoría de Cloudflare² da el método del revisor-seguridad: evidencia en el código, una reproducción segura y el arreglo más pequeño. También da su escala de gravedad y sus nueve listas por dominio.
2. El revisor de seguridad de Anthropic³ aporta la lista de categorías que el revisor-seguridad no reporta, como la denegación de servicio, porque casi siempre son ruido.
3. Las skills de Trail of Bits⁸ revisan solo lo que introduce el cambio y a quién afecta. Además, comprueban cada sospecha para descartar falsos positivos y mutan el código para medir las pruebas. Esas tres ideas están en el contrato común de los revisores y en el revisor-pruebas.
4. Los plugins oficiales pr-review-toolkit y feature-dev de Anthropic⁹ traen revisores de fallos silenciosos, diseño de tipos y cobertura de pruebas. También traen agentes que exploran el código y diseñan antes de implementar. De ellos salen el revisor-errores-y-tipos, la puntuación de lo que las pruebas no cubren en el revisor-pruebas, el explorador y el arquitecto.
5. ECC⁴ tiene agentes de trabajo acotados: uno arregla la compilación con el cambio mínimo, otro limpia el código muerto y otro pone al día la documentación. Son el resolutor-compilacion, el limpiador y el documentador.
6. La guía de revisión de Google⁵ dice qué mirar en una revisión y pide leer cada línea. De ella salen la pregunta y la lista de categorías del revisor-calidad.
7. Superpowers¹⁰ aporta tres hábitos: ver fallar la prueba primero, buscar la causa raíz y parar tras tres arreglos fallidos, y no afirmar nada sin la orden que lo demuestra. También elige el modelo más barato que pueda hacer cada tarea, porque el número de turnos influye más en el coste que el precio por token. Está en pruebas-primero, depurar, el final de AGENTS.md y los niveles de orquestar.
8. Las skills de Matt Pocock¹¹ le hacen preguntas antes de construir y comprueban si el cambio hace lo pedido. También resuelven los conflictos de fusión según la intención de cada lado. De ahí salen aclarar, el apartado «Lo pedido» del revisor-calidad y la regla de fusión de orquestar.
9. gstack¹² reutiliza lo que existe antes de escribir código nuevo y avisa antes de una orden destructiva. Además, trata el acuerdo entre dos modelos como un indicio, y la decisión sigue siendo suya. Está en el implementador, en el hook de órdenes destructivas y en el uso de claude-council.

De las fuentes con licencia CC BY-SA solo se toman ideas; el texto es propio.

4. Qué herramientas opcionales propone el prompt

Además de lo que crea, el prompt propone tres herramientas y dos colecciones de skills, todas opcionales.

graphify convierte el repositorio en un grafo de conocimiento: qué función llama a cuál, qué módulo importa a cuál y qué archivos forman un subsistema. El agente lo consulta antes de abrir archivos uno por uno, por ejemplo para encontrar todo lo que usa una función antes de cambiar su firma.

graphify analiza el código en local con tree-sitter, un analizador de sintaxis, sin modelo de lenguaje. En cambio, la documentación, los PDF y las imágenes sí se envían al modelo del agente. Construir el grafo desde la terminal, con graphify update ., no envía nada fuera de la máquina¹³.

claude-council es un plugin de terceros para Claude Code que hace la misma pregunta a varios modelos. Muestra las respuestas una junto a otra, con una síntesis de acuerdos y desacuerdos. Sirve para decisiones de diseño en las que el sesgo de un solo modelo puede llevar a error, como elegir entre dos estructuras de datos.

Con proveedores por API, como OpenAI, Gemini o Grok, el plugin envía a esos terceros la pregunta. También les envía hasta cinco archivos del proyecto que añade por su cuenta. El modo --local, con subagentes de Claude, y el modo ollama no envían nada fuera de la máquina¹⁴.

archify es una skill con un programa de línea de órdenes en Node.js. Convierte una descripción o un repositorio en un diagrama interactivo, en un único archivo HTML autónomo. Hay cinco tipos: arquitectura, flujo de trabajo, secuencia, flujo de datos y ciclo de vida.

archify sirve para ver cómo se conectan las piezas de un proyecto, incluido el código que escribió el agente, y valida el diagrama antes de entregarlo. No envía datos del proyecto. Cada unas 72 horas hace una comprobación opcional de versiones nuevas, en la que el servidor solo ve la IP y la hora¹⁵.

Las skills de Matt Pocock, mattpocock-skills¹¹, le hacen preguntas antes de construir, aplican pruebas primero y depuran. También revisan un cambio contra los estándares del repositorio y contra lo que pedía la tarea. Sus skills tdd, diagnosing-bugs, code-review y grill-me se solapan con las del prompt. Al instalarlas, el prompt propone quedarse con una de cada par.

Son instrucciones en Markdown y no envían nada por sí mismas. Además aportan lo que el prompt no tiene. to-spec y to-tickets convierten una conversación en una especificación o en tareas. improve-codebase-architecture mejora la arquitectura del código existente, y handoff pasa el trabajo a otra sesión.

gstack¹² es un proceso de desarrollo completo con unas cuarenta skills para planificar, revisar, probar en un navegador, publicar y hacer retrospectivas. Se instala en su cuenta de usuario, fuera del proyecto, y necesita Bun. Su instalación compila un navegador propio y registra un hook en la configuración global, ~/.claude/settings.json.

En modo equipo, gstack añade otro hook, que descarga y reinstala la última versión al abrir cada sesión, como mucho una vez por hora. Por eso el prompt lo propone sin modo equipo y con la telemetría apagada. Tampoco importa las cookies del navegador, que darían al agente las sesiones que usted tiene iniciadas.

Cómo hacerlo. La fase 10 del prompt propone las tres herramientas y las dos colecciones una a una, y solo instala cada una si usted lo confirma.

5. Cómo trabajar con el entorno: una función nueva de principio a fin

Con el entorno configurado, el agente ya conoce las órdenes y las convenciones del proyecto, y tiene un procedimiento para cada paso. Este ejemplo sigue una función nueva en el proyecto de ejemplo, desde la petición hasta el commit.

La petición. Escriba /plan seguido de lo que quiere y de los requisitos que ya conoce. En modo plan, el agente lee, busca y ejecuta órdenes de exploración, pero no edita nada hasta que usted aprueba el plan¹⁶:

/plan Añadir descuentos a los pedidos. resumen() tiene que mostrar el importe final,
ningún total puede quedar por debajo de cero y el cambio lleva sus pruebas.

Qué hace el entorno con esa petición:

1. Parte de AGENTS.md. El agente ya sabe que las pruebas se lanzan con npm test, que los importes son céntimos enteros y que solo formatearPrecio los convierte en texto. No tiene que deducirlo del código.

2. Aclara antes de planificar. La petición deja decisiones abiertas, así que se activa aclarar. El agente busca en el código lo que puede averiguar y le pregunta el resto por rondas, con una recomendación en cada pregunta. En la ejecución del punto 2, ante una petición parecida, preguntó así:

   1. ¿Qué tipo de descuento? a) porcentaje, b) importe fijo en céntimos, c) los dos.
      Recomiendo b: es entero desde el principio y no obliga a decidir cómo redondear.
   3. ¿Qué pasa si el descuento es mayor que el total? a) se lanza un error, b) el neto queda en 0.
      Recomiendo a, por coherencia con el TypeError de formatearPrecio.

3. Diseña y reparte. Con las decisiones tomadas, orquestar decide si la tarea merece repartirse. Si lo merece, el arquitecto, con el modelo mayor, la divide en piezas que no comparten archivos. Cada pieza lleva su prueba, su orden de comprobación y su nivel de modelo. Antes de proponer código nuevo, busca lo que ya existe; aquí, formatearPrecio.

4. Usted aprueba el plan. El plan aparece como texto: puede aprobarlo, pedir que siga planificando o editarlo con Ctrl+G¹⁶. Un enfoque equivocado se corrige en ese texto, sin revertir archivos.

5. Implementa con la prueba primero. Cada pieza sigue pruebas-primero. Primero se escribe la prueba del comportamiento, por ejemplo que un descuento mayor que el total lanza un error. Se comprueba que falla, y después se escribe el código mínimo. Si hay piezas independientes, cada implementador trabaja en su propio árbol de trabajo. El agente principal las fusiona de una en una y ejecuta la suite después de cada fusión.

6. Los límites siguen activos. Si el agente intenta leer .env, editar package-lock.json o ejecutar git reset --hard, la regla de permisos y los hooks lo bloquean. No depende de que el modelo lo recuerde.

7. Revisa antes de confirmar. AGENTS.md pide ejecutar revisar-cambio antes de cada commit, y usted también puede lanzarla con /revisar-cambio. El revisor de calidad compara el cambio con el plan aprobado, y el de errores y tipos busca, por ejemplo, un descuento negativo que nadie valida. El de pruebas muta la lógica del descuento para ver si alguna prueba lo detecta.

8. Confirma. Si el veredicto sale limpio o solo con avisos, el agente confirma el cambio con el formato de commit del proyecto. Si algo bloquea, lo arregla y vuelve a revisarlo.

Las herramientas opcionales encajan en los mismos pasos. El explorador consulta graphify antes de abrir archivos, y archify dibuja el flujo si usted lo pide. claude-council sirve para una decisión dudosa, como porcentaje frente a importe fijo.

Qué gana el proyecto. Cada paso evita un tipo concreto de error:

• Una decisión que nadie tomó, como el tipo de descuento o qué pasa con los negativos, se pregunta antes de escribir código. Así no se descubre en la revisión.
• Una convención olvidada, como formatear un importe fuera de formatearPrecio, está escrita en AGENTS.md, y la comprueba el revisor de calidad.
• Una prueba que pasa por construcción no protege nada, así que pruebas-primero exige verla fallar y el revisor de pruebas muta el código para comprobarlo.
• Un fallo de seguridad lo revisa otro agente, en su propio contexto, que lo confirma ejecutándolo. No depende de que lo vea quien lo escribió.
• Un secreto o una orden destructiva no dependen de la atención de nadie, porque los bloquea el harness.

El punto 2 muestra el resultado de esa revisión sobre fallos sembrados.

Cómo hacerlo.

1. Escriba /plan seguido de la petición, o pulse Shift+Tab hasta el modo plan y escriba la petición.
2. Responda las preguntas de aclarar y apruebe el plan.
3. Durante la implementación, consulte /context para ver cuánto ocupa la conversación, y use /rewind para deshacer un paso que salió mal.
4. Antes de confirmar, ejecute /revisar-cambio si el agente no la ha lanzado ya.

Por dónde seguir

Revise lo que escriban los agentes con Ocho cosas que revisar en el código que genera la IA, que recoge ocho fallos de seguridad frecuentes con su corrección.

Para convertir los requisitos de seguridad en peticiones y en comprobaciones del compilador, el linter y las pruebas, lea cómo pedirle a la IA código seguro.

Referencias

1. Claude Code. Subagentsubicaciones, campos de la cabecera, orden en que se elige el modelo, contexto aislado e invocación con @agent.code.claude.com↩
2. Cloudflare. security-audit-skilllicencia MIT; exigencia de frontera y resultado, anclas de gravedad y verificación independiente.github.com↩
3. Anthropic. claude-code-security-reviewlicencia MIT; revisión de seguridad por cambio, umbral de confianza y reglas para descartar falsos positivos.github.com↩
4. Affaan Mustafa. ECClicencia MIT; agentes code-reviewer, security-reviewer, silent-failure-hunter y tdd-guide.github.com↩
5. Google. Engineering Practices: What to look for in a code reviewlicencia CC BY 3.0; diseño, complejidad, pruebas, nombres, comentarios, coherencia y salud del código.google.github.io↩
6. Claude Code. Run parallel sessions with worktreesaislamiento de subagentes con isolation: worktree y rama base por omisión.code.claude.com↩
7. Claude Code. Orchestrate subagents at scale with dynamic workflowsaviso a partir de 25 agentes y guía de tamaño de los workflows.code.claude.com↩
8. Trail of Bits. skillslicencia CC BY-SA 4.0; se toman ideas, no texto, de differential-review, fp-check y mutation-testing.github.com↩
9. Anthropic. claude-plugins-official, plugins pr-review-toolkit y feature-devlicencia Apache 2.0; revisión de código, fallos silenciosos, diseño de tipos, comentarios y cobertura de pruebas, exploración y diseño de una función nueva.github.com↩
10. Jesse Vincent. Superpowerslicencia MIT; pruebas primero, depuración sistemática, verificación antes de terminar y cómo recibir una revisión.github.com↩
11. Matt Pocock. Skills For Real Engineerslicencia MIT; commit c55ee46 del 18 de septiembre de 2026; catalogada como mattpocock-skills en el catálogo oficial de plugins; consultado el 26 de septiembre de 2026.github.com↩
12. Garry Tan. gstacklicencia MIT; versión 1.91.2.0; consultado el 26 de septiembre de 2026.github.com↩
13. Graphify Labs. graphifylicencia Apache 2.0; paquete de PyPI graphifyy, con dos "y", versión 0.9.69; consultado el 26 de septiembre de 2026.github.com↩
14. hex. claude-councillicencia MIT; versión 2026.9.15; consultado el 26 de septiembre de 2026.github.com↩
15. tt-a1i. archifylicencia MIT; última versión publicada v2.16.0; consultado el 26 de septiembre de 2026.github.com↩
16. Claude Code. Permission modesciclo de Shift+Tab, texto de la barra de estado y descripción de cada modo.code.claude.com↩