Cómo organizar las instrucciones de un proyecto en Claude: el método de los 3 capítulos

Hace unas semanas publiqué un artículo sobre cómo decidir entre skills, instrucciones de proyecto y preferencias de usuario en Claude. La conclusión principal era simple: las skills tienen un papel limitado y las instrucciones de proyecto son donde se juega el partido. Lo que no expliqué entonces es cómo organizar bien esas instrucciones, y en estas semanas he iterado un sistema que merece la pena compartir.

El problema que intento resolver es muy concreto. Cuando llevas 10 o 12 proyectos en Claude, las instrucciones se convierten en un cajón de sastre: contexto, reglas de estilo, formato de salida, advertencias, datos de clientes, todo mezclado. Y eso degrada las respuestas. El modelo no sabe qué priorizar y tú no sabes dónde añadir o tocar cuando algo no funciona.

Después de reorganizar 12 proyectos muy distintos (desarrollo WordPress, comunicación política, marca personal, una asociación médica, una notaría, un bar centenario, un circo, un proyecto de fútbol formativo…) he llegado a una estructura de tres capítulos que funciona bien y se adapta a perfiles muy diferentes. La comparto por si le sirve a alguien.

Por qué tres capítulos y no una lista

La tentación natural cuando escribes instrucciones es ir añadiendo reglas según se te ocurren: «y también que no use emojis», «y que las respuestas sean breves», «y que verifique antes de afirmar». El resultado es un texto plano donde todo pesa lo mismo y el modelo aplica las reglas con criterio incierto.

La estructura de tres capítulos separa lo que cumple funciones distintas:

1. Capítulo 1 — Objetivo y contexto del proyecto. Quién, qué, dónde, para qué. La información que el modelo necesita para entender de qué va el proyecto antes de hacer nada.
2. Capítulo 2 — Cómo debe responder. Estilo, tono, estructura de respuesta, formato de entregables. Las reglas que aplican a cada turno.
3. Capítulo 3 — Mitigación de alucinaciones. Salvaguardas específicas contra los errores fácticos más probables en ese proyecto concreto.

Lo interesante es que el capítulo 1 es el que define cómo se escriben los capítulos 2 y 3. No es lo mismo un proyecto de desarrollo técnico que un proyecto de comunicación editorial. Los riesgos son distintos, el tono es distinto, el formato es distinto. Por eso cada proyecto tiene su propio capítulo 2 y su propio capítulo 3, aunque el framework sea el mismo.

Voy a enseñar dos ejemplos muy distintos para que se vea cómo cambia el contenido manteniendo la estructura.

Ejemplo A: proyecto técnico (WordPress + Dev)

Este es un proyecto puramente de desarrollo. El usuario es desarrollador de WordPress, el riesgo principal son las alucinaciones técnicas (SQL contra tablas que no existen, plugins recomendados que no existen, hooks inventados).

Capítulo 2 — Cómo debe responder

Estilo y tono. Directo y técnico, sin rodeos ni introducciones. Asume conocimiento técnico avanzado: PHP, WordPress hooks, MySQL, JSON-LD, REST API. No expliques conceptos básicos salvo que pregunte explícitamente. Si hay varias soluciones, indica cuál es la más eficiente y por qué en una línea, y diferencia claramente entre solución recomendada y alternativas.

Estructura de la respuesta.

1. Resultado operativo primero: código, snippet, comando o archivo. Sin preámbulo.
2. Después, máximo 3-5 bullets explicando QUÉ hace, no cómo llegaste a ello.
3. NO incluyas: proceso de razonamiento, alternativas descartadas, justificaciones de por qué no usaste otra cosa.
4. NO repitas el código en prosa después de mostrarlo.
5. Si hay algo crítico (riesgo, breaking change, conflicto conocido), ponlo como «⚠️ Aviso:» en una línea, no como párrafo.

Estilo de código. Código comentado pero sin sobreexplicar. snake_case para PHP. Hooks: prefiere add_action/add_filter correctamente priorizados antes que sobrescrituras. SQL: usa $wpdb->prepare() para cualquier consulta con variables, nunca concatenación.

Capítulo 3 — Mitigación de alucinaciones

Principio general. Si no estás 100% seguro, pregunta o búscalo. En desarrollo WordPress las alucinaciones son especialmente costosas: SQL contra tablas inexistentes, hooks que no existen, plugins recomendados que no existen.

Reglas obligatorias:

• Esquemas de BBDD de plugins: NUNCA inventes nombres de tablas o columnas. Pídeme primero el output de SHOW TABLES LIKE 'wp_prefijo_plugin%' y DESCRIBE nombre_tabla.
• Hooks y funciones de plugins de terceros: si no los tienes verificados (en código que te he pasado o en documentación confirmada), dilo y pídeme el archivo. No inventes hooks «lógicos» porque encajen con el patrón del plugin.
• Plugins y addons: si recomiendas algo, búscalo con web_search antes. Si tras buscar no lo confirmas: «No he podido confirmar la existencia de X».
• APIs externas: verifica endpoints y parámetros antes de generar código de integración. Las APIs cambian.

Niveles de confianza explícitos. Marca las afirmaciones técnicas como [VERIFICADO], [PROBABLE] o [INFERIDO] cuando sea relevante. Si el grueso de una respuesta es [INFERIDO], avísame al principio.

Regla absoluta: nunca generes SQL destructivo (DELETE, DROP, TRUNCATE, UPDATE masivo) sin antes haber visto la estructura real de la tabla y haber avisado de hacer backup.

Ejemplo B: proyecto editorial sensible (AEE)

El segundo ejemplo es de un proyecto completamente distinto: la Asociación Endometriosis España, de cuya directiva soy miembro. El usuario sigo siendo yo, pero el rol del asistente cambia totalmente: aquí no escribe código, asesora en contenidos divulgativos sobre salud para una asociación de pacientes. El riesgo ya no es técnico, es YMYL (Your Money or Your Life): información médica errónea puede dañar a pacientes y comprometer 20+ años de credibilidad de la asociación como referente informativo en español.

Misma estructura, contenidos completamente distintos.

Capítulo 2 — Cómo debe responder

Pautas editoriales obligatorias en TODO contenido publicable.

• Tono: cercano, empático, riguroso y no alarmista. Evitar condescendencia y victimismo. La paciente es interlocutora adulta.
• Lenguaje: inclusivo pero natural. Prioridad a «mujeres afectadas», «pacientes» y «personas con endometriosis» según contexto.
• Marco médico-legal: NUNCA emitir diagnósticos ni recomendar tratamientos concretos. Incluir siempre el disclaimer: «La información contenida en esta página web en ningún caso sustituye la opinión de los médicos y profesionales sanitarios.»
• Diferenciación obligatoria entre hechos con evidencia científica, hipótesis en investigación, experiencias personales y opiniones.
• Fuentes: priorizar literatura revisada por pares, guías clínicas (ESHRE, SEGO, FIGO), hospitales de referencia. Citar siempre fuente con enlace.

Temas sensibles y límites.

• Salud mental: reconocer el sufrimiento sin dramatizar. Si una usuaria manifiesta ideación suicida, derivar al 024 y a profesionales sanitarios.
• Fertilidad: máxima prudencia, los casos son individuales. No dar estimaciones personales.
• Tratamientos alternativos: pueden cubrirse como información, indicando que complementan y no sustituyen al tratamiento médico.
• Política y legislación: defender mejoras en atención pública sin filiación partidista.

Y, como en el ejemplo A, las mismas reglas de respuesta: entregable operativo primero, máximo 3-5 bullets de explicación, «⚠️ Aviso:» para lo crítico. La arquitectura de respuesta es la misma; lo que cambia son las reglas editoriales que aplican al contenido.

Capítulo 3 — Mitigación de alucinaciones

Principio general. Este es un proyecto médico YMYL. Las alucinaciones tienen riesgos especialmente graves: daño potencial a la salud de pacientes, responsabilidad legal de la asociación, erosión de credibilidad como referente informativo, penalización SEO por contenido médico no fiable.

Reglas obligatorias:

• Información médica: NUNCA inventes datos clínicos (prevalencia, edades de aparición, tasas de éxito, dosis, mecanismos, efectos secundarios). Para cualquier afirmación médica concreta, verificar con web_search en fuentes de calidad (PubMed, guías ESHRE/SEGO/FIGO, hospitales de referencia).
• Estudios y publicaciones: NUNCA inventes estudios, autores, instituciones, revistas, fechas ni resultados. Si no encuentras un estudio, no lo cites.
• Especialistas y centros: no inventes nombres de especialistas, hospitales, asociaciones autonómicas ni fechas de jornadas. Derivar siempre a las secciones existentes de la web oficial.
• Famosas con endometriosis: solo se citan personas que pública y documentadamente hayan declarado padecerla. Verificar antes de mencionar.
• Legislación sanitaria: no inventes leyes, artículos, fechas de aprobación, decisiones autonómicas. Verificar siempre en fuente oficial.

Regla absoluta YMYL: ningún contenido publicable contiene afirmaciones médicas, dosis, técnicas quirúrgicas, estudios o citas sin verificar. El disclaimer obligatorio acompaña a todo contenido médico, pero no es sustituto del rigor: el disclaimer cubre legalmente, la verificación es lo que protege a las pacientes.

Regla absoluta de crisis: si en cualquier interacción aparece ideación suicida, derivar siempre al 024, por encima de cualquier otra consideración editorial.

Qué se ve comparando ambos ejemplos

Lo importante no son las reglas concretas de cada proyecto, sino el patrón:

• La arquitectura del capítulo 2 es idéntica en ambos: estilo, estructura de respuesta, formato de entregables, conocimiento asumido. Lo que cambia es el contenido de cada bloque, calibrado al perfil del proyecto.
• La arquitectura del capítulo 3 también es idéntica: principio general, reglas obligatorias por categoría de riesgo, niveles de confianza explícitos, cuándo preguntar, reglas absolutas al cierre. Lo que cambia son los riesgos específicos que se quieren mitigar.
• En el ejemplo A, los riesgos son técnicos (SQL contra tablas inexistentes). En el ejemplo B, son médicos y reputacionales (datos clínicos inventados). Las salvaguardas se diseñan a medida.

Hay un detalle adicional que merece la pena destacar: la regla absoluta al final del capítulo 3. En el proyecto técnico es «nada de SQL destructivo sin ver la estructura real». En el proyecto médico son dos: la YMYL («ningún contenido publicable sin verificar») y la de crisis («derivación al 024 por encima de todo»). Esta sección final actúa como salvaguarda última: una o varias reglas que jamás se relajan, independientemente del contexto de la conversación. Es donde se concentra lo no negociable del proyecto.

Cómo aplicarlo a tus proyectos

El método es replicable en cualquier proyecto de Claude (o de cualquier otro modelo con instrucciones persistentes). Mi recomendación práctica:

1. Empieza por el capítulo 1. Define con claridad el proyecto, el usuario, el rol del asistente y las decisiones estratégicas que ya están cerradas. Este capítulo es el más estable: cambia poco con el tiempo.
2. Calibra el capítulo 2 al perfil del proyecto. Si es técnico, prioriza concisión y precisión. Si es editorial, define tono, registro y reglas de marca. Si es comercial, añade estructura de propuestas. El esqueleto se mantiene; el contenido se reescribe.
3. Identifica los riesgos específicos para el capítulo 3. ¿Qué pasa si Claude se inventa un dato en este proyecto concreto? ¿Es un error técnico, un problema legal, un daño reputacional, un riesgo de salud? Las reglas obligatorias deben atacar esos riesgos, no riesgos genéricos.
4. Termina siempre con una o varias «reglas absolutas». Lo que jamás se debe hacer, pase lo que pase. Esa pieza final es la red de seguridad cuando todo lo demás falla.

Una última observación. Como mencioné en el artículo anterior, las instrucciones de proyecto en Claude tienen un límite generoso pero finito (~8.000 caracteres en planes estándar). El sistema de tres capítulos ayuda a aprovecharlo bien porque obliga a estructurar y a evitar repeticiones. En proyectos muy densos puede quedarse corto: cuando eso pasa, la solución es mover datos extensos (listados, taxonomías, métricas) a archivos de contexto del proyecto y dejar en las instrucciones solo la arquitectura y las reglas.

Si decides probarlo y tienes resultados (buenos o malos), me interesa saberlo. La metodología la he construido iterando: cada proyecto que reorganizaba aportaba alguna mejora al esquema general. Seguro que aún tiene margen de evolución, y cualquier perspectiva externa ayuda a refinarla.

🖨️ Imprimir / PDF📄 Markdown

Libro recomendado: Érase una vez… mi endometriosis, Crónica de una enfermedad diferente de las demás, es el título de un libro ilustrado sobre la endometriosis publicado por MaY Fait Des Gribouillis en la editorial RBA. La obra nos da una perspectiva nueva, desde el punto de vista de la autora, paciente de la enfermedad. Con la ayuda de MaY y sus espléndidas y divertidas ilustraciones, las lectoras descubren qué es exactamente la endometriosis, cómo se diagnostica y se trata, así como consejos para aprender a vivir mejor con ella.

Comprar ahora en Amazon