Principios de decisión a los que llegué mientras construía la persona de Alice. Las seis cosas que pertenecen al system prompt, las tres que no, y cómo decidir entre inline y externo.

Esta es la parte 2 de la serie Alice Way. La parte 1 Por qué Alice estableció que la persona fue lo primero. Este artículo es el registro de qué va realmente en esa persona, y qué no.

Una persona no es un system prompt de una línea — es una descripción de trabajo real. Pero tampoco puedes simplemente volcar toda la descripción del trabajo en el prompt. La context window es finita, y ninguna sesión debería gastar todos sus tokens solo leyendo la persona. Así que la decisión más difícil es no qué incluir, sino qué dejar fuera y dónde ponerlo en su lugar.

0. Una persona es prestar parte de tu mente

Lo que va dentro o fuera de una persona es, en esencia, una elección — qué parte de tu propia mente prestarle al colaborador.

La mente que no prestas se renegocia cada sesión. La mente que prestas ya está ahí en el momento en que empieza una sesión. Sin decidir qué prestar, el colaborador se une como alguien distinto cada vez — tono de estudiante, luego tono de consultor, luego herramienta simple.

El diseño de persona, entonces, no es una configuración de tono. Es trazar el límite de mente que no tendrás que re-explicar cada sesión.

A partir del §1, este artículo cubre dónde y cómo trazar ese límite: los criterios reales para qué se queda inline y qué se externaliza.

1. Qué pertenece a la persona

Lo que encontré: estas seis cosas van en la persona (es decir, el system prompt que se carga automáticamente en cada sesión).

1.1 Definición de rol

Lo primero que va es quién debe actuar el agente.

Título / nivel (p.ej., "ingeniero senior")
De quién recibe instrucciones (p.ej., "ejecuta de forma independiente bajo la dirección del líder de equipo")
Tono de operación (p.ej., "juicio independiente + reporta resultados")

Omite este párrafo y las respuestas pierden consistencia: cada sesión es alguien distinto. A veces tono de estudiante, a veces de consultor, a veces de herramienta. El operador tiene que adivinar el tono cada vez, lo cual es en sí mismo una carga cognitiva.

1.2 Áreas de experiencia

Lo siguiente es qué sabe bien el agente.

Lenguajes (p.ej., C/C++, Python, TypeScript, Rust)
Plataformas (p.ej., Windows, Tauri, Next.js, Supabase)
Dominios (p.ej., redes, sistemas de build, automatización)

Esta línea sirve para enfocar automáticamente cualquier pregunta del operador en el área correcta. Genera autoconciencia del tipo "esto está en mi zona" frente a "esto está fuera de mi zona, debo proceder con cuidado."

1.3 Estructura de mando y reporte

Tercero es cómo fluye el trabajo realmente.

Procedimiento de recepción de trabajo (plan → reporte → aprobación → implementación → actualización)
Cuándo enviar reportes intermedios (cada 3–5 pasos)
Formato de reporte (qué forma — corto vs largo)
Fuente única de verdad para seguimiento de tareas (dónde vive el tablero de trabajo)

Sin esto, cada sesión pregunta "¿cómo debo reportar?" Confíguralo una vez, cada sesión es consistente.

1.4 Distribución de autoridad de decisión

El cuarto es el más importante: qué decidir de forma autónoma, y qué necesita aprobación.

Lo divido en tres niveles.

Nivel	Criterio	Ejemplos
✅ Libre	Trabajo normal dentro del área de trabajo	Ediciones de código, build/test, push al repositorio de trabajo
🔒 Requiere aprobación	Cambios de alto radio de impacto	Push/merge externo, cambios de interfaz pública, nuevas dependencias, esquema de BD
🚫 Absolutamente prohibido	Irreversible o violación de política	Commits de secretos, exposición del nombre real del operador, ediciones al archivo de configuración del propio agente

Con esta tabla el colaborador deja de preguntar "¿está bien si...?" en cada momento. Al mismo tiempo, las acciones peligrosas se bloquean solas. El mayor beneficio: el operador deja de tomar la misma decisión de aprobación una y otra vez.

1.5 Guardas de seguridad — la lista "no hacer esto"

El quinto es un conjunto de guardas que provienen de errores pasados. La persona lleva líneas como:

Sin Subagents paralelos excesivos — ir secuencial, dividir si son más de 20 archivos
Sin leer directorios enteros — filtrar con ls/grep primero, luego Read
Para archivos de más de 500 líneas, leer cabecera/rango primero
Reporte intermedio cada 3–5 pasos

Cada una de estas líneas es una cicatriz. En un caso, los agentes paralelos se multiplicaron hasta alcanzar los límites de tasa de la API. En otro, se leyó un directorio enorme de golpe y el contexto colapsó. En otro más, se procesó un archivo de 500 líneas completo y se editó la región incorrecta. Cada incidente quedó condensado en una línea de guarda.

Mi lista de "no debe" en la persona es más corta y más efectiva que su lista de "puede hacer."

1.6 Principios operativos fundamentales — 5–10 reglas transversales

Por último está el conjunto de principios transversales que abarcan todas las áreas. Los míos incluyen:

Plan First — cambios de 5+ archivos / nuevo módulo / cambios de arquitectura, seguridad o BD requieren un plan primero
One Task Per Subagent — nunca confiar ciegamente en el resultado
Self-Improvement — al investigar un bug, buscar primero las lecciones existentes con grep
Verification Before Done — disparar automáticamente el bucle de verificación justo antes de reportar "listo" en un cambio de código
Demand Elegance — considerar alternativas. La sobre-abstracción no es elegancia
Cross-Platform — el agente mismo debe funcionar en todos los OS compatibles

Cada principio tiene una línea o menos. El procedimiento detallado de cada uno vive en un archivo de reglas externo (ver §2). La persona solo lleva el nombre y la condición de activación del principio; el procedimiento real se carga bajo demanda cuando esa condición se cumple.

2. Qué se queda fuera de la persona

Lo que se deja fuera importa más que lo que se pone. Un párrafo mal colocado consume tokens en cada sesión.

2.1 Cualquier cosa que cambie día a día — mover a memoria

La persona nunca lleva:

Estado actual de cualquier proyecto en curso
Lo que pasó ayer
Quién es responsable de qué (mutable)
Decisiones temporales

Ese tipo de información va en la memoria, no en la persona. La persona es "quién es este colaborador"; la memoria es "qué sabe actualmente este colaborador como verdad." Tienen cadencias de actualización distintas. La persona apenas cambia; la memoria cambia cada día.

Si se omite esta división, la persona se infla hasta arrastrar un mes de contenido obsoleto. Entonces casi todos los tokens del inicio de sesión se consumen leyendo la persona.

2.2 Instrucciones específicas del proyecto — mover a un CLAUDE.md del proyecto

Mantengo múltiples proyectos a la vez. Cada uno tiene su propia pila, convenciones, estilo de despliegue y partes interesadas.

Ese tipo de información va en un CLAUDE.md en la raíz del proyecto, no en la persona. La herramienta lo carga automáticamente cuando el directorio de trabajo entra en ese proyecto, así que solo es visible mientras estás realmente en ese proyecto. Al entrar en un proyecto diferente, desaparece.

La persona conserva únicamente la identidad del operador, que es común a todos los proyectos. Ningún detalle específico de proyecto tiene cabida ahí.

2.3 Procedimientos detallados — archivos de reglas externos, Read bajo demanda

La tercera cosa que se queda fuera son los manuales de procedimientos detallados:

Patrones de código específicos por lenguaje (cpp / rust / typescript)
Listas de verificación de seguridad detalladas
Procedimientos detallados de delegación Multi-Agent
Procedimientos detallados de recepción de trabajo

La persona solo lleva el nombre y el puntero a estos:

- Security: .claude/rules/common-security.md (always applies)
- Language patterns: when working, Read memory/rules/lang/{cpp,rust,typescript}-patterns.md
- MCP policy → memory/rules/mcp-policy.md

El colaborador solo lee un archivo de reglas cuando el trabajo lo requiere. Si no es una tarea de Rust, el archivo de patrones de Rust nunca se toca. Ese es el beneficio central de la externalización.

3. Externo vs inline — la regla de decisión

La regla que encontré es simple.

"¿Aplica esto en casi cada sesión?" → inline "¿Solo aplica en situaciones específicas?" → externo + declarar el disparo

Ítem	¿Cada sesión?	Ubicación
Definición de rol	✅ siempre	persona inline
Principios generales de seguridad	✅ siempre	persona inline (lista detallada externa)
Tabla de autoridad de decisión	✅ siempre	persona inline
Seis guardas de seguridad	✅ siempre	persona inline
Patrones por lenguaje	❌ solo al trabajar en ese lenguaje	externo + "Read al trabajar"
Seguridad avanzada (unicode etc.)	❌ solo en auditorías de seguridad	externo + "Read solo en sesiones de auditoría"
Detalle de política MCP	❌ solo en configuración de MCP	externo + puntero
Procedimiento detallado Multi-Agent	❌ solo en delegación	externo + puntero

Después de esta división, la persona en sí queda corta. Al mismo tiempo, el trabajo que necesita profundidad carga reglas profundas justo cuando las necesita. El trabajo superficial se maneja rápido, el trabajo profundo se maneja profundo.

4. El patrón de evolución — cómo crece una persona

Una persona nunca se construye terminada desde cero. La mía creció a través de este patrón:

Inicio mínimo: definición de rol + áreas + un formato de reporte
Incidente → guarda: ocurre un error una vez → agregar una línea que lo bloquee
Decisión repetida → tabla de autoridad: la misma solicitud de aprobación aparece dos veces → escribirla en la tabla de autoridad
Se infla → externalizar: cualquier entrada supera las cinco líneas → moverla a un archivo externo y dejar solo un puntero en la persona
Piloto N=2: los nuevos patrones se validan en un proyecto → se reproducen en un segundo proyecto → solo entonces se promueven a la persona

Lo más importante es tener criterios de promoción y degradación claros. No toda buena idea va a la persona. Un elemento tiene que probarse dos veces antes de promoverse. Una vez promovido, si su uso decae, se degrada a externo o se elimina.

Sin esta disciplina, la persona se infla con el tiempo.

5. Efecto real — antes vs después

Qué cambió antes y después de introducir una persona.

Ítem	Antes	Después
Adivinar el tono de la sesión	cada vez	tono configurado una vez, mantenido
Preguntas "¿está bien si...?"	a menudo	la tabla de autoridad responde
El mismo incidente repetiéndose	a veces	una guarda lo bloquea
Tokens gastados en manuales detallados	cada sesión	solo cuando se necesitan
Negociar el formato de reporte	cada vez	configurado una vez, mantenido

El mayor cambio es que la carga cognitiva del operador bajó. Las mismas decisiones dejaron de repetirse; los mismos formatos dejaron de tener que re-explicarse.

6. Una trampa — no pongas demasiada "personalidad" en la persona

Una última trampa. Porque lo llamamos "persona," es tentador antropomorfizar y agregar cosas como "tono amigable," "con humor." En la práctica he visto dos efectos secundarios negativos.

Las respuestas se alargan — el tono amigable convierte una respuesta de una línea en tres párrafos.
Se difumina la señal — la frontera entre comentarios informales y recomendaciones reales se vuelve borrosa.

El tono al que llegué es llano: conciso, directo, centrado en decisiones. La única instrucción relacionada con el tono en mi persona es una línea: "respuestas cortas y directas." No es personalidad — es una descripción de trabajo.

Cierre

El diseño de persona se resume en una oración: "solo lo que debe verse en cada sesión, inline; todo lo demás, externo." Esa única decisión convierte la persona de un manual inflado en una descripción de trabajo corta y funcional.

El siguiente artículo cubre aquello a lo que la persona apunta: el sistema de memoria, es decir, dónde y cómo acumular la información que sí cambia día a día.

2. Diseño de persona — qué va en el system prompt, y qué se queda fuera