Planning with Files es una skill para agentes de Ahmad Adi que guarda el plan, los hallazgos y el progreso de una tarea en archivos del proyecto. Úsala cuando una tarea de programación o investigación dure lo suficiente como para que una conversación nueva tuviera que reconstruir decisiones anteriores. Los archivos ofrecen al agente un registro que puede leer y actualizar; su utilidad depende de mantenerlos al día y con información correcta.
El punto de partida práctico son tres archivos Markdown: task_plan.md, findings.md, y progress.md. Asigna a cada uno una función distinta. El plan sigue lo que queda pendiente, los hallazgos explican lo aprendido y el progreso registra lo que ha sucedido. Copiar el mismo párrafo en los tres dificulta la recuperación.
Ejemplo ficticio de planificación para Apple; los comentarios citados y los porcentajes son ilustrativos. Abre la ilustración a tamaño completo.
Instala la carpeta completa de la skill
La página de la skill Planning with Files en Thrive proporciona la fuente revisada del editor. Instálala en tu proyecto:
npx usethrive add planning-with-files --agent claudePara Codex, cambia --agent claude por --agent codex. El instalador copia la carpeta completa de la skill fijada a una revisión, incluidas las plantillas y los scripts. Deja intacta una instalación existente, así que revisa la copia instalada antes de sustituirla.
Instalar una skill e instalar un plugin del entorno son operaciones diferentes. El editor también proporciona integraciones para hooks de ciclo de vida y recuperación de tareas. Copiar una carpeta no registra automáticamente todos los hooks del plugin en cada entorno. Si quieres esas integraciones, sigue la documentación de instalación del editor para el agente y el sistema operativo que utilices.
Mantén la skill instalada separada de los archivos de planificación del proyecto. La carpeta instalada contiene scripts y plantillas reutilizables. El directorio de la tarea contiene los registros de tu trabajo actual. El flujo actual del editor puede seleccionar un directorio de tarea; usa su inicializador y la identidad de tarea que muestra cuando ese modo esté habilitado, en lugar de asumir que todas las tareas escriben en la raíz del proyecto.
Asigna a cada archivo una función útil
Archivo | Qué guardar aquí | Qué evitar aquí |
|---|---|---|
| El objetivo, las fases, los criterios de aceptación y la siguiente acción | Una transcripción de todas las llamadas a herramientas |
| Evidencias, enlaces a fuentes, restricciones y motivos de las decisiones | Una conclusión sin respaldo presentada como un hecho |
| Pasos completados, resultados reales de pruebas y fallos sin resolver | Comprobaciones previstas descritas como completadas |
Para una edición breve, estos archivos pueden generar más trabajo del que ahorran. Corregir un encabezado rara vez requiere un sistema de recuperación. Una migración, una investigación con varias fuentes o una funcionalidad con varias dependencias son mejores candidatas, porque la siguiente acción depende de evidencias anteriores.
Ejemplo: planifica una pequeña migración de contenido
Supongamos que vas a trasladar un archivo de boletines a un CMS. Necesitas establecer la correspondencia de títulos, fechas, etiquetas y contenido sin publicar borradores privados. Empieza con un plan que defina el resultado y las comprobaciones:
# Newsletter archive migration
## Objective
Import the approved public archive and preserve draft visibility.
## Phases
- [ ] Inventory source records and classify their visibility.
- [ ] Map source fields to the target content model.
- [ ] Import a small sample and check formatting.
- [ ] Import the approved remaining records.
- [ ] Verify counts, visibility, and representative links.
## Acceptance criteria
- Source and imported approved-record counts match.
- Draft records have no public snapshot.
- Sample links, headings, and publication dates are preserved.
## Next step
Inspect five representative source records before writing the mapper.El ejemplo es una plantilla de planificación, no una afirmación de que se haya completado ninguna migración. Sustituye sus comprobaciones por las que exijan tus sistemas de origen y destino. Si una correspondencia necesita una decisión del editor, registra esa dependencia en lugar de dejar que el agente adivine.
En findings.md, explica una decisión de correspondencia con evidencias. Por ejemplo, «La exportación contiene published_at solo para entradas publicadas; conserva un valor ausente para los borradores» resulta útil si lo has observado en la exportación. Registra el archivo revisado y los campos pertinentes. No escribas esa conclusión solo porque parezca plausible en un CMS.
En progress.md, registra el resultado real de la muestra. «Se han importado cinco registros; un vídeo incrustado necesita una regla de conversión aparte» indica a la siguiente sesión qué queda pendiente. «La migración parece estar bien» no proporciona suficiente información para continuar con seguridad.
Retoma la tarea tras un reinicio del contexto
Pide al agente que lea los tres archivos de la tarea seleccionada e informe de la fase actual, las decisiones sin resolver y la siguiente acción antes de editar. Contrasta ese relato con el repositorio y con cualquier sistema externo que utilice la tarea. Una casilla de Markdown puede estar desactualizada; el agente debe verificar el archivo o resultado correspondiente antes de confiar en ella.
Si el plan dice que las pruebas han pasado, el registro de progreso debe identificar el comando y el resultado. Si dice que un despliegue ha terminado, conserva el identificador o la URL del despliegue. No incluyas secretos en estos archivos, especialmente si el repositorio es compartido. Registra los nombres de las credenciales y los requisitos de acceso en lugar de copiar tokens.
El editor incluye herramientas de recuperación de sesiones con modos explícitos. Usa el modo adecuado para la tarea y el entorno. No interpretes el acceso a un directorio de proyecto como permiso para recopilar registros locales de conversaciones ajenas a la tarea. Un plan de proyecto suele bastar para recuperar el contexto útil de la tarea.
Evita planes desactualizados y ediciones en conflicto
Actualiza el plan cuando cambie una fase y expresa el siguiente paso con un verbo concreto: revisar, comparar, implementar o verificar. Una instrucción vaga como «continuar el desarrollo» obliga a una sesión nueva a reconstruir otra vez la decisión.
Cuando colaboren varios agentes, elige un responsable del plan compartido. Los demás pueden informar mediante sus archivos asignados o mensajes. Así es más fácil conciliar una tarea completada con un fallo recién descubierto. Varios agentes que reescriben por su cuenta el mismo documento de estado pueden ocultar por accidente el trabajo de los demás.
Antes de cerrar la tarea, contrasta los criterios de aceptación con el resultado. Deja visibles los asuntos sin resolver. Planning with Files mejora la continuidad del trabajo de un agente; que su script de finalización acepte un plan no demuestra por sí solo que el trabajo sea correcto.
Qué probar primero
Instala la skill para una tarea que ya preveas que ocupará varias sesiones. Empieza con un objetivo breve, unas pocas fases y una siguiente acción verificable. Tras la primera sesión, abre tú mismo los archivos y comprueba si otra persona podría continuar a partir de ellos. Las decisiones ausentes o las entradas de estado vagas te indican qué mejorar antes de que la tarea crezca.
Para flujos de trabajo que también generen notas de investigación, consulta la skill Obsidian Markdown. Mantén separados los registros de ejecución del proyecto y las notas personales de referencia cuando tengan responsables o requisitos de privacidad distintos.
