Revisada el 2026-10-12
Skill de Claude Code que ordena un proyecto, deja git al día tras confirmar y entrega un resumen ejecutivo de su estado.
Se invoca a demanda, con «limpia el proyecto» o con /limpiar-proyecto. Nunca borra sin confirmación: lo que sobra se archiva. El método explicado paso a paso está en Ordenar un proyecto con Claude Code.
| Datos clave | |
|---|---|
| Formato | Skill de Claude Code (SKILL.md)1 |
| Idioma | Español |
| Instalación | Global: ~/.claude/skills/limpiar-proyecto/SKILL.md. Solo un proyecto: .claude/skills/limpiar-proyecto/SKILL.md1 |
Prompt
Copia el bloque completo en un archivo SKILL.md. La cabecera inicial (name y description) es la que usa Claude Code para decidir cuándo ofrecer la skill.1
---
name: limpiar-proyecto
description: Revisa las carpetas del proyecto en el que está abierta la sesión y propone limpiarlo: handoffs y borradores obsoletos, duplicados, cachés y ficheros que no pertenecen al proyecto. Comprueba también el estado de git (cambios sin commitear, push pendiente) y lo deja al día tras confirmar. Termina con una foto ejecutiva del proyecto (edad, tamaño, carpetas, git, sesiones). Recuerda de qué va el proyecto antes de proponer nada. Nunca borra sin confirmación; lo que sobra se archiva en output/archivo/. Actívala cuando el usuario diga "limpiar proyecto", "limpia el proyecto", "hay mucho desorden", "revisa las carpetas" o "/limpiar-proyecto".
---
Esta skill hace una pasada de orden sobre un proyecto con dos objetivos en cada ejecución: (1) dejarlo limpio y con git al día (commit y push, previa confirmación) y (2) entregar una foto ejecutiva, breve, del estado real del proyecto. No decide por el usuario: presenta un informe, pregunta por grupos de archivos y aplica solo lo que se confirma. Está pensada para proyectos con carpetas como `contexto/`, `docs/`, `output/`, `inputs/` y `credentials/`; si falta alguna, la omite sin error. Si el proyecto usa otros nombres, adáptalos en el texto antes de usarla.
## 0. Principios
- Nada se borra sin confirmación explícita. Lo que sobra se mueve a `output/archivo/<AAAA-MM-DD>/`, conservando la ruta relativa original.
- Nunca se sobrescribe un original. Si el destino ya existe, se añade un sufijo `-2`, `-3`, etc.
- No se toca `~/.claude` (skills, memoria, configuración). Si algo de allí parece sobrar, solo se informa.
- No se toca nunca: `credentials/`, `contexto/`, `CLAUDE.md`, `CLAUDE.local.md`, `.git/`, `inputs/` y `output/finales/`. En esas carpetas solo se señala lo que parezca sobrar y se pregunta.
- Fecha de hoy: la que indique el sistema. Todos los nombres de archivo nuevos llevan `AAAA-MM-DD`.
## 1. Identificar el proyecto
1. Usa la carpeta de trabajo de la sesión, o la ruta que indique el usuario. Si no hay repositorio git ni `CLAUDE.md`, pregunta cuál es el proyecto antes de seguir.
2. Lee `CLAUDE.md` del proyecto (si existe) y `contexto/objetivo.md`.
3. Si `contexto/objetivo.md` no existe, pregunta al usuario de qué va el proyecto (qué busca, para quién, estado actual). Con su respuesta crea `contexto/objetivo.md` con fecha de creación. Es la única escritura permitida antes de confirmar.
## 2. Recordar la línea del proyecto
Antes de proponer nada, muestra un resumen de 3 a 5 líneas: qué es el proyecto, qué se entrega y dónde están los entregables. Así el usuario puede detectar enseguida si algún fichero no encaja.
## 3. Inventario
Recorre el proyecto excluyendo `.git/`, `node_modules/` y `credentials/`, y recoge por cada fichero: ruta, tamaño, fecha de última modificación y si está en git (`git ls-files`, `git status --porcelain`).
### Estado de git (antes de limpiar)
Si hay repositorio, recoge y anota: rama actual, si hay remoto (`git remote -v`), cambios sin commitear (`git status --porcelain`: modificados, borrados, sin seguimiento), commits por delante o por detrás del remoto (`git rev-list --left-right --count @{u}...HEAD`; si no hay upstream, dilo) y fecha del último commit y del último push. Si no hay repositorio o no hay remoto, se anota en el informe y se pasa al siguiente paso sin error.
## 4. Clasificar
Agrupa los hallazgos en estas categorías:
- Handoffs obsoletos. Los handoffs están en `docs/sesiones/` con nombre `handoff-AAAA-MM-DD.md` (o `handoff.md` heredado). Conserva el más reciente. Un handoff más antiguo es candidato si su contenido ya figura en `contexto/decisiones.md` o en `docs/registro-cambios/`.
- Borradores superados. En `output/borradores/`, un borrador es candidato si ya existe un fichero con el mismo tema en `output/finales/`.
- Duplicados. Mismo contenido (compara hash) o nombres que solo cambian en un sufijo de copia (`copia`, `(1)`, `-v2` si la v2 existe y es posterior).
- Cachés y basura regenerable: `.DS_Store`, `__pycache__/`, `.wrangler/`, `*.log` antiguos. Se pueden borrar tras confirmación de grupo, no uno a uno.
- Sin tocar en más de 30 días y sin referencias desde `CLAUDE.md`, `contexto/` ni `docs/`. Se señala como candidato, nunca como obsoleto automático.
- Ajenos al proyecto: ficheros que, por el nombre o el contenido, no encajan con el objetivo del paso 2. Para cada uno propón un destino probable (otro proyecto, o revisar a mano) y deja la decisión al usuario.
## 5. Informe
Guarda el informe en `docs/registro-cambios/limpieza-AAAA-MM-DD.md` con estas secciones: resumen del proyecto, hallazgos por categoría (ruta, tamaño, motivo), qué se propone hacer y qué queda pendiente de decisión. Muestra en el chat solo el resumen y el número de elementos por categoría.
## 6. Preguntar por grupos
Pregunta una categoría cada vez, no fichero a fichero. Para cada grupo, las opciones son: archivar, borrar (solo grupos de cachés o duplicados idénticos), dejar tal cual o revisar uno a uno. Si el usuario no responde a un grupo, no se toca.
## 7. Aplicar
- Archivar: mover a `output/archivo/AAAA-MM-DD/` con la ruta relativa original. Antes de mover, comprueba que el destino no existe.
- Borrar: solo los ficheros confirmados, y listados en el chat antes de borrarlos. Los que estén en git se pueden recuperar con `git`; los que no, no. Avísalo en el mismo mensaje.
- Ficheros ajenos: solo se mueven si el usuario indica el destino. Si el destino es otro proyecto, no se copia nada allí sin confirmación: se deja una nota en el informe.
- El commit y el push no se hacen aquí, sino en el paso 8, siempre tras confirmar.
## 8. Git al día
Se hace después de aplicar la limpieza, para que el commit recoja el estado final.
1. Vuelve a ejecutar `git status --short` y confirma que lo movido aparece como eliminado y lo archivado como nuevo.
2. Si hay cambios sin commitear, muestra la lista agrupada (modificados, borrados, nuevos) y pregunta: commit con todo, commit solo de una parte o dejarlo tal cual.
3. Antes de proponer un commit, comprueba que no entra nada sensible: `credentials/`, `CLAUDE.local.md`, `.env*`, claves o ficheros que `.gitignore` debería cubrir. Si algo así aparece sin ignorar, avisa y no lo incluyas.
4. Propón el mensaje de commit (español, una línea clara, qué cambia) y espera confirmación. Termina el mensaje con la línea de atribución indicada por el sistema, si la hay.
5. Con el commit hecho, si hay remoto, pregunta si hacer push. Nunca fuerza (`--force`) ni cambia de rama sin pedirlo. Si el push falla, dilo tal cual con el error y no reintentes de forma distinta sin consultar.
6. Si no hay remoto o no hay upstream, informa y pregunta si se quiere configurar; no lo configures por tu cuenta.
7. Si el usuario rechaza el commit o el push, queda anotado como pendiente en la foto final.
## 9. Verificar y registrar
1. Comprueba que `output/archivo/AAAA-MM-DD/` contiene todo lo movido, con el mismo número de ficheros.
2. Añade a `docs/registro-cambios/limpieza-AAAA-MM-DD.md` la lista final: creados, movidos, borrados y pendientes.
## 10. Foto del proyecto (informe ejecutivo)
Es el cierre de cada ejecución. Una pantalla, sin relleno: tablas o viñetas cortas, nada de párrafos largos. Se muestra en el chat y se añade al final de `docs/registro-cambios/limpieza-AAAA-MM-DD.md` bajo el título «Foto del proyecto». Se calcula con el estado de después de la limpieza y el commit.
Contenido, en este orden:
- Veredicto en una línea: p. ej. «Limpio y al día» o «Limpio, 3 cambios sin commitear».
- Vida del proyecto: fecha de creación (primer commit: `git log --reverse --format=%cs | head -1`; si no hay git, la fecha más antigua de los ficheros), días vivo hasta hoy, fecha de la última actividad.
- Tamaño: peso total del proyecto sin `.git/` y peso de `.git/` (en macOS `du` no tiene `--exclude`: mide `du -sk .` y `du -sk .git` y resta), nº de carpetas, nº de ficheros, y peso de `output/archivo/`. Si se ha hecho limpieza: tamaño antes → después y espacio liberado.
- Contenido: ficheros por carpeta de primer nivel (solo las 5 mayores), y nº de ficheros en `contexto/`, `output/finales/` y `output/borradores/`.
- Git: rama, nº de commits, último commit (fecha y mensaje), cambios sin commitear, commits pendientes de push, remoto.
- Trabajo con Claude: nº de sesiones de Claude Code y fecha de la última (ficheros `*.jsonl` en `~/.claude/projects/<ruta del proyecto con / cambiada por ->`; solo se cuentan y se lee su fecha, no su contenido), nº de handoffs en `docs/sesiones/` y fecha del último, nº de entradas en `docs/registro-cambios/`. Si alguna ruta no existe, se pone «n/d».
- Esta ejecución: archivado (nº), borrado (nº), pendiente de decisión (nº).
- Pendientes, como máximo 3 líneas.
Reglas del informe:
- Máximo unas 25 líneas. Si algo no aporta, se quita.
- Cifras reales, medidas en el momento. Lo que no se pueda medir se marca «n/d»; nunca se estima.
- Sin análisis ni recomendaciones largas. Solo datos y el veredicto.
- Fechas en formato AAAA-MM-DD y tamaños en unidades legibles (MB, GB).
## Lo que no hace
- No reorganiza la estructura de carpetas del proyecto: eso lo decide el usuario aparte.
- No toca `~/.claude`, unidades externas ni otros proyectos.
- No ejecuta comandos de despliegue ni cambia DNS.
- No hace commit ni push sin confirmación explícita, ni fuerza el push, ni reescribe el historial.
- No revisa el contenido de los ficheros de `credentials/`.Cómo adaptarla
- Los nombres de carpeta (
contexto/,docs/sesiones/,output/archivo/,docs/registro-cambios/) son un convenio. Cámbialos por los del proyecto, en todo el texto. - Si el proyecto no tiene un archivo de objetivo, la skill lo pide la primera vez; ajusta ese paso si prefieres otro lugar.
- El umbral de 30 días sin tocar y el tope de 25 líneas de la foto final son ajustables.
- Prueba primero en un proyecto sin datos sensibles y con git, para comprobar qué propone antes de confirmar nada.
Referencias
Footnotes
-
Extend Claude with skills. Anthropic, documentación de Claude Code. Consultado el 2026-10-10. ↩ ↩2 ↩3