3.1 arrancar-sesion

Documenta arrancar-sesion 4.1.0 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

arrancar-sesion prepara cada conversación de trabajo: averigua qué tipo de sesión es, carga solo el contexto que ese tipo necesita —mandando lectores en paralelo, uno por archivo, que traen hechos con cita— y te entrega una línea que dice qué cargó, en qué máquina estás y qué hay que vigilar.

Cuándo usarla y cuándo no

Úsala al empezar cualquier sesión. La disparan frases como «carga contexto», «arranca sesión», «retomemos» o «ponme al día», y la forma más precisa: declarar el tipo de sesión en tu primer mensaje.

A media sesión, para una sola fuente, dile «trae <fuente>» (detalle en el maestro, §3.1, «Trae…» a media sesión).

No escribe en tu entorno. Arrancar es leer. La única escritura posible es anotar la máquina en que estás, y solo si tú le das el nombre. Tampoco da de baja proyectos que lleven tiempo sin moverse: los señala y nada más.

No arranca sin tu carpeta maestra. Si no está conectada a la conversación, la pide; sin ella no sigue.

Los siete tipos de sesión

Los tipos 0 y D solo leen el núcleo y reportan; los demás, además, mandan cargadores, reconcilian lo que traen y luego reportan.

Cómo declarar el tipo

Escribe en tu primer mensaje la palabra Sesión seguida del tipo. La forma completa es:

Sesión <TIPO> · <dominio> · <proyecto> · <encomienda> · bitácora: <motivo>

Solo el tipo es obligatorio; lo demás es opcional y vale igual separado con · o dicho en prosa. Palabras que valen como tipo: PANORÁMICA, PROYECTO, ENCOMIENDA, MECÁNICA, META, COORDINACIÓN. Hay una más, DIRIGIDA: vale como ENCOMIENDA si nombras una encomienda que existe como archivo, y como PROYECTO si no.

Ejemplos (los nombres son inventados):

• Sesión PROYECTO · Comercial · Reporte semanal — trabaja ese proyecto.
• Sesión PROYECTO · Reporte semanal · bitácora: cambio de formato — además carga de la bitácora las entradas que toquen ese motivo.
• Sesión ENCOMIENDA · depurar-catalogo — ejecuta esa encomienda; la busca aunque no digas proyecto.
• Sesión COORDINACIÓN · Comercial — revisa el estado de los proyectos del dominio.
• Sesión META — para trabajar el entorno; este tipo solo existe si lo declaras.

Si no declaras

Infiere el tipo de lo que pides, probando en este orden y quedándose con el primero que aplique:

1. Nombras una encomienda que existe como archivo → C.
2. Nombras varios proyectos o encomiendas para gerenciarlos, no para ejecutarlos → F.
3. Nombras un proyecto → B.
4. Pides un panorama, tus pendientes o qué quedó abierto → A.
5. Pides una tarea mecánica sin memoria de proyecto → D.
6. No hay señal —un saludo, una pregunta sin objeto— → 0.

El tipo E nunca se infiere. Cuando el tipo salió inferido o por omisión, el reporte te sugiere declararlo la próxima vez con «Sesión <TIPO> · <proyecto>».

3.2 cerrar-sesion

Documenta cerrar-sesion 3.2.0 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

cerrar-sesion guarda lo que la sesión dejó: escribe un acta de lo ocurrido y se la entrega a tres escritores frescos que pasan el conocimiento nuevo al corpus, retiran de la bandeja lo que ya se usó y actualizan la bitácora y la memoria de cada proyecto, cada cosa en su nivel; al final te deja un título, un reporte breve y un sello de sesión cerrada.

Cuándo usarla y cuándo no

Úsala al terminar, con frases como «cierra la sesión» o «ya acabamos», o al despedirte. También se dispara sola cuando cambia un dato durable —tu perfil o el estado de un proyecto— a media sesión.

Corre en uno de tres modos:

No la uses para migrar un proyecto viejo a la forma vigente: eso es de arrancar-proyecto. El cierre escribe en el proyecto con la forma que tenga.

3.3 arrancar-proyecto

Documenta arrancar-proyecto 3.1.1 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

arrancar-proyecto convierte una idea de trabajo en un proyecto con objetivo claro: te entrevista hasta que el objetivo queda firme, crea la carpeta del proyecto, escribe su documento central (proyecto.md), lo anota en el índice de proyectos y deja lista su caja de instrucciones.

Cuándo usarla y cuándo no

Úsala cuando vas a empezar un trabajo que merece su propia carpeta y memoria. Dile algo como «arranca un proyecto», «nuevo proyecto» o «prepara esta carpeta».

No la uses para crear un dominio (una organización o área nueva, como tu empresa o lo Personal). Si se lo pides, te lo dice y te manda a pay-de-manzana («agrega un dominio»).

No arranca nada si no estás. Si la invocas en una tarea que corre sola, no inventa el objetivo: deja una encomienda con lo que juntó en la bandeja _Inbox/ del dominio y lo avisa. El objetivo siempre sale de ti.

3.4 capturar-conocimiento

Documenta capturar-conocimiento 2.2.1 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

capturar-conocimiento revisa lo que la sesión aprendió, se queda solo con lo que va a servir más allá del proyecto actual y lo escribe en el Corpus de Conocimiento del dominio, siguiendo las reglas que ese corpus declara en su SCHEMA.md; el agente escribe y tú curas y decides.

Cuándo usarla y cuándo no

Al cerrar la sesión la invoca cerrar-sesion, como candado del cierre: nada más se escribe hasta resolverla. No necesitas pedirla.

Suelta, a petición tuya: «destila la sesión», «pasa esto al corpus». También corre en caliente cuando el trabajo necesita enlazar una entidad nueva que aún no está en el corpus.

No escribe bitácora ni memoria de proyecto: esas son de cerrar-sesion. Solo escribe en el corpus.

No crea ni revisa tu perfil. Si algo de lo aprendido te describe a ti, no lo escribe en el corpus ni en tu perfil: lo deja como observación pendiente de que la confirmes.

3.5 generar-encomienda

Documenta generar-encomienda 3.0.1 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

generar-encomienda redacta una encomienda: el registro de un trabajo que no se puede hacer en este momento, escrito tan completo que cualquier sesión futura lo arranca sin que nadie le vuelva a explicar nada. La guarda en <Proyecto>/_Memoria/encomiendas/<slug>.md del proyecto dueño, o en la bandeja _Inbox/ del dominio si todavía no tiene proyecto. La redacta; no la ejecuta.

Cuándo usarla y cuándo no

Úsala cuando quieras dejar un trabajo encargado para después. Dile «hazme una encomienda» o «encola esto». También la usas para dos cosas más sobre una encomienda que ya existe: avanzar una en draft a listo (contestar sus preguntas pendientes) y re-pensar una desalineada (una que se quedó atrás porque cambió el objetivo).

No la uses para hacer el trabajo. Al crear la encomienda no la ejecuta: la deja lista en la cola para que otra sesión la tome.

Un tema a la vez. No abre varias encomiendas a la vez si no se lo pides, y respeta las preferencias de trato que tengas en _Memoria/perfil.md de tu carpeta maestra.

3.6 cuestionar-usuario

Documenta cuestionar-usuario 2.0.1 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

cuestionar-usuario te interroga sobre un plan, una idea o una decisión hasta que nada quede supuesto en silencio, y al final te entrega un acta de lo decidido, lista para pegar donde haga falta. No escribe archivos: el resultado es el entendimiento compartido en la conversación y el acta; quien la invocó decide dónde se coloca.

Cuándo usarla y cuándo no

Úsala antes de comprometerte con algo que todavía no está claro. Dile «cuestióname», «interrógame», «ponme a prueba esta idea» o «antes de arrancar, pregúntame».

No la uses para una duda suelta de ejecución (por ejemplo, «¿lo guardo en PDF o en Word?»). Esa se contesta y ya; esta skill es para un plan o una decisión completa.

También la llaman otras skills. Por ejemplo, generar-encomienda la invoca cuando a una encomienda le quedan tres o más preguntas abiertas después de la primera ronda. Sus dos salidas declaradas son generar-encomienda (para convertir lo decidido en un encargo) y capturar-conocimiento (para guardar lo que sirva a otros proyectos).

Lo que puede hacer mientras te interroga es leer y buscar en tus archivos y en la carpeta que tengas conectada, lanzar subagentes de búsqueda, consultar la web y hacerte preguntas con opciones para elegir. Son las únicas herramientas que declara; no edita nada.

3.7 maxwell

Documenta maxwell 3.0.1 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

maxwell audita un entregable contra el objetivo de su encargo antes de que llegue a ti: un revisor fresco —un subagente que no hizo el trabajo y que no altera nada— lo clasifica con un vocabulario fijo, y Maxwell reúne lo necesario, registra cada vuelta y te reporta. Solo deja pasar el trabajo que cumple su objetivo.

Cuándo usarla y cuándo no

Úsala al cerrar una encomienda, cuando quieras saber si algo ya está para entregarse, y siempre ante un trabajo largo o delicado. Dile «pásalo por Maxwell» o «¿ya está listo?».

No esperes que corrija. El revisor no altera nada, y Maxwell tampoco arregla: los hallazgos regresan a la sesión que hizo el trabajo para que los corrija ella.

No esperes un sí por cortesía. Si no se pudo probar algo, el dictamen lo dice (NO SE PUDO VERIFICAR); no lo da por bueno.

3.8 pay-de-manzana

Documenta pay-de-manzana 1.3.2 tal como viene en el paquete Pay de Manzana 1.3.1.

En una frase

pay-de-manzana lleva tu entorno Cowork a su forma vigente: en modo INTEGRAR lo monta de cero, le agrega un dominio, lo actualiza al paquete nuevo o repone lo que falte —y es el único modo que escribe—; en modo REVISAR hace exactamente el mismo análisis y te dice qué haría, sin tocar nada.

Cuándo usarla y cuándo no

Úsala con frases como estas:

También la puedes arrancar por su nombre. Si tu frase no deja claro el modo, te pregunta una sola vez: «¿solo reviso o también arreglo?».

Requisito: la carpeta maestra (la carpeta de tu entorno) tiene que estar conectada a la conversación, en los dos modos: para leer siempre y para escribir en INTEGRAR. Sin ella, te guía a conectarla y no arranca.

No la uses para:

• Instalar, actualizar o retirar skills. Pone al día tu entorno, no tus skills: eso siempre es paso tuyo en la app.
• Migrar el proyecto.md de un proyecto. Eso lo hace arrancar-proyecto, proyecto por proyecto; esta skill te da la línea para abrir esa sesión.
• Configurar la sincronización con Drive. No la configura; si algo de la sincronización estorba, trabaja local y te avisa. Trabajar sin sincronización es un estado válido.
• Revisar tu perfil en medio de otro trabajo. El módulo de perfil solo corre en un proceso dedicado a él (la alta, una migración o cuando lo pides expresamente), nunca dentro de una sesión con otro objetivo.

3.9 desarrollar-skills

Documenta desarrollar-skills 3.3.0 tal como viene en el paquete Pay de Manzana 1.3.1.

Para quién es este capítulo. desarrollar-skills es una skill de quien fabrica o ajusta el entorno, no del uso diario. La vas a ver trabajar cuando escribas una skill propia o corrijas una del paquete; si solo usas el entorno para tu trabajo, no la necesitas. El porqué de cada regla está en la vista «temas» y en el maestro.

En una frase

desarrollar-skills lleva una skill por todo su ciclo —diseño, borrador, congelamiento, entrega, instalación y registro— con compuertas que impiden escribir antes de que apruebes el diseño, numerar una versión antes de que digas «congélalo» y entregar un paquete que nadie más revisó.

Cuándo usarla y cuándo no

Úsala siempre que la sesión vaya a crear, editar, revisar, versionar, empacar o auditar una skill, aunque el encargo no lo pida. Se carga junto con skill-creator. Basta con decir algo como «hagamos una skill para…», «corrige esta skill» o «empaca la skill».

No la uses para redactar el texto en sí. Cómo se escribe una instrucción —qué entra, qué sale, cuánto mide— lo fija redactar-para-agentes, que esta skill carga. desarrollar-skills se ocupa del ciclo: etapas, versión, compuertas, empaque y entrega.

No instala nada. Te entrega el paquete con su botón; el clic es tuyo.

3.10 redactar-para-agentes

Documenta redactar-para-agentes 1.1.1 tal como viene en el paquete Pay de Manzana 1.3.1.

Para quién es este capítulo. redactar-para-agentes es una skill de quien fabrica o ajusta el entorno, no del uso diario. La vas a ver trabajar cuando escribas o corrijas una caja de instrucciones, una encomienda, una memoria o una skill propia. El porqué de cada regla está en la vista «temas» y en el maestro.

En una frase

redactar-para-agentes es la norma con que se escribe y se revisa todo texto que un agente lee para ejecutar: dice qué entra, qué sale, cuánto puede medir, y entrega cada revisión con el texto corregido y una hoja de hallazgos con archivo y renglón.

Cuándo usarla y cuándo no

Úsala al escribir, revisar, adelgazar o auditar una skill, una caja de instrucciones, una encomienda o una memoria de dominio o de proyecto, y antes de dar por buena la description de una skill. Otras skills del entorno la cargan solas antes de escribir esos textos (por ejemplo, arrancar-proyecto y desarrollar-skills).

No la uses para documentos que leen personas: un manual como éste, un informe o una minuta no son instrucciones para un agente.

No la uses para empacar o versionar. La mecánica de empaque y versión vive en desarrollar-skills.

3.1 arrancar-sesion

Por qué existe

Cargar de más cuesta y confunde. Una sesión que solo va a transcribir un audio no necesita la bitácora ni el índice de proyectos; una que va a decidir el rumbo de un proyecto sí. Si cada sesión leyera todo el entorno, pagaría por leer lo que no usa y mezclaría lo vigente con lo que no aplica. Por eso hay siete tipos de sesión, y cada uno abre solo sus fuentes. Lo que la tabla del tipo no nombra no se abre; para saber qué hay en una carpeta basta listarla, no leerla.

Lectores baratos que traen solo lo que importa. Los archivos grandes —la bitácora, el corpus, la Ficha del dominio— no los lee la ventana principal. Los lee un cargador: un subagente de solo lectura que contesta preguntas fijas del tipo de sesión y devuelve hechos, cada uno con el archivo y el renglón de donde sale. Sin cita no hay hecho. Así la ventana recibe pocos renglones verificables en lugar de miles de renglones crudos, y todos los cargadores corren a la vez.

Cada dato tiene un dueño. Cuando dos fuentes dicen cosas distintas, no se elige en silencio: vale la fuente que declara ese dato (la del proyecto para su estado, el perfil para quién eres tú) y la contradicción se te reporta con las dos citas para que corrijas la fuente equivocada.

La fecha y la máquina importan. El reloj del sistema viene en hora UTC, que de tarde-noche ya va un día adelante; todo lo que después se estampe con fecha saldría mal. Y la máquina que anuncia el arranque es la que el cierre usa para firmar la entrada de bitácora de la sesión.

Para enseñarla

• El error más común es enseñarla como «la que lee todo al empezar». Es lo contrario: la que decide qué no leer. Enséñala desde los tipos de sesión.
• Enseña a declarar desde el día uno. «Sesión PROYECTO · <proyecto>» en el primer mensaje ahorra la inferencia y sus avisos. Las frases sueltas («carga contexto», «retomemos») funcionan, pero el tipo queda inferido.
• Enseña a leer la línea del reporte: fecha, máquina, tipo, «Cargué» con sus N de M, y los avisos. Quien sabe leer esa línea sabe si la sesión arrancó bien.
• Demostración sugerida: arranca dos veces la misma conversación con un proyecto de ejemplo —una con «hola» (tipo 0) y otra con «Sesión PROYECTO · <proyecto>»— y compara las dos líneas de reporte. Luego pide «trae la bitácora para <pregunta>» y muestra cómo se agrega a «Cargué».
• Preguntas de comprobación: «¿Qué diferencia hay entre una sesión B y una C?», «¿Por qué el tipo E no se infiere?» y «¿Qué significa corpus 40 de 212 en el reporte?».

3.2 cerrar-sesion

Por qué existe

Lo que no se guarda, la próxima sesión no lo sabe. Cada conversación empieza en blanco; lo único que pasa de una a otra es lo que quedó escrito en la carpeta maestra. El cierre es el paso que lo escribe.

La ventana relata; otros escriben. La conversación que trabajó conoce lo que pasó, pero lleva encima todo el ruido de la sesión. Por eso no escribe en el corpus, la bitácora ni los índices: redacta un acta y la reparte a tres escritores que arrancan frescos, sin más material que esa acta. Lo que no está en el acta no existe para ellos, así que el acta se escribe primero y con cuidado.

Una decisión tuya no se parafrasea. Si el acta resume con otras palabras lo que decidiste, la siguiente sesión obedece el resumen, no tu decisión. Por eso las decisiones van textuales: parafrasear una decisión la deroga.

Cada dato en un solo nivel. El detalle vive en el nivel más bajo que aplique —el proyecto—, y arriba solo sube su estado, una línea y un puntero. Si el mismo avance se escribiera en la bitácora y en el proyecto, tarde o temprano dirían cosas distintas.

Hay documentos que no cambian sin ti. Tu perfil, la lista de dominios, las cajas de instrucciones y las Fichas de dominio rigen todas las sesiones. El cierre no los edita: propone el cambio y espera tu aprobación.

La bandeja no es lugar de trabajo. En _Inbox/ solo debe quedar lo que nadie ha tocado; así, al abrirla, lo que ves es exactamente lo pendiente.

Para enseñarla

• El error más común es enseñarla como «la que resume la sesión». Enséñala como la que reparte: la ventana escribe un acta y tres escritores ponen cada cosa en su lugar.
• Insiste en el acta. Todo lo que no entre ahí se pierde; por eso las decisiones van textuales y los ítems de bandeja usados se declaran.
• Explica el sello. Seguir escribiendo después de 🔒 SESIÓN CERRADA no es un error, pero reabre la sesión: el nombre pasa a ✗ y lo nuevo se guarda como addendum hasta re-cerrar.
• Demostración sugerida: en una sesión de ejemplo, toma una decisión explícita, usa un archivo de la bandeja y pide «cierra la sesión». Después abre la bitácora, el proyecto.md, la bandeja y _Memoria/admisiones.md para que vean dónde quedó cada cosa.
• Preguntas de comprobación: «¿Por qué la ventana no escribe directamente en la bitácora?», «¿Qué pasa con un archivo de la bandeja que solo leíste?» y «¿Qué documentos nunca cambian sin tu aprobación?».

3.3 arrancar-proyecto

Por qué existe

El objetivo decide si un proyecto tiene éxito; todo lo demás es andamiaje. Las carpetas, el índice y la caja de instrucciones se pueden crear en un minuto y no hacen que nada salga bien. Lo que sí lo hace es saber qué tiene que ser verdad al terminar, para quién y cómo se va a medir. Por eso la skill dedica la sesión a esclarecer el objetivo, y deja las carpetas para el final.

El arranque es el momento de más contexto. Cuando alguien decide empezar algo, tiene en la cabeza por qué, para quién y qué le preocupa. Una semana después ya no. La skill aprovecha ese momento con una entrevista completa, no con «una o dos preguntas»: lo que no se fija al arranque cuesta mucho más reconstruirlo después.

Un documento central que solo instruye. Cada sesión que trabaja el proyecto lee su proyecto.md completo. Si ese archivo acumula historia —qué se intentó, qué cambió, quién dijo qué— cada sesión paga por leer lo que ya no manda, y el agente puede confundir lo viejo con lo vigente. Por eso proyecto.md lleva solo instrucciones vigentes; la historia va a otro archivo que no se carga.

Cada dato en un solo lugar. Lo que es cierto de ti va en la memoria global; lo que es cierto del negocio, en el dominio; lo que es cierto del proyecto, en su proyecto.md. Los niveles de abajo apuntan a los de arriba, no copian. Si un dato vive en dos lugares, tarde o temprano se contradicen y nadie sabe cuál manda.

Tres tipos de proyecto porque avanzan distinto. Un trabajo que se termina en una tarde, uno que evoluciona durante meses y uno que se repite para siempre no se planean igual ni se miden igual. Un proyecto fugaz no es un complejo abreviado: hace menos preguntas y siembra otro documento.

Para enseñarla

• El error más común al enseñarla es presentarla como «la que crea las carpetas». Las carpetas son lo de menos: enséñala como la entrevista que fija el objetivo.
• No digas «contesta unas preguntas». Son el guion completo; si el asistente espera dos preguntas y le llegan ocho, siente que algo salió mal.
• Demostración sugerida: arranca en vivo un proyecto fugaz real de alguien del grupo. Deja que la skill proponga cada respuesta y que el grupo corrija. Termina abriendo proyecto.md y la fila del índice para que vean que la memoria quedó escrita.
• Pregunta de comprobación: «¿Qué diferencia hay entre un proyecto fugaz, uno complejo y un proceso?», y «¿Para qué sirve la contra-medida?».

3.4 capturar-conocimiento

Por qué existe

El conocimiento tiene que sobrevivir al proyecto. Lo que se aprende de un proveedor, una norma o un equipo mientras se trabaja un proyecto sirve después a otros proyectos. Si se queda en la memoria del proyecto o en la bitácora, nadie lo encuentra. El corpus es el lugar donde vive ese conocimiento; los proyectos y bitácoras lo referencian, no lo copian.

No todo lo que se aprendió es conocimiento. La prueba ácida es una pregunta: ¿le sirve a una sesión de otro proyecto dentro de seis meses? Si solo le sirve a este proyecto, es contexto y ya vive en su proyecto.md o en la bitácora.

Pocas páginas buenas valen más que muchas. Un corpus que crece con todo lo que pasó se vuelve tan difícil de consultar como no tener corpus. Por eso la skill es selectiva: cero páginas es un resultado válido.

Cada organización con su corpus, sin cruces. El conocimiento de una organización no se consulta ni se escribe desde otra; lo personal no se mezcla con lo de negocio.

Las reglas las pone el corpus, no la sesión. Cada corpus trae su SCHEMA.md: qué tipos de página existen, qué campos llevan y cómo se escriben. La skill lo carga antes de escribir y no inventa nada fuera de él.

Para enseñarla

• El error más común es enseñarla como «la que guarda todo lo de la sesión». Enséñala como un filtro: su trabajo principal es dejar fuera lo que no va.
• Enseña la prueba ácida con casos: «¿le sirve a una sesión de otro proyecto dentro de seis meses?». Lleva tres o cuatro hechos de una sesión de ejemplo y que el grupo decida cuáles pasan.
• Separa corpus de perfil: lo que describe a la persona va al perfil, y solo con su confirmación; lo que describe al negocio o a sus entidades va al corpus.
• Demostración sugerida: en una sesión de ejemplo, menciona una entidad nueva (un proveedor ficticio) y pide «pasa esto al corpus». Abre después la página, el index.md y el log.md del paquete para mostrar las tres escrituras y las tres marcas de procedencia.
• Preguntas de comprobación: «¿Por qué un dato del proyecto no va al corpus?», «¿Dónde va la incertidumbre de un dato?» y «¿Qué pasa con algo que la sesión aprendió sobre ti?».

3.5 generar-encomienda

Por qué existe

El trabajo que se deja para después se pierde si no se escribe completo. Cuando un encargo se pospone, el contexto que lo hacía claro se queda en la sesión que lo pensó. La encomienda lo fija por escrito para que otra sesión —otro día, en otra máquina, con otro agente— lo tome y lo haga bien.

Dos componentes deciden si una encomienda sirve: el objetivo y las preguntas abiertas. Todo lo demás —el encabezado, las rutas, los límites— es andamiaje alrededor de esos dos. Un objetivo flojo no se nota al escribirlo: se nota cuando el agente que la toma decide mal todo lo que la encomienda no cubre. Y una pregunta sin contestar que nadie escribió se vuelve una suposición del agente. Por eso la skill dedica la sesión a esos dos componentes.

La regla de oro. Una encomienda pasa a listo —es decir, puede ejecutarse— solo cuando su sección de preguntas abiertas está vacía y sus criterios de aceptación los puedes verificar tú en menos de diez minutos. Si revisar el resultado te costaría una hora, los criterios no están bien escritos.

Redacta primero, pregunta después. La skill arma la encomienda con lo que ya sabe y luego te pregunta solo lo que falta. Lo que dedujo lo marca como deducido dentro del texto de la encomienda, no solo en su cabeza: quien la tome después tiene que ver qué confirmaste y qué se supuso.

Una encomienda que no empuja el objetivo de su proyecto no debe existir. Dentro de un proyecto, cada encargo existe para acercarlo a su objetivo. Si no se puede decir a cuál objetivo empuja, el trabajo sobra, o pertenece a otro lado, o el objetivo del proyecto ya está viejo. Por eso la skill revisa esto antes de escribir una sola sección, y si no pasa, no escribe la encomienda.

Cada tipo de entregable tiene su norma, y esa norma ya está escrita. Una skill, un texto para agentes o un archivo del Corpus tienen reglas propias, guardadas en documentos llamados rectores. La skill los consulta en vez de inventar los criterios, y los cita en vez de copiarlos.

Para enseñarla

• El error más común es presentarla como «la que llena una plantilla». Enséñala como la que fija el objetivo y las preguntas abiertas; la plantilla es andamiaje.
• Insiste en la compuerta. Que una skill se niegue a escribir algo sorprende; explica antes que una encomienda que no empuja el objetivo es trabajo que no debe existir.
• Explica draft como algo sano. Una encomienda en draft no está mal: está honesta sobre lo que falta.
• Demostración sugerida: pide en vivo una encomienda para un trabajo real y pequeño. Deja que la skill proponga los cinco puntos y que el grupo los corrija; abre el archivo y señala el encabezado, la sección de preguntas y las Notas de progreso. Después pide «avánzala» y muestra el cambio a listo.
• Preguntas de comprobación: «¿Qué hace la compuerta del punto 5 y cuáles son sus tres salidas?», «¿Cuándo una pregunta no es pregunta abierta?» y «¿Qué diferencia hay entre draft y desalineada?».

3.6 cuestionar-usuario

Por qué existe

Una idea floja no se puede comprometer, pero tampoco hay que esperar a que madure sola. La vaguedad no es razón para posponer: es justo la materia prima de esta skill. Sirve para convertir una idea todavía difusa en decisiones tomadas.

Los hechos son de la skill; las decisiones son tuyas. Todo lo que se puede averiguar —en tus archivos, en la memoria del proyecto, con una búsqueda— lo averigua ella y nunca te lo pregunta. Tu tiempo se gasta solo en lo que únicamente tú puedes decidir.

El qué antes que el cómo. Qué tiene que lograr el trabajo es lo fundamental; cómo se logra admite muchas formas válidas. Un cómo bien resuelto sobre un qué flojo es trabajo perdido. Por eso no te pregunta ningún detalle de ejecución mientras el objetivo, el entregable o la prueba de que quedó bien sigan abiertos.

El riesgo es que termines asintiendo a un plan que escribió el agente. Si contestas «de acuerdo» cuarenta veces, el plan no es tuyo. Por eso la skill registra quién decidió cada cosa, te avisa cuando llevas tres aceptaciones seguidas sin matizar y nunca contesta sus propias preguntas.

Para enseñarla

• El error más común es presentarla como «la que hace muchas preguntas». Enséñala como la que separa hechos de decisiones: averigua todo lo averiguable y solo te pregunta lo que es tuyo.
• Explica el árbol y la frontera con un ejemplo de pizarrón: no tiene sentido preguntar el formato de un reporte antes de saber quién lo recibe.
• Demostración sugerida: que alguien del grupo traiga una idea a medio pensar y diga «cuestióname». Muestra los cuatro campos de cada pregunta, cambia de modo a media sesión y termina leyendo el acta: señala qué quedó inferida y pregunta al grupo si de verdad lo decidieron.
• Preguntas de comprobación: «¿Por qué no te pregunta una ruta de archivo?», «¿Qué diferencia hay entre una pregunta que abre y una que cierra?» y «¿Qué significa propuesta confirmada?».

3.7 maxwell

Por qué existe

Quien hizo el trabajo no puede revisarlo. La sesión que produjo un entregable ya está convencida de que quedó bien. Por eso el revisor es siempre un subagente fresco, distinto en cada vuelta, que no es quien hizo el trabajo. Maxwell no clasifica: reúne, registra y reporta; el que juzga es el revisor.

Se audita el objetivo; los criterios son solo evidencia. Un entregable puede cumplir todos sus criterios y aun así no servir para lo que se encargó. Por eso el veredicto sobre el objetivo manda. Y si hay una parte del objetivo que ningún criterio revisa, el defecto no es del entregable sino de la vara con que se mide (Maxwell lo llama hueco de vara).

El revisado no fija las reglas de su propia revisión. Ni la sesión que hizo el trabajo ni la encomienda que lo encargó le dicen a Maxwell qué palabras puede usar el dictamen ni qué abarca la revisión. Si quien hizo el trabajo pudiera decir «revísalo y cierra con PASA o NO PASA», le borraría al revisor dos de sus cuatro respuestas posibles.

Cuatro dictámenes, ni uno más. El vocabulario es cerrado: ningún otro término vale y ninguno se renombra.

Cada reserva lleva un dueño y uno de tres destinos: se corrige antes de congelar el entregable; va al registro de pendientes de tu entorno (o al reporte, si tu entorno no lleva ese registro); o se acepta con la razón escrita.

La última palabra es tuya. Maxwell nunca envía, publica, gasta, borra ni toca permisos o archivos compartidos. Aunque el dictamen sea PASA, la compuerta final eres tú.

Para enseñarla

• El error más común es pensar que Maxwell «corrige» o «mejora» el trabajo. Enséñalo como un portero: dice si pasa o no, y por qué; corregir es de quien hizo el trabajo.
• Explica por qué cuatro dictámenes y no dos. RESERVAS y NO SE PUDO VERIFICAR existen para que la duda y la falta de prueba no se disfracen de PASA.
• Insiste en el objetivo sobre los criterios con un ejemplo: un reporte que cumple todas las casillas pero no sirve para la decisión que se encargó.
• Demostración sugerida: pasa por Maxwell un entregable pequeño con un error deliberado (por ejemplo, una cifra que no cuadra con su fuente). Muestra el dictamen, abre auditoria_v1.md y señala el mandato textual y el hallazgo con su archivo:renglón. Corrige solo ese renglón y pásalo otra vez.
• Preguntas de comprobación: «¿Por qué el revisor no puede ser quien hizo el trabajo?», «¿Qué diferencia hay entre NO PASA y NO SE PUDO VERIFICAR?» y «¿Qué es un hueco de vara?».

3.8 pay-de-manzana

Por qué existe

Tu entorno ya tiene cosas tuyas, y ninguna se puede perder. La regla que gobierna toda la skill es: «nada del usuario se pierde: lo que cabe se conserva; lo que no cabe se mueve con respaldo, traza y tu visto bueno». Por eso nunca vuelve a sembrar una plantilla encima de un archivo que ya existe: trabaja pieza por pieza sobre lo que haya, y lo que no cabe en la forma nueva lo mueve, no lo borra.

Lo que hay en tu carpeta se reconoce por su forma, no por la etiqueta. Un entorno puede decir en su índice que es de cierta versión y no serlo, o tener piezas de dos versiones mezcladas. Por eso la skill te reporta la versión que declara tu _Memoria/INDICE.md, pero esa versión no decide ningún paso: lo que decide es la situación de cada pieza, vista en sus encabezados, columnas y cláusulas. Por lo mismo, el contenido de tu carpeta tampoco decide el modo: el modo lo decide lo que pediste.

Un solo proceso con dos modos. REVISAR no es un análisis aparte: recorre el mismo reconocimiento y arma el mismo plan que INTEGRAR, y se detiene antes de aplicar. Así, lo que REVISAR te reporta es exactamente lo que INTEGRAR haría.

Quien mira el disco no es quien lo arregla. El reconocimiento de tu carpeta lo hace siempre un subagente fresco de solo lectura, nunca la conversación principal. Ese subagente funciona como candado: no puede escribir, así que lo que reporta es lo que hay, no lo que la conversación espera encontrar. Si tu superficie de trabajo no permite subagentes, la skill se detiene en vez de reconocer por su cuenta.

Lo que vive en la app no se ve desde la carpeta. Las cajas de instrucciones, el ajuste «Cowork files», las carpetas conectadas, las skills instaladas y la sincronización viven en la app, no en tu disco. La skill no los da por buenos con evidencia indirecta: te pide que los confirmes, y las cajas te las entrega para que tú las pegues.

Una sola ronda de preguntas y un solo sí. Todo lo que necesita saber de ti lo pregunta junto, al principio, con valores por defecto; después te presenta un plan completo y te pide una sola aprobación, con derecho a vetar filas. No te interrumpe a media aplicación.

Correrla dos veces no duplica nada. Cada paso revisa antes si ya está hecho, y el plan que apruebas, con tus vetos, queda guardado para que la siguiente corrida no te vuelva a proponer lo que ya rechazaste.

Cajas mínimas y cada dato en un solo lugar. Las cajas de instrucciones solo dicen dónde vive tu entorno, qué skill corre al abrir y al cerrar, y las reglas de seguridad al escribir; el detalle del modelo vive en INDICE.md y tus preferencias en perfil.md. Cada regla vive en un solo nivel de caja y cada dato en un solo nivel de memoria: los de abajo apuntan a los de arriba, no copian. Si un dato vive en dos lugares, tarde o temprano se contradicen.

Para enseñarla

• El error más común al enseñarla es presentarla como «el instalador». Enséñala como la que lleva tu entorno a su forma vigente sin perder nada tuyo: el respaldo, el plan en seco y el sí único son el corazón, no las carpetas.
• Enseña los dos modos con una sola idea: REVISAR es INTEGRAR sin el paso de aplicar. Si alguien tiene miedo de tocar su entorno, que empiece con «revisa mi entorno».
• Anticipa lo manual. Pegar cajas, cambiar «Cowork files», desconectar carpetas e instalar skills son clics del asistente. Dilo antes, para que nadie espere que la skill lo haga sola.
• Demostración sugerida: sobre una carpeta vacía de ejemplo, corre «genera mi entorno» con nivel «Solo trabajo», pega las cajas siguiendo la instrucción de cerrar y reabrir, y termina con el ejercicio 1 de «Mi primer proyecto». Después corre «revisa mi entorno» para que vean un reporte sin cambios.
• Para el perfil: subraya que dejar ranuras vacías es lo deseable y que la carga de proponer es de Claude; el asistente solo confirma, corrige o tacha.
• Preguntas de comprobación: «¿Qué diferencia hay entre INTEGRAR y REVISAR?», «¿Qué es la alta?» y «¿Por qué la carpeta de “Cowork files” no puede estar dentro de la maestra?».

3.9 desarrollar-skills

Por qué existe

Una skill es código que otro agente ejecuta, y se fabrica como código. Sin un ciclo fijo, una sesión escribe la skill de una vez, le pone número, la empaca y te la entrega «terminada» para que la apruebes después. Esta skill parte el trabajo en etapas que tú abres: tú apruebas el diseño, tú lees el borrador, tú das la orden de congelar, tú haces el clic de instalar.

No reemplaza a skill-creator; la complementa. skill-creator es la herramienta general para crear skills; desarrollar-skills es el delta de este entorno: lo que aquí se hace distinto. Las dos se cargan juntas, y cada diferencia entre ellas está declarada en una tabla (ver «Divergencias con skill-creator»).

Iterar no es versionar. Mientras corriges un borrador no hay número de versión, ni registro, ni paquete. El número aparece una sola vez, cuando congelas. Así la versión 1.2.0 de una skill es una cosa concreta, y no «la que estaba en la carpeta el martes».

Quien revisa no es quien hizo. El agente que escribió la skill no puede darla por buena. Un revisor fresco, que no altera nada, la audita contra criterios escritos; sin su dictamen favorable no se empaca. Es una compuerta, no un consejo.

La skill viaja; el entorno no. Una skill se instala en la cuenta y corre en cualquier máquina y en el entorno de otras personas. Por eso no puede llevar rutas de tu máquina, credenciales ni nombres de productos que quizá otro no tenga, y tiene que decir qué hacer cuando algo de afuera no está.

Para enseñarla

• Enséñala como un ciclo de aprobaciones, no como un empacador. El valor está en que nada avanza sin el sí de la persona: diseño, borrador, congelamiento, instalación.
• La idea que más cuesta: iterar no es versionar. Haz que el grupo distinga «la carpeta que estoy editando» de «la versión 1.2.0 que se entregó».
• El revisor fresco no es un consejo, es la compuerta 7: la sesión que hizo la skill no puede darla por buena, y un PASA sin informe detrás no abre.
• Demostración sugerida: toma una skill pequeña de ejemplo, haz un cambio de una línea, corre las compuertas en modo borrador y muestra cómo se detienen en la primera falla y qué significa cada código. Cierra mostrando la tabla de estantes y pregunta en qué estante iría la skill.
• Preguntas de comprobación: «¿Qué cambio sube MINOR y cuál PATCH?», «¿Por qué una skill nombra ~~drive y no un producto?» y «¿Qué hace la skill si un objeto del entorno no está?».

3.10 redactar-para-agentes

Por qué existe

Una instrucción es código, no documentación. Un agente no lee una caja o una skill para informarse: la ejecuta. Cada renglón que solo informa —historia, explicaciones, consejos para el humano— se paga en cada lectura y compite con los renglones que sí mandan. La regla de la skill cabe en una línea: escribe el comportamiento correcto vigente, en positivo, para que un modelo lo ejecute; nada más.

«Está muy largo» no gana discusiones; un número sí. Por eso cada texto declara su propio presupuesto de renglones y se mide contra él. La norma no fija uno para todos, porque un procedimiento de cuatro ramas y una página de mecánica no son comparables.

Un dato en dos lugares acaba mintiendo. Cuando se corrige arriba y la copia de abajo sigue con el error, la copia no sobra: miente. Por eso cada dato vive en un solo nivel y los demás apuntan a él.

Sirve para cerrar discusiones de redacción. Además de las reglas, trae seis criterios de diseño (FILOSOFIA.md). Ante una discusión, decide el criterio; si ninguno aplica, es cuestión de gusto y no de norma.

Para enseñarla

• Enséñala con una prueba, no con una lista: «¿instruye o registra?». Con esa sola pregunta el grupo puede revisar cualquier caja.
• El error más común es querer adelgazar recortando palabras. Muestra que lo que se saca son renglones enteros que registran o explican.
• Demostración sugerida: toma una caja de instrucciones de ejemplo que lleve un párrafo de historia, un «sé breve» y un ejemplo que repite la instrucción. Revísala en vivo con el orden de once pasos y entrega la hoja de hallazgos con archivo y renglón.
• Preguntas de comprobación: «¿Dónde se declara el presupuesto de una encomienda?», «¿Por qué un puntero a otra pieza no obliga al agente a abrirla?» y «¿Qué diferencia hay entre falla y no se pudo verificar?».