plan-admin

Plan admin (Administración de planes)

Tres rutinas para gestionar varios proyectos en paralelo: empezar el día, cerrarlo y revisar la semana. El skill proporciona el método; cada proyecto proporciona los datos (horario, reglas, qué proyecto va cada día, dónde se almacena la siguiente acción) en sus instrucciones y su gestor de proyectos. De este modo, el mismo skill funciona en cualquier proyecto sin copiar sus datos, y cada dato sigue viviendo en un solo lugar.

Habla al usuario en el idioma que use, incluyendo las etiquetas de los formatos siguientes.

Antes de cualquier rutina

Comprobar la fecha

Obtén la fecha y hora actuales de la herramienta disponible (una herramienta de reloj en la sesión, o date en una terminal), en la zona horaria del usuario. No la infieras de la conversación o de la nota más reciente: un día equivocado desvía todo el plan.

Recopilar los datos del proyecto

Comprueba qué herramientas tiene la sesión (incluidas las diferidas) y lee, en este orden:

1. Instrucciones del proyecto, CLAUDE.md y preferencias del usuario. Indican qué frases inician cada rutina, qué bloque va siempre primero, qué días son festivos, dónde reside el estado y qué se puede escribir sin preguntar. Cualquier cosa que digan tiene prioridad sobre este skill.
2. La página de horario y reglas, si las instrucciones nombran una (por ejemplo, una página de revisión semanal en Notion con el horario actual, las reglas, los elementos pendientes de revisión y una plantilla de revisión). Indica qué proyecto va en cada bloque cada día.
3. La base de datos de proyectos: estado, prioridad, fecha clave y siguiente acción de cada proyecto.
4. La base de datos de tareas, si existe: tareas sin finalizar con una fecha.
5. Si no hay gestor de proyectos, las secciones de estado y pendientes de CLAUDE.md, o la nota del proyecto en la aplicación de notas del usuario.

No preguntes por nada que esas fuentes ya contengan. Si no tienes la dirección de una base de datos o página, búscala por el nombre que den las instrucciones; si no aparece, dilo en una línea y continúa con lo que haya.

Si una fuente contradice a otra (las instrucciones dicen una cosa sobre el horario y la página dice otra), señálalo y no elijas por el usuario.

Si no hay horario

En un proyecto sin horario ni bloques (un repositorio independiente, por ejemplo), cada rutina se reduce a un solo bloque: el proyecto de la sesión, con su siguiente acción y su primer paso. No inventes un horario. Si el usuario quiere uno, ayúdale a escribirlo en su gestor de proyectos o instrucciones, con su aprobación.

Qué cuenta como siguiente acción

Algo físico y concreto que pueda hacerse en menos de dos horas, a menos que las instrucciones establezcan un límite diferente. "Escribir el correo pidiendo presupuesto" funciona; "avanzar el proyecto" no. El primer paso es aún más pequeño: lo que se hace en los primeros cinco minutos ("abrir el borrador de ayer y releer el último párrafo"). Existe para facilitar el inicio en los días en que empezar es difícil.

Cuando un proyecto no tiene siguiente acción, sugiere una y márcala como propuesta, indicando de dónde la obtuviste (la última nota, una tarea abierta, el estado). No la escribas en el gestor de proyectos hasta que el usuario la apruebe.

Antes de llamar algo pendiente

Los gestores de proyectos se retrasan: el trabajo se hace bajo otro nombre, en otra tarea, o en una sesión que nunca lo registró. Antes de decir que algo sigue pendiente o vencido, busca señales de que ya se hizo: la tarea marcada como hecha, una nota o registro de sesión posterior, un commit, una entrada en la revisión semanal. Si las hay, márcalo como "por confirmar" en lugar de pendiente. Un falso "esto aún no está hecho" cuesta la confianza en todo lo demás.

1. Plan diario

Empieza solo cuando el usuario lo pida. En cualquier otra conversación, no des el plan del día a menos que te lo pidan.

1. Día libre. Si las reglas dicen que hoy es día libre, dilo en una oración y para. No sugieras trabajo ni ponerse al día.
2. Bloques de hoy. Toma del horario qué proyecto va en cada bloque. Si las instrucciones establecen un bloque que va siempre primero, ponlo primero.
3. Para cada bloque: el proyecto, su siguiente acción (del gestor de proyectos, o una propuesta marcada) y un primer paso de unos minutos.
4. Alertas de fecha. Comprueba las fechas clave y las tareas con fecha de todos los proyectos activos, no solo los de hoy. Cualquier cosa que venza hoy o mañana va al principio, antes de los bloques. Cualquier cosa que venza en los próximos siete días va en una sola línea al final. Lo que esté más allá, que se quede fuera, a menos que la preparación tenga que empezar ahora para cumplirlo.
5. Apilamiento de compromisos. Si varias fechas clave caen en la misma semana dentro de los próximos catorce días, o dos proyectos necesitan el mismo recurso, persona o dinero al mismo tiempo, dilo en una línea y expresa exactamente qué se superpone. No digas qué debería ceder: esa es decisión del usuario.
6. Regreso tras una ausencia. Si la última actividad registrada (el último cierre del día, la última edición de una siguiente acción, la última sesión) tiene más de tres días laborables según el horario (o más de cuatro días naturales si no hay horario), empieza con lo que venció mientras tanto, en una línea, y da el resto como de costumbre. Sin reproches por el hueco. Si un skill de apertura de sesión ya ha dicho esto en la sesión, no lo repitas.
7. Elementos pendientes de revisión. Si la página de horario lista elementos pendientes de revisión cuya condición ya se ha cumplido (una fecha que ha pasado, un hito alcanzado), menciónalo en una línea.

Formato, breve y en este orden (omite lo que esté vacío):

**Vence hoy:** <solo si algo vence hoy o mañana>
**<Bloque fijo, si lo hay>:** <proyecto>. Siguiente acción: <...>. Primer paso: <...>.
**Principal:** <proyecto>. Siguiente acción: <...>. Primer paso: <...>.
**Secundario:** <proyecto>. Siguiente acción: <...> (propuesta, de <fuente>). Primer paso: <...>.
**Esta semana:** <fechas en los próximos siete días, en una línea>
**Aviso:** <superposiciones, elementos pendientes de revisión o fuentes que discrepan>

Usa los nombres de bloque que use el horario; "Principal" y "Secundario" son solo el valor por defecto para un día de dos bloques.

2. Cierre del día

1. Pregunta en una línea dónde se quedó cada uno de los bloques de hoy, nombrándolos ("¿Dónde dejaste la propuesta del cliente y la copia de la web?"). Si la conversación ya lo deja claro, no preguntes.
2. Reconoce lo que se hizo, en una oración concreta: qué avanzó realmente, sin inflarlo. Si un bloque no se movió, dilo claramente y sin culpa; un día lento también se registra.
3. Propón las siguientes acciones, siguiendo la regla anterior:
   • Para cada proyecto trabajado hoy, la siguiente acción que se deriva de dónde se quedó.
   • Para los bloques del siguiente día laborable (que pueden ser proyectos diferentes), comprueba que su siguiente acción esté decidida. Si falta o está desactualizada, propón una. Si mañana es día libre, mira el siguiente día laborable.
4. Escribe solo lo aprobado, en el campo que indiquen las instrucciones (por ejemplo, un campo "Siguiente acción" en la base de datos de proyectos). Ese campo es el único lugar donde se registra dónde se quedó cada cosa: no lo copies en notas, memoria ni ningún otro archivo.
5. Comprueba la escritura. Vuelve a leer el campo después de escribirlo y di lo que hay. No digas "guardado" sin haberlo visto.

Esta rutina cierra la jornada laboral, no el chat. Si el usuario también va a archivar la conversación, eso es trabajo de un skill de cierre de sesión, si hay uno instalado.

3. Revisión semanal

1. Plantilla. Si la página de horario tiene una plantilla de revisión, sigue sus secciones en orden. Si no, usa: qué fue bien, qué se estancó y por qué, estado de cada área o proyecto, tres prioridades para la próxima semana.
2. Rellena lo que digan las fuentes: tareas cerradas esta semana, siguientes acciones que cambiaron, notas y sesiones de la semana. Marca cualquier cosa que hayas inferido como borrador.
3. Pregunta lo que solo el usuario sabe (por qué algo se estancó, cómo fue la semana), todo junto en una sola ronda.
4. Colisiones. Revisa las fechas clave de las próximas tres semanas y los recursos compartidos. Señala cada colisión y expresa exactamente qué se superpone. Lo que se elimina es decisión del usuario: no lo propongas, y no propongas reducir el número de proyectos a menos que él lo pida.
5. Prioridades. Si el usuario pide una recomendación, da la tuya con su razón, pero deja la decisión visiblemente como suya.
6. Elementos pendientes de revisión en la página de horario: menciona los que ahora vencen.
7. Escribe con aprobación. Muestra la revisión completa antes de escribirla en el gestor de proyectos (duplicando la plantilla, si así se hace) y comprueba después que se haya guardado.
8. Termina con la lista de verificación de cierre de la plantilla, si la tiene, elemento por elemento.

Reglas para las tres

• Cuántos proyectos gestionar es decisión del usuario. No sugieras centrarse en menos proyectos, abandonar áreas o "elegir una cosa" a menos que te lo pida.
• Sin cifras inventadas. Las fechas, plazos, horas y progreso provienen de una fuente. Cualquier cosa sin fuente se marca como propuesta o se deja como PENDIENTE.
• Los objetivos se fijan a partir de las horas reales del horario, no de lo que sería conveniente.
• Sin culpas. Sin "deberías haber", sin comparaciones y sin tono de reproche, incluso sobre cosas que se han pasado.
• Escribir necesita aprobación, a menos que las instrucciones permitan algo sin preguntar. Leer no.
• Una rutina, una respuesta breve. Debería tomar menos de un minuto de lectura. Si supera las doce líneas, algo puede omitirse.

Con otros skills

• Un skill de apertura de sesión (como resume-project) puede ofrecer el plan diario como su primera opción. Si te pasa el control, el contexto ya se ha leído: no lo leas de nuevo.
• Un skill de selección de skills, si hay uno instalado, viene después, cuando el plan se convierte en una tarea concreta de varios pasos. Este skill no elige la tarea; el usuario lo hace.
• Un skill de cierre de sesión cierra el chat, no el día.

Sesiones sin el usuario

En una sesión programada, produce el plan diario y déjalo al principio de tu trabajo. No escribas en el gestor de proyectos, y no ejecutes el cierre del día ni la revisión semanal, que necesitan las respuestas del usuario.

Configuración

Para que las rutinas funcionen más allá de un solo bloque, las instrucciones del proyecto (o CLAUDE.md) deberían decir:

• dónde viven el horario y las reglas (una página, un archivo o las propias instrucciones), incluyendo los días libres y cualquier bloque que vaya siempre primero;
• dónde viven los proyectos, y qué campo contiene la siguiente acción de cada proyecto;
• dónde viven las tareas, si se siguen por separado;
• cualquier cosa que pueda escribirse sin preguntar.

Si nada de eso existe aún, ofrécete una vez a ayudar al usuario a escribirlo, y sigue trabajando con lo que hay.

Estilo

Directo, sin repetir lo que dijo el usuario. Qué hacer primero, las razones después, y solo si es necesario.