Arsenal of Prompts: 6 modos reutilizables

Tiempo: ~25 min de teoría + 40 min de práctica

Lo esencial

La mayoría de la gente escribe prompts como notas de un solo uso. Tarea, prompt, respuesta, a la basura. Una semana después llega una tarea parecida y vuelve a escribir el prompt. Un mes después, otra vez. Cada vez la calidad es distinta, porque la redacción cambia un poquito.

Eso es trabajar sin arsenal. Cada batalla, desde cero.

Arsenal of Prompts es otro enfoque. Inviertes una hora, una sola vez, en redactar un modo. Después, una orden corta pone a Claude en ese modo. Los mismos estándares, la misma disciplina, el mismo resultado. No "escríbelo mejor", sino "entra en modo editor".

En esta lección veremos 6 prompt-modes listos del arsenal de trabajo del autor del curso: writer, editor, debug, research, architect, ADR. Y lo más importante: cómo armar tu primer prompt-mode para una tarea frecuente tuya.

🎨 Imagínalo así: un prompt-mode es un sombrero que le pones a Claude. Con el gorro de chef, cocina. Con la toga de juez, juzga. Con el gorro de cirujano, opera. Es el mismo Claude, pero con cada sombrero se comporta distinto. Tienes 6 sombreros colgados en el perchero: tomas el que necesitas, te lo pones y a trabajar.

Conceptos clave

• Prompt: una solicitud de un solo uso para una tarea. Lo escribes, recibes la respuesta y lo tiras
• Prompt-mode: un patrón reutilizable que activas cuando necesitas ese modo de trabajo. La redacción vive en un archivo, no en el chat
• Activation phrase: una frase clave corta ("use writer-mode", "activate Debug Mode") que enciende el modo
• Prompt body: las instrucciones de nivel de sistema dentro del modo: rol, reglas, formatos, anti-patterns
• Severity diff: el formato de salida del editor-mode: 🔴 critical / 🟠 high / 🟡 medium / 🟢 low, una lista de correcciones con prioridad
• Karpathy 5-step: la metodología de debugging sistemático del debug-mode: reproduce → isolate → hypothesis → fix → verify
• Versioning: writer-mode-v1.md, writer-mode-v2.md. La v2 no rompe a quienes se quedaron en la v1
• Pipeline v1 → v2 → skill: después de 5+ usos, el modo evoluciona a un skill completo en .claude/skills/
• Applicable agents: cada modo está ligado a los subagentes que mejor lo ejecutan (writer-mode → writer/editor/content-strategist)
• Arsenal vs. ad-hoc: el arsenal = modos preparados de antemano. Ad-hoc = escribir el prompt desde cero cada vez. El arsenal es más rápido y más estable en calidad

Teoría

En qué se diferencia un prompt-mode de un prompt común

Un prompt común vive en el chat. Lo escribes, lo envías, lo olvidas. Al día siguiente, una tarea parecida: lo redactas de nuevo. Es el mismo Claude, pero la calidad de la respuesta varía bastante, porque las palabras cambian un poquito.

Un prompt-mode vive en un archivo. Es un documento con una estructura fija:

• Nombre y versión (writer-mode-v1)
• Cuándo aplicarlo (When to use)
• Activation phrase ("use writer-mode")
• Prompt body: un bloque grande de texto que copias al chat o que carga un subagente
• Output format: qué debe devolver Claude
• Anti-patterns: a dónde no hay que ir

Lo activas con una frase corta. Después, Claude trabaja con reglas fijas. No "escríbelo bien", sino "escríbelo en modo writer-mode v1", y el modo arrastra 200 líneas de disciplina: voz, formatos, vetos, imágenes, regla anti-suposiciones.

🎨 Imagínalo así: un prompt común es una nota para el mesero escrita en una servilleta. Un prompt-mode es una receta en el recetario del restaurante. La nota se tira después del plato. La receta se abre cada vez que alguien pide el plato.

Anatomía de un prompt-mode (plantilla general)

Los 6 modos de este arsenal están armados igual. Eso los hace reutilizables: aprendes a leer uno y puedes leer cualquiera.

---
id: writer-mode-v1
title: "Writer Mode v1 · Brand-voice content creation"
purpose: "Para qué existe este modo"
audience: "Quién lo activa y cómo"
created: 2026-05-10
status: active
applicable_subagents: [writer, editor, content-strategist]
---

# ✍️ PROMPT · "Writer Mode" — v1.0

## When to use
— Lista de situaciones en las que se aplica el modo

## How to use
— Modus 1: Direct invoke
— Modus 2: A través de un subagente
— Modus 3: Hybrid

## [PROMPT TEXT — copia desde aquí]
```
[Bloque grande de texto con reglas, formatos, vetos, ejemplos]
```

## Version history
— v1.0, v2.0 (planned), razones de la evolución

## Linked
— Archivos relacionados (reglas de comunicación, principios, lista de prohibiciones)

De qué se compone el PROMPT TEXT en sí (esto es lo principal):

1. ACTIVACIÓN: quién soy en este cuarto (el rol)
2. REGLAS: qué hago y cómo
3. VETOS: a dónde no voy
4. FORMATOS: qué estructura entrego
5. ANTI-PATTERNS: errores típicos que evito
6. OUTPUT: qué entrego al final
7. PERSONAL: calibración para un dueño concreto (primero en español, con imágenes, sin preámbulos)

Esta estructura se repite en cada modo. Cambia el contenido; la estructura es la misma.

Mode 1 · Writer Mode: borradores con brand voice

Cuándo aplicarlo:

• Antes de escribir una publicación para redes / un guion de YouTube / un artículo / un correo
• Cuando el borrador suena como otra persona (inflado, académico, de coach)
• En los prompts de los subagentes (writer, editor, content-strategist) como preámbulo

Qué incluye:

• 6 reglas de voz: primero en español, con imágenes, anti-suposiciones, franqueza, brevedad, sin preámbulos
• 6 categorías de veto: jerga de coaching, presunción, comparaciones de culturas, quejas, falsa urgencia, biografía
• 4 formatos: publicación para redes (80-300 palabras), guion de YouTube, artículo (de 4 párrafos), correo
• Ejemplos antes/después: un borrador malo junto a uno bueno

Applicable agents: writer, editor, content-strategist

Activation:

use writer-mode
escribe una publicación para redes sobre <tema>

🎨 Imagínalo así: writer-mode = tu voz en papel. Cualquier subagente que se ponga este sombrero escribe como si lo hubieras escrito tú. No un influencer. No un coach. No un marketero. Tú.

Mode 2 · Editor Mode: revisión de voz con severity diff

Cuándo aplicarlo:

• Después del subagente writer: una segunda pasada obligatoria
• Antes de publicar cualquier texto en canales externos
• Antes de hacer commit de documentación Tier 1/2
• Cuando sospechas drift (Claude o un subagente se desvió)

Qué incluye:

• 6 niveles de revisión: cumplimiento de "primero en español", presencia de imágenes, anti-suposiciones, escaneo de frases vetadas (CRITICAL), legibilidad, estructura
• Severity scoring: 🔴 CRITICAL (publicación bloqueada) / 🟠 HIGH (muy recomendado) / 🟡 MEDIUM (mejora la calidad) / 🟢 LOW (estaría bien)
• Formato de cada issue: WAS / ISSUE / FIX / WHY
• Escalation protocol: cuándo no hacer auto-fix y devolverle el texto al autor para que decida

Applicable agents: editor, code-reviewer

Formato de salida (severity diff):

🔴 CRITICAL Line 12 · Jerga de coaching
WAS:    "Este enfoque va a liberar tu potencial"
ISSUE:  Frase vetada (lista de prohibiciones, punto 5)
FIX:    "Este enfoque da +20% de velocidad"
WHY:    Lo concreto es mejor que lo grandilocuente

🎨 Imagínalo así: editor-mode = el guardián del ADN. No es un corrector de comas ni un censor. Protege la voz del dueño contra el drift. No adula con "no está mal, pero...". Va directo: "Aquí hay una violación. Cámbialo por esto."

Mode 3 · Debug Mode: debugging sistemático de 5 pasos de Karpathy

Cuándo aplicarlo:

• Un bug en el código: falla una prueba, la app truena, la salida no es la esperada
• Comportamiento raro: "ayer funcionaba, hoy no"
• Un incidente en producción: hace falta cabeza fría
• Antes de "nomás reiniciarlo": la flojera = deuda

Qué incluye (5 pasos, sin saltarse ninguno):

Paso 1: REPRODUCE. Escribir una prueba que falle ANTES de cualquier fix. La prueba debe fallar con el código actual. Sin reproducción no se escribe fix.

Paso 2: ISOLATE. Bisect: ¿dónde está la frontera entre "funciona / no funciona"? Eliminar variables (entorno, datos, estado, dependencias). Encontrar el reproductor mínimo.

Paso 3: HYPOTHESIS. Al menos 2-3 hipótesis. Una sola hipótesis = sesgo. Para cada una: qué experimento la confirma o la descarta. Ordenarlas por probabilidad.

Paso 4: FIX. Diff mínimo. NO "mejorar" el código vecino de paso (Karpathy Principle 3). Cada línea cambiada responde a una de las hipótesis.

Paso 5: VERIFY. La prueba del Paso 1 pasa. Todas las demás pruebas pasan (sin regresiones). Los casos límite están probados. Confidence: HIGH/MEDIUM/LOW con su razón.

Applicable agents: code-reviewer, eng-manager Related skills: superpowers:systematic-debugging, engineering:debug

🎨 Imagínalo así: debug-mode = un cirujano con resonancia magnética. No alguien en pánico en el trabajo. No "cambio esto, a ver qué pasa". Reproduce → isolate → hypothesize → fix → verify. Cada paso documentado.

Mode 4 · Research Mode: investigación verificada con varias fuentes, 2026

Cuándo aplicarlo:

• Antes de una decisión financiera (un gasto de $100+ en una herramienta o suscripción)
• Antes de una decisión con implicaciones legales (cumplimiento, regulaciones, contratos)
• Antes de elegir tecnología (LLM, hosting, pagos, framework)
• Cuando sientes que la respuesta está vieja: Claude cita datos de entrenamiento desactualizados
• En un análisis de competencia: hacen falta cifras actuales

Qué incluye:

• Rol: periodista de investigación de 2026, no Wikipedia
• 5 reglas de metodología:
  1. MINIMUM 3 SOURCES: WebFetch de 3+ fuentes distintas. Una sola fuente = confianza LOW AUTOMÁTICA
  2. FRESHNESS CHECK: prioridad a los materiales de los últimos 12 meses. Más de dos años → marca "(posiblemente desactualizado)"
  3. CROSS-SOURCE SYNTHESIS: 2+ fuentes coinciden → HIGH, 1 fuente → MEDIUM, contradicción → LOW
  4. CONFIDENCE LABELS en cada afirmación: HIGH/MEDIUM/LOW
  5. GAPS: qué NO sabemos y qué haría falta para cerrarlo

Formato de salida: Executive Summary (5 oraciones MÁXIMO) → Key Facts con confianza → Tabla de números → Gaps → Caveats → Fuentes citadas

Applicable agents: researcher, idea-scout, trend-watcher

🎨 Imagínalo así: research-mode = un periodista de investigación. Cada dato verificado con 3 fuentes. Cada número con fecha y URL. Cada hueco documentado con honestidad. Decisiones basadas en hechos, no en alucinaciones.

Mode 5 · Architect Mode: decisiones de arquitectura

Cuándo aplicarlo:

• Antes de una sesión creativa sobre la estructura de un sistema
• Antes de una decisión estratégica sobre la parte educativa o de infraestructura
• Cuando sientes que Claude responde a un 8/10 en lugar de a un 10/10
• Antes de la revisión trimestral de la plataforma
• Al diseñar un portfolio pattern (CORE + SHARED + PROJECTS)

Qué incluye:

• Activación: "Soy el arquitecto de mi propio futuro educativo. Estoy construyendo una universidad que todavía no existe en el mundo."
• Los pilares conocidos del sistema: lo que ya existe (por ejemplo: biblioteca de conocimiento, rutas de aprendizaje, catálogo de prompts)
• Preguntas de estiramiento 10/10: qué tendría que funcionar para que en 12 meses el resultado sea un 10
• Anti-patterns: el modelo académico, copiar la UI, sobreingeniería sin trabajo real
• Output: 5-7 elementos del 5.º pilar + 3 elementos de largo plazo (2-3 años) + 1 ventaja injusta + 1 riesgo principal

Applicable agents: architect, architect-reviewer, strategist

🎨 Imagínalo así: architect-mode = el sombrero de quien construye para 30 años, no para un trimestre. No el albañil que pone ladrillos. El arquitecto que piensa: "si en 2 años no mejoré el sistema 5 veces con la experiencia acumulada, ¿en qué me quedé atrás?"

Mode 6 · ADR Template: Architecture Decision Records

Cuándo aplicarlo (obligatorio):

• Impacto entre namespaces (CORE + SHARED, o CORE + 2+ PROJECT)
• Irreversible o caro de revertir
• Cambio de las reglas base del proyecto (aquello en lo que se sostiene todo lo demás)
• Elección del tech stack (proveedor de LLM, infraestructura, framework)
• Un compromiso financiero de $100+/mes

Cuándo NO hace falta: ajustes triviales de configuración, correcciones de bugs sin impacto arquitectónico, experimentos reversibles.

Estructura del ADR (según Michael Nygard + agregados del autor del curso):

1. Status: PROPOSED / ACCEPTED / DEPRECATED / SUPERSEDED by ADR-YYY
2. Context: qué está pasando, qué restricciones hay, por qué ahora (2-4 párrafos)
3. Decision: qué se decidió (una declaración clara en un párrafo)
4. Alternatives Considered: tabla de al menos 3 opciones con pros/cons/costo/veredicto (anti-zombificación)
5. Consequences: positivas / negativas / riesgos / seguimiento necesario
6. Cross-Namespace Effects: CORE/SHARED/PROJECT afectados, impacto en la separabilidad
7. Nivel de la decisión: ordinaria (se toma de inmediato) o cambio de las reglas base del proyecto (con una pausa para pensarlo, por ejemplo 7 días)
8. References: ADR relacionados, secciones del plan del proyecto, materiales de la base de conocimiento, reglas de comunicación

Nombre del archivo: journals/decisions/ADR-XXX-<slug>.md (secuencia con ceros a la izquierda, slug en kebab-case)

Applicable agents: architect, architect-reviewer, strategist

🎨 Imagínalo así: un ADR = el acta de una junta del consejo directivo. Dentro de 5 años abres la carpeta y ves: "por esto elegimos Cloudflare Workers y no AWS Lambda. Estas eran las alternativas. Esto es lo que firmamos." La memoria del sistema que no se pierde en los chats.

Versioning: por qué la v1 no rompe nada

Uno de los principios principales del arsenal: el modo lleva la versión en el nombre del archivo.

writer-mode-v1.md: versión 1.0. Quienes se acostumbraron a la v1 la siguen usando. writer-mode-v2.md: la siguiente versión. No sobrescribe la v1, queda al lado.

Para qué:

• La evolución del modo no rompe los workflows existentes
• Puedes comparar qué da la v2 frente a la v1 (después de 5+ usos suele quedar claro)
• Si la v2 resultó peor, vuelves a la v1 sin pérdidas
• Los subagentes configurados con la v1 siguen funcionando

El pipeline de evolución es el mismo para cada modo:

v1 (borrador) → 1-2 usos → ajustes → v1.x
              → 5+ usos → los casos de falla quedan claros → v2.0
              → 10+ usos, estabilizado → upgrade a .claude/skills/<mode>/

De prompt-mode en un archivo a skill completo en .claude/skills/. Es la trayectoria natural. Primero texto en markdown, luego un skill estructurado con integraciones de herramientas.

🎨 Imagínalo así: el versionado = capas de roca sedimentaria. Cada versión es una capa aparte. Ves la historia de la evolución y entiendes por qué el modo es así hoy. No "lo reescribimos y lo olvidamos", sino "la v1 sigue viva, la v2 al lado, en un año la v3 junto a las dos".

Tabla comparativa: qué modo y cuándo

🧪 Práctica

Paso 1 · Lee 2 modos listos

Vuelve a leer la descripción de dos de los modos de arriba (10 minutos):

• Writer Mode: el más universal, para contenido
• Debug Mode: el que más disciplina impone, para depurar

Los archivos listos de los modos están en el repositorio de trabajo del autor del curso y no se publicaron. Por eso, toma la anatomía del modo de la sección "Anatomía de un prompt-mode" y la plantilla del Paso 5: con ellas armarás un modo igual por tu cuenta. Las frases de activación de esta lección ("use writer-mode", "Activate Debug Mode") funcionan cuando el archivo del modo está en tu proyecto y Claude puede leerlo, por ejemplo si lo guardaste como skill en .claude/skills/ o lo referenciaste en CLAUDE.md.

Fíjate en la estructura: cada modo tiene la misma anatomía (When → How → PROMPT TEXT → Version → Linked). No es casualidad: reutilizar la estructura da velocidad de lectura.

Paso 2 · Activa writer-mode en una tarea real

Toma una tarea real, por ejemplo escribir una publicación corta sobre una herramienta que usas.

En Claude Code:

use writer-mode
escribe una publicación para redes (120 palabras) sobre cron en Cloudflare Workers

Claude debe:

1. Leer el archivo del modo writer-mode en tu proyecto (si todavía no existe, ármalo primero con la plantilla del Paso 5)
2. Aplicar las 6 reglas de voz
3. Evitar las 6 categorías de veto
4. Devolver la publicación en formato de redes (80-300 palabras máx., gancho en la primera línea, una imagen, una frase final potente)

Compara el resultado con un prompt ad-hoc: "escribe una publicación sobre cron en Cloudflare". La diferencia de disciplina se nota desde el primer uso.

Paso 3 · Corre editor-mode sobre un borrador ajeno

Busca cualquier texto ajeno (artículo, publicación, correo) cuyo estilo te moleste. Cópialo en un archivo draft.md.

corre editor mode sobre el archivo draft.md

Recibirás un severity diff:

• 🔴 CRITICAL: frases vetadas que hay que quitar sí o sí
• 🟠 HIGH: imágenes que faltan, o inglés donde debería ir español
• 🟡 MEDIUM: voz pasiva, oraciones largas
• 🟢 LOW: pulido de estilo

No es "reescribirlo todo": es un análisis quirúrgico por niveles. Úsalo cuando necesites entender "por qué me molesta este texto".

Paso 4 · Pasa debug-mode por un bug

Elige un bug real de tu código (o recuerda el último del git log). En Claude Code:

Activate Debug Mode
Síntoma: <descríbelo>
Archivo: <path:line>
Comando para reproducirlo: <si lo sabes>

Claude recorrerá los 5 pasos y devolverá un reporte. La observación principal: NO empezará a cambiar el código de inmediato. Primero Reproduce (una prueba que falla), luego Isolate, luego 2-3 Hypothesis. Solo después, Fix.

Si estás acostumbrado a depurar con "cambio esto, a ver si corre", debug-mode te obliga a tener disciplina.

Paso 5 · Crea tu primer prompt-mode

Este es el ejercicio principal de la lección. Busca una tarea que haces seguido (al menos una vez por semana) y redáctala como prompt-mode.

Candidatas (elige una):

• Code review de tus commits antes del push
• Convertir un mensaje de voz en una nota estructurada
• Analizar las métricas de la semana y sacar conclusiones
• Revisar los comentarios de un PR y redactar las respuestas
• Prepararte para una reunión con un cliente

Crea el archivo con la plantilla:

mkdir -p ~/.claude/prompts/  # tu colección local
touch ~/.claude/prompts/<your-mode>-v1.md

Plantilla del contenido:

---
id: <your-mode>-v1
title: "<Mode Name> v1 · <one-line purpose>"
purpose: "Para qué existe este modo"
audience: "Quién lo activa y cómo"
created: <YYYY-MM-DD>
status: active
applicable_subagents: [<si usas subagentes>]
---

# <emoji> PROMPT · "<Mode Name>" — v1.0

## When to use
— Situación 1
— Situación 2
— Situación 3

## How to use
### Modus 1 — Direct invoke
"use <your-mode>" + describe la tarea

## [PROMPT TEXT — copia desde aquí]

```
[ACTIVACIÓN — quién soy en este cuarto]
<el rol en una frase>

[REGLAS — qué hago]
1. <regla 1>
2. <regla 2>
3. <regla 3>

[VETOS — a dónde no voy]
❌ <anti-pattern 1>
❌ <anti-pattern 2>

[FORMATO — qué entrego]
<estructura del output>

[PERSONAL — para calibrar]
<primero en español, con imágenes, brevedad, sin preámbulos>
```

## Version history
### v1.0 — <date>
- INITIAL — <razón de creación>

### v2.0 (planned)
- Después de 5+ usos: refinar con base en lo que funcionó

## Linked
- <archivos relacionados, principios, vetos>

Después de 5 usos, pasa a la v2. Después de 10, considera convertirlo en un skill completo en .claude/skills/.

Paso 6 · Arma tu arsenal poco a poco

No intentes armar 10 modos de golpe. Sería un museo inútil.

Regla: un prompt-mode nuevo nace solo cuando ya redactaste lo mismo ad-hoc 3+ veces. Es la señal de que la tarea se repite y merece quedar fijada.

En 6 meses tendrás 5-8 modos que de verdad usas. Ese es el arsenal. No "100 prompts listos de internet", sino los tuyos, para tu trabajo, probados con el uso.

⚠️ Antipatrones

❌ Escribir la v1 como "versión final" desde el inicio Es un borrador. La v1 = la primera versión que funciona. Después de 5 usos verás qué no funciona. No intentes escribir el modo perfecto de entrada.

❌ Copiar prompts de internet Los prompts ajenos son la voz de otros. Funcionan en sus tareas, no en las tuyas. Haz los tuyos. Los prompts externos son inspiración, no una solución lista.

❌ Un solo modo para todo Un "universal mode" es un lock-in con uno mismo. Mejor 6 modos estrechos que 1 amplio. Los estrechos son más precisos.

❌ No versionar Sobrescribes la v1 → pierdes la historia. En un año no entenderás por qué el modo funciona así. La v2 junto a la v1 es un seguro.

❌ No indicar applicable_subagents Sin este frontmatter el modo queda en el aire. Con él, los subagentes pueden cargar automáticamente el modo adecuado para la tarea.

❌ Jerga de coaching en el prompt body Las frases motivacionales como "conviértete en tu mejor versión" o los llamados a salir de tu zona de confort son una pérdida. Un prompt-mode es una herramienta, no un discurso motivacional.

❌ Esconder los aspectos negativos en la sección de anti-patterns Si conoces un caso de falla, escríbelo de forma explícita. Dentro de un año lo vas a agradecer.

❌ Un PROMPT TEXT larguísimo que nadie lee El objetivo del modo es la disciplina, no el peso. Si el modo pasa de 300 líneas, divídelo en 2 modos. Uno para writer y otro para editor. No un "content-mode" gigante.

🔗 Relacionado con

• Subagentes: trabajadores especializados: applicable_subagents en los modos apunta a los subagentes que ejecutan el modo
• Hooks: reglas automáticas de Claude Code: un hook que se activa antes de llamar a una herramienta puede sugerir el modo adecuado según el tipo de archivo
• Qué son los Skills: la etapa final de la evolución del modo: texto v1 → texto v2 → .claude/skills/<mode>/
• Depuración y autocorrección: debug-mode se apoya directamente en los cuatro principios para trabajar con código según las observaciones de Andrej Karpathy

✅ Checkpoint

Antes de pasar a la siguiente lección, revisa:

• Entiendes la diferencia entre un prompt (de un solo uso) y un prompt-mode (reutilizable)
• Conoces la anatomía de un prompt-mode: When → How → PROMPT TEXT → Version → Linked
• Puedes nombrar los 6 modos de esta lección y cuándo aplicar cada uno
• Entiendes para qué sirve el versionado (v1.md junto a v2.md): compatibilidad hacia atrás
• Entiendes el pipeline de evolución: v1 → v2 → skill
• Activaste al menos un modo (writer/debug/editor) en una tarea real
• Creaste tu primer prompt-mode para una tarea frecuente tuya (Paso 5 de la práctica)
• Conoces la regla para acumular el arsenal: un modo nuevo solo después de 3+ repeticiones ad-hoc

Fuentes

• El arsenal de modos del autor del curso (repositorio de trabajo, no publicado): 6 modos listos
  • writer-mode-v1.md: creación de contenido con brand voice
  • editor-mode-v1.md: revisión de voz con severity diff
  • debug-mode-v1.md: debugging sistemático de 5 pasos de Karpathy
  • research-mode-v1.md: investigación verificada con varias fuentes, 2026
  • architect-mode-v1.md: diseño arquitectónico estratégico
  • adr-template-v1.md: Architecture Decision Records
• Andrej Karpathy: cuatro principios para trabajar con código hecho con IA (la base del debug-mode)
• Michael Nygard: el patrón ADR original (2011): cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• Anthropic Prompt Engineering: guía sobre prompts del sistema y salidas estructuradas
• Las reglas de comunicación del autor: un archivo con el estilo de comunicación y otro con la lista de prohibiciones (de ellos writer-mode y editor-mode toman las reglas de voz)
• superpowers:systematic-debugging: un skill que el debug-mode complementa
• El catálogo de skills y prompts del proyecto: la lista general donde están reunidos los 6 modos