Capítulo 1 de 10 · 100 proyectos para hacer con tu coding agent

CLI y automatización (1-10)

Diez herramientas de terminal que vas a acabar usando de verdad. Un renombrador, backups, dotfiles, un cronómetro de tareas y, para terminar, tu propio shell.

6 min de lecturaActualizado el 8 de septiembre de 2026

Si es tu primer proyecto con un agente, empieza por la terminal. No hay que pelearse con CSS, pruebas las cosas al momento y el resultado se nota el mismo día, porque es una herramienta que vas a usar tú. Además, las herramientas de línea de comandos son fáciles de describir en un prompt, y eso ayuda bastante.

1. Renombrador masivo con vista previa

Renombrar 400 fotos con un bucle de mv sale mal una de cada tres veces, y siempre te das cuenta cuando ya es tarde. Esta herramienta acepta un patrón, te enseña el antes y el después, y no toca el disco hasta que confirmas.

Construye una CLI llamada "ren" que renombre ficheros por lotes.

Requisitos:
- Acepta un glob de entrada y un patrón de salida con variables: {n}, {name}, {ext}, {date}.
- Por defecto hace dry-run: imprime una tabla "antes -> después" y no toca nada.
- Solo renombra con --apply, y aborta si algún destino ya existe.
- Guarda un fichero de deshacer para revertir el último lote con "ren undo".

Tests: colisiones de nombres, ficheros sin extensión, y que el dry-run
no escriba en disco. Sin dependencias fuera de la librería estándar.

2. Cronómetro de tareas para la terminal

Un time-tracker de andar por casa: t start "escribir guía", t stop, t report. Sin cuenta, sin nube y sin suscripción mensual. Lo interesante es que todo vive en un fichero que puedes abrir con cualquier editor.

Crea una CLI de seguimiento de tiempo que guarde los registros en un
único fichero JSONL en ~/.local/share/tt/log.jsonl.

Comandos: start <tarea> [--tag], stop, status, report [--hoy|--semana].
El informe agrupa por tarea y por etiqueta, con totales en horas:minutos.
Si haces "start" con un cronómetro abierto, ciérralo antes y avísame.

Criterio de aceptación: el fichero es legible a mano, cada línea es un
registro válido y borrar la última línea deja el estado consistente.

3. Gestor de dotfiles con enlaces simbólicos

Todo el mundo acaba escribiendo uno de estos, así que mejor hacerlo bien. La clave está en que detecte conflictos antes de pisar ese .zshrc que llevas cinco años afinando.

Escribe una herramienta que gestione dotfiles desde un repositorio git.

- "link" crea enlaces simbólicos de repo/home/* a ~/ respetando la estructura.
- Si el destino existe y no es un enlace nuestro, hace copia .bak y avisa.
- "status" muestra qué está enlazado, qué falta y qué difiere.
- "adopt <fichero>" mueve un fichero existente al repo y lo enlaza.

Todo debe ser idempotente: ejecutarlo dos veces no cambia nada la segunda.

4. Buscador de ficheros duplicados

Recorre un directorio, agrupa por tamaño y solo entonces calcula hashes. Ese orden es todo el proyecto: si te pones a hashear 200 GB directamente, tienes para toda la tarde.

Haz una CLI que encuentre ficheros duplicados en un directorio.

Estrategia obligatoria: agrupar primero por tamaño, luego comparar los
primeros 4 KB, y solo hashear (BLAKE3 o SHA-256) los candidatos que sigan
coincidiendo. Muestra el espacio recuperable al final.

Flags: --min-size, --json, --delete (interactivo, conserva el más antiguo).
Debe manejar enlaces simbólicos sin entrar en bucles infinitos.

5. Backup incremental a un disco externo

No es que vayas a sustituir a rsync, es que vas a entender cómo funciona. Snapshots por fecha con hard links, de forma que diez copias ocupen poco más que una.

Implementa una herramienta de backup incremental estilo Time Machine.

Cada ejecución crea un directorio snapshots/YYYY-MM-DD-HHMM. Los ficheros
sin cambios se enlazan (hard link) al snapshot anterior en lugar de copiarse.
Lee las exclusiones de un fichero .backupignore con sintaxis tipo gitignore.

Incluye "restore <snapshot> <ruta>" y "prune --keep-daily 7 --keep-weekly 4".
Explícame en el README por qué los hard links hacen que esto ocupe poco.

6. Cliente HTTP de terminal con colecciones

Un curl con memoria. Guarda las peticiones en ficheros de texto, las agrupa por entorno y se acuerda del token entre una llamada y la siguiente. Es de esas herramientas que, una vez hechas, ya no sueltas.

Crea un cliente HTTP para terminal que lea peticiones desde ficheros .http
(sintaxis tipo REST Client: método, URL, cabeceras, cuerpo).

- Variables por entorno en env.json: {{base_url}}, {{token}}.
- Extracción de valores de la respuesta a variables para la siguiente petición.
- Salida coloreada, con --raw para pipes y --json para procesar con jq.
- Historial de las últimas 50 peticiones, repetible con "rerun <n>".

Los secretos nunca se imprimen en el historial ni en los logs.

7. Vigilante de directorios que ejecuta comandos

Es la base de cualquier flujo de recarga automática. La parte con miga es detectar cambios sin quemar la CPU con un bucle de ls cada segundo.

Construye un "watch" que ejecute un comando cuando cambien ficheros.

Uso: watch --ext go,templ --ignore vendor -- go test ./...

Requisitos: usa la API de eventos del sistema (inotify/FSEvents/ReadDirectoryChangesW),
aplica debounce de 200 ms, y mata el proceso anterior antes de lanzar el nuevo.
Salida limpia: una línea por evento, sin repetir el mismo cambio tres veces.

Prueba que un "guardar" de un editor (que a veces son tres eventos) dispara
una sola ejecución.

8. Gestor de snippets con búsqueda difusa

Todos tenemos un comandos.txt por ahí que nunca encontramos cuando hace falta. Esto lo convierte en algo que puedes buscar desde la terminal en dos teclas.

Haz una CLI de snippets de comandos con búsqueda difusa interactiva.

- "snip add" abre el editor para guardar comando + descripción + etiquetas.
- "snip" sin argumentos abre un selector interactivo en la terminal.
- Al elegir, copia el comando al portapapeles o lo imprime para eval.
- Soporta placeholders: los pide uno a uno antes de devolver el comando.

Implementa el algoritmo de coincidencia difusa a mano y explícalo en el código.

9. Multiplexor de procesos para desarrollo

Levantar la API, el front y la base de datos con un solo comando, y que un Ctrl-C lo mate todo sin dejar procesos zombis por detrás. Parece fácil hasta que lo intentas.

Escribe un ejecutor de procesos en paralelo configurado por YAML.

processes:
  api: {cmd: "npm run dev", cwd: "./api", ready: "listening on"}
  web: {cmd: "npm run dev", cwd: "./web", depends_on: [api]}

- Prefija cada línea de salida con el nombre del proceso y un color estable.
- "depends_on" espera al patrón "ready" del proceso del que depende.
- Ctrl-C envía SIGTERM a todo el grupo y SIGKILL a los 5 segundos.
- Si un proceso muere, muestra su código de salida y para el resto.

10. Tu propio shell

De los diez, el que más enseña por línea escrita. Parseo, fork, exec, tuberías, redirecciones, señales. En un fin de semana tienes algo capaz de ejecutar ls | grep foo > out.txt, y cuando lo consigues la terminal deja de ser una caja negra.

Implementa un shell POSIX mínimo en C (o Rust/Go si prefieres).

Fases, y quiero commit al final de cada una:
1. REPL que ejecuta comandos con argumentos (fork + execvp + waitpid).
2. Tuberías de N etapas y redirecciones <, >, >>.
3. Builtins: cd, exit, export, pwd (explica por qué cd no puede ser externo).
4. Job control básico: &, jobs, fg, y manejo correcto de SIGINT.
5. Historial persistente y expansión de ~.

Ve explicándome qué hace cada llamada al sistema mientras la escribes.