alex20-create/resume-project

Reanudar proyecto

Cuando se abre una sesión, lo importante de las anteriores está repartido en varios lugares. Esta skill allana el camino de vuelta: lo recopila, lo coteja con la información más reciente disponible y se lo comunica al usuario en pocas líneas, para que pueda decidir en qué trabajar hoy sin tener que recordar nada.

Cuatro aspectos determinan su funcionamiento:

• Solo lectura. No escribe en ningún archivo, nota, base de datos ni memoria. Por eso no pide permiso para cada paso: leer no cambia nada. Copiar un archivo del ordenador del usuario a la sesión para leerlo cuenta como lectura. La única escritura permitida es git fetch --prune, y solo donde lo indique references/claude-code.md. Dar acceso a la sesión a un repositorio nuevo no es solo lectura: no lo hagas por tu cuenta (consulta la fila de GitHub en el paso 0). Los hooks de otros plugins pueden escribir al abrir la sesión (consolidando memoria, guardando registros): eso no es escritura de esta skill y no necesita mención, a menos que cambie una fuente que estés a punto de leer.
• Lee archivos, no ejecuta flujos de trabajo. Varias skills, al ejecutarse, escriben telemetría o estado, crean carpetas, piden su propio formato de salida o terminan con su propia pregunta. Cuando sepas dónde almacena sus datos una skill, lee ese archivo directamente. Ejecuta la skill solo si no hay otra forma y, en ese caso, toma sus datos, omite su pregunta final y su formato, y detén cualquier paso que escriba.
• Las instrucciones del proyecto tienen prioridad. Si las instrucciones del proyecto, un CLAUDE.md o las preferencias del usuario indican dónde reside el estado, qué carpetas se pueden leer, cómo se resuelven los conflictos o cómo se planifica el día, eso prevalece sobre esta skill.
• Termina con una pregunta y una transferencia. Una skill de cierre de sesión (por ejemplo, wrap-up) termina diciendo que la sesión se puede archivar; esta termina preguntando en qué trabajar hoy y pasando la respuesta al siguiente paso (paso 6).

0. Inventario: qué puedes leer realmente

No elijas las fuentes por el nombre del entorno. Una misma sesión puede estar en la nube, dentro de un proyecto de claude.ai y vinculada al ordenador del usuario a la vez. Antes de leer nada, examina las herramientas que tiene la sesión (también las diferidas, buscándolas) y anota cuáles de estas capacidades están presentes:

Capacidad	Cómo reconocerla	Fuentes que abre
Terminal en el repositorio	La carpeta de trabajo es uno de los repositorios del usuario, o hay un terminal en su ordenador (device_bash o similar) con el repositorio en una carpeta conectada	Git y el remoto (C), con references/claude-code.md
Archivos del ordenador sin terminal	Herramientas para listar y copiar archivos del ordenador, sin terminal	Bóveda (D), registro de sesión (B, si la configuración escribe uno) y traspasos (E) si están en una carpeta conectada, y el CLAUDE.md de un repositorio cuya carpeta esté conectada (D). No git local
GitHub sin terminal en el repositorio	gh instalado en la sesión, o una herramienta para añadir repositorios a la sesión	Pull requests, ramas y commits en el remoto (C2)
Gestor de proyectos	Un conector de Notion u otro gestor de proyectos, más instrucciones o un CLAUDE.md que indiquen qué base de datos o página contiene los proyectos	Estado, siguiente acción y tareas (A)
Chats anteriores	Herramientas para buscar o listar chats	Chats (F), con references/claude-ai.md
Sesiones de Claude Code	Herramientas para listar o buscar sesiones de la aplicación de escritorio (list_sessions, search_session_transcripts, list_events o similares)	Sesiones anteriores (F2), con references/claude-code.md
Artefactos publicados	Herramientas para listar artefactos, páginas o documentos publicados (Artifact con list, o similar)	Entregables fuera del repositorio (I)
Memoria	Memoria en el contexto, o herramientas de memoria	Memoria (G)
Proyecto de claude.ai	Instrucciones o archivos del proyecto en el contexto, o una herramienta de proyecto	Instrucciones y archivos (H)

Las referencias detallan la información sobre git (references/claude-code.md), sobre los chats de claude.ai (references/claude-ai.md) y sobre un registro de sesión por proyecto escrito por un hook (references/session-log.md). Lee solo la que abra una capacidad que tengas, y session-log.md solo si la configuración escribe dicho registro. Si una referencia dice que algo no está (bóveda, disco, git) y el inventario dice que sí, prevalece el inventario. Si falta una referencia, continúa con lo que dice este archivo.

Si la sesión tiene muchas herramientas diferidas, no las cargues todas para hacer el inventario: busca las palabras de la tabla (notion, session, transcript, chat, memory, project, repository, artifact) y carga el esquema solo de las que vayas a usar. gh no es una herramienta de sesión sino un programa: compruébalo con gh auth status. Si los nombres de las herramientas diferidas ya son visibles en el contexto, elige de esa lista y carga solo esas, sin buscar.

Las letras de las fuentes en este archivo (A a I) no son las de claude-code.md (A a H): E aquí son los traspasos, mientras que E en esa referencia es el CLAUDE.md. Cuando este archivo cite una categoría de claude-code.md, la cita por su nombre; búscala por el nombre, no por la letra.

Carpetas permitidas. Lee solo las carpetas que el usuario haya conectado a la sesión o que sus instrucciones te permitan leer, y a las que la sesión pueda acceder realmente. No pidas acceso a ninguna de ellas para poder reanudar. Pon todo lo que esté fuera de alcance en una sola línea de "Aviso":

• fuentes útiles fuera de las carpetas conectadas (por ejemplo, ~/.gstack en la carpeta de inicio, en una sesión sin terminal);
• carpetas que las instrucciones te permiten leer pero que no están conectadas (por ejemplo, la carpeta propia de un proyecto). Si una pertenece a un proyecto que aparece en el resumen, añade que todo lo que se sabe de ese proyecto es lo que dice el gestor de proyectos.

1. De qué proyecto se trata

• Un repositorio, una carpeta o un nombre. Si la sesión está en un repositorio, ese es el proyecto. Si el usuario lo nombra, búscalo en el gestor de proyectos (A) y en la bóveda (D), sin distinguir mayúsculas/minúsculas y probando los alias que dé la memoria: los nombres pueden no coincidir, y un proyecto puede estar en medio de un cambio de nombre.
• Un paraguas. Si el contexto es un espacio con varios proyectos (un proyecto de claude.ai que organiza todo el trabajo, un gestor de proyectos con una base de datos de proyectos, una bóveda con varias carpetas) y el usuario no nombra uno, no elijas en silencio. Escribe un resumen multiproyecto (paso 4) con aquellos que tengan la actividad más reciente y los que las instrucciones marquen como prioridad a corto plazo.
• Lo que el usuario da por sentado. Si el mensaje de apertura afirma un estado (una operación de git sin terminar, una rama, un PR, un despliegue), compruébalo contra las fuentes en cuanto las leas: la instantánea rápida de git, GitHub o, si lo hay, el registro de sesión. Si no coincide, dilo en una línea antes del resumen, con lo que dice cada una. Si lo que nombra pertenece a otro proyecto (otra carpeta, repositorio o nota), pregunta cuál se está reanudando antes de seguir leyendo; en una sesión sin usuario, continúa con el proyecto de la carpeta de trabajo y dilo al principio del resumen.
• Nada que reanudar. Sin notas, registros, chats ni commits: dilo en una frase y pasa al paso 6 con lo que el usuario quiera hacer.

Cómo se empareja el mismo proyecto entre fuentes

El gestor de proyectos, la bóveda y, si lo hay, el registro de sesión nombran los proyectos cada uno a su manera. Emparejalos por claves, en este orden, y no por el nombre simple:

1. Ruta. Si la configuración escribe un registro de sesión, su ruta contra el campo path: en el frontmatter de la nota de la bóveda (D), como se describe en "Emparejamiento por ruta" en references/session-log.md.
2. Enlace del gestor de proyectos. El campo del gestor de proyectos que apunta a la nota (en Notion, por ejemplo, un campo como "Obsidian note"), contra la carpeta de la nota.
3. Nombre. Sin distinguir mayúsculas/minúsculas y con los alias de la memoria.

Si un proyecto en el gestor de proyectos no enlaza su nota pero la nota existe (coincide por ruta o por nombre), dilo en "Aviso" en una línea.

2. Fuentes, en orden de lectura

Primero lo que indica cuánto vale cada nota (lo que realmente ocurrió y cuándo), luego lo que indica qué viene después, y finalmente el porqué.

B. Registro de sesión, opcional. Si la configuración escribe uno, sigue references/session-log.md.

C. Git y el remoto. Solo con un terminal en el repositorio. Sigue la "Instantánea rápida de git" y la categoría "Estado real de git y el remoto" de references/claude-code.md.

C2. GitHub sin terminal. Úsalo para confirmar lo que las fuentes locales no pueden saber: si una rama fue subida, si tiene un pull request y si fue fusionada. Obtén owner/repository de la nota del proyecto en la bóveda (campo url: o una línea github.com/...), del CLAUDE.md o, si hay un registro de sesión, de sus commits "Merge pull request #N from /...".

• Primero comprueba si la sesión ya tiene acceso con una lectura: gh api "repos/<owner>/<repo>/pulls?state=all&sort=updated&direction=desc&per_page=10". Usa la API REST (gh api repos/...): gh pr list puede fallar porque GraphQL no siempre está disponible. Cada PR tiene created_at y merged_at: cuándo se integró lo indica merged_at, no la fecha de creación.
• Si responde, lee también las ramas (repos/<owner>/<repo>/branches) y los últimos commits en la rama principal (repos/<owner>/<repo>/commits?per_page=5). Con eso, una rama no fusionada que otra fuente nombre se convierte en "tiene PR abierto #N", "fusionada" o "no está en el remoto".
• Lee también la CI de la rama principal (repos/<owner>/<repo>/actions/runs?branch=<main>&per_page=1). Si la última ejecución falló, va en "Pendiente"; si pasó, no la menciones, y si no hay ninguna ejecución (el repositorio no tiene CI), tampoco lo menciones.
• Si responde que el repositorio no está habilitado para la sesión, no lo añadas por tu cuenta: conceder acceso a un repositorio no es solo lectura. Anótalo en "Aviso" y ofrécelo como opción en el paso 5 ("Confirmar en GitHub"). En una sesión sin usuario, omítelo.

A. Gestor de proyectos. Si las instrucciones indican que el estado, la prioridad o la siguiente acción residen en un gestor de proyectos (Notion u otro), léelo: es la fuente para lo que viene después. Obtén la dirección de la base de datos de las instrucciones o del CLAUDE.md; no la busques por nombre si ya la tienes.

• En Notion: obtén el esquema de la base de datos y consulta las filas con su enlace (url), nombre, área o rama, estado, prioridad, fecha clave, siguiente acción y nota.
• Archivado. Elimina las filas que Notion haya archivado y, si la base de datos también tiene su propia casilla de verificación o estado para eso (por ejemplo, una casilla "Archivado" o un estado "Cerrado"), también las que lo tengan marcado.
• Fechas de edición. La consulta no devuelve la fecha de la última edición. Abre la página de las filas que vayas a cotejar con otra fuente y, en un paraguas, también las de los proyectos que las instrucciones marquen como prioridad a corto plazo, aunque no tengan registro ni nota: así los proyectos sin código también pueden aparecer en "Dónde lo dejaste".
• Ediciones masivas. Si varias páginas en la misma base de datos tienen fechas de edición con segundos de diferencia, fue un cambio hecho a todas a la vez (un nuevo campo, una importación, una plantilla), no trabajo en esos proyectos. No uses esa fecha como actividad: deja esos proyectos sin fecha, a menos que otra fuente les dé una.
• Tareas. Si las instrucciones nombran una base de datos de tareas, obtén su esquema y consulta las tareas sin terminar que estén vencidas o venzan en los próximos siete días. Solo cuentan las de proyectos que aparezcan en el resumen: las de proyectos pausados, cerrados o fuera del resumen no están pendientes aunque estén vencidas. Van en "Pendiente" bajo el elemento de su proyecto, con su fecha. Para proyectos prioritarios sin siguiente acción, consulta también sus tareas abiertas sin filtro de fecha (ver más abajo).
• Tareas sin proyecto. No van en "Pendiente". Pero si una coincide con un aviso de "Aviso" (por ejemplo, una tarea para enlazar las notas cuando un proyecto no enlaza la suya), nombra la tarea en ese aviso en lugar de presentarla como un hallazgo nuevo.
• Una fila sin siguiente acción no es un elemento pendiente: no lo inventes. Si el proyecto es prioritario, ponlo en "Pendiente" como "sin siguiente acción". Si tiene tareas abiertas, con o sin fecha, nombra la primera (la de la fecha más próxima, o la primera sin fecha): "sin siguiente acción; tarea abierta: ". Esto son datos del gestor de proyectos, no una sugerencia. Prioridad significa lo que las instrucciones marquen como prioridad a corto plazo, más la primera de sus prioridades a largo plazo; si las instrucciones no establecen prioridades, la prioridad más alta en el gestor de proyectos. Que el gestor de proyectos diga "Alta" no es suficiente cuando las instrucciones establecen otras.
• Si no caben. "Pendiente" tiene como máximo cinco elementos. Si hay más proyectos que incluir, los de corto plazo y los que tienen siguiente acción o algo a medias van primero; los proyectos prioritarios que solo añadirían "sin siguiente acción" se agrupan en una línea de "Aviso": "Sin siguiente acción: X, Y y Z".
• Si el estado del gestor de proyectos contradice claramente otra fuente más reciente (por ejemplo, "Idea" en el gestor de proyectos y la nota de la bóveda con trabajo realizado), dilo en "Aviso" con ambas fechas.

D. Bóveda de Obsidian. La nota del proyecto, en la carpeta de proyectos de la bóveda (las instrucciones o el CLAUDE.md suelen indicarla; en una bóveda de estilo PARA, por ejemplo, 2 Projects/<project>/), y su updated:. Su campo path:, si lo tiene, es una clave para emparejarla (ver paso 1). Lee el encabezado y las entradas más recientes, no toda la nota. No se necesita ninguna skill para leerla. En Claude Code, la referencia indica cuándo ejecutar una skill de bóveda y cuándo no.

• El CLAUDE.md del repositorio. Si se puede alcanzar (un terminal, o la carpeta del repositorio conectada), sus secciones de estado y pendientes ("Estado actual", "Pendientes") son la lista de pendientes más fiable disponible localmente; lee solo esas secciones. Con un terminal, sigue la categoría "CLAUDE.md" de references/claude-code.md.

E. Traspasos. Notas, documentos o archivos que otra persona o una skill de cierre de sesión (por ejemplo, wrap-up) haya dejado en la carpeta del proyecto o en la carpeta de traspasos que especifiquen las instrucciones. Cada uno dice lo que queda por hacer desde el punto de vista de quien lo escribió y, si lo indica, cuándo caduca. Se leen igual que una nota de la bóveda.

F. Chats anteriores. La búsqueda en chats de claude.ai (F) y las sesiones de Claude Code (F2) se rigen por sus referencias. Léelos solo si las otras fuentes no son suficientes para saber dónde se quedó el trabajo.

• Si una fuente ya tiene una entrada con la fecha del último trabajo y lo que se hizo (git, registro de sesión), los chats no añaden información nueva y no es necesario leerlos.
• Búscalos solo cuando no haya suficiente: proyecto sin git, sin registro, sin nota de bóveda, o actividad demasiado antigua.

G. Memoria. Solo si está en el contexto. No ejecutes herramientas de memoria solo para leerla. Si la memoria ya está presente cuando la sesión se abre, léela.

H. Instrucciones y archivos del proyecto de claude.ai. Si la sesión es un proyecto de claude.ai, las instrucciones y los archivos del proyecto son el mapa. El inventario lo detecta.

I. Artefactos (publicados). Solo si una capacidad del inventario los expone. No son commits ni notas: son documentos o páginas publicadas que el equipo acordó como referencia externa. Si no hay herramienta para listarlos, no los leas.

3. Cotejar

Para cada proyecto que tenga varias fuentes, haz dos comprobaciones:

• Fecha de la última actividad. La más reciente de todas las fuentes (git, registro de sesión, nota de la bóveda, página del gestor de proyectos). Incluye solo la fuente y la fecha, no un resumen de lo que ocurrió: el resumen viene a continuación. Para las fechas de la bóveda, la fecha de updated: en el frontmatter es la fecha de la nota; la última entrada de trabajo en el cuerpo puede ser de una fecha diferente —usa la de la entrada, si la hay. Para el gestor de proyectos, las páginas sin fecha (ediciones masivas, ver paso 2) se quedan sin fecha a menos que otra fuente les dé una. Si la fecha más reciente de todas las fuentes es de git, la entrada de git es la actividad.
• Posibles conflictos. Qué dice cada fuente sobre el estado del proyecto, la rama y la siguiente acción. Señala las diferencias: git dice main, el gestor de proyectos dice develop, el traspaso dice que lo está revisando otra persona. No resuelvas el conflicto: preséntalo y deja que el usuario decida.

En un paraguas, haz esto para cada proyecto que entre en el resumen (todos los que tengan actividad y prioridad a corto plazo, más la primera prioridad a largo plazo).

4. Resumen

El resumen se escribe en una conversación, no en un archivo. Quien lo lea debe saber, en cinco líneas como máximo tras leerlo, lo siguiente:

1. Proyecto. Nombre y, en un paraguas, una línea por proyecto con el nombre, la fecha y la fuente.
2. Dónde lo dejaste. Una línea que sintetice el último trabajo ("último commit de ayer en feat/pagos", "registro del viernes: revisando PR").
3. Lo que sigue. Hasta dos líneas con lo que digan las fuentes: siguiente acción, tareas atrasadas, PR sin fusionar.
4. Avisos. Conflictos no resueltos, fuentes importantes fuera de alcance, proyectos sin enlace.

5. Confirmar

Pregunta al usuario: "¿Reanudamos con ?" con un "sí" como opción por defecto y, en un paraguas, una pregunta de selección. Si hay un conflicto (por ejemplo, dos proyectos con el mismo nombre en fuentes diferentes, o la rama de git y la del gestor de proyectos no coinciden), preséntalo y pregunta cuál es el correcto. En una sesión sin usuario, salta este paso.

6. Pregunta final y transferencia

Pregunta "¿En qué te gustaría trabajar hoy?" a continuación del resumen, sin esperar confirmación del usuario para ofrecer la opción. La respuesta se pasa a una skill de selección de skills (por ejemplo, alex20-create/choose-skill) si está instalada; de lo contrario, la sesión continúa con lo que el usuario decida.

Los pasos 0 a 2 leen fuentes; el paso 3 las coteja; los pasos 4 a 6 comunican y transfieren.