komilovsg/f-mode

Modo F — modo filtro primero

Principio: los datos brutos nunca entran en el contexto; solo el resultado. Mueve la lógica a los datos (un pipeline de shell, un script corto, un subagente) y trae de vuelta un resumen compacto. Cada token de un volcado de logs que lees es un token que no puedes gastar en razonamiento — y un contexto largo y ruidoso empeora el razonamiento, no solo lo hace más caro.

1. Filtrar y agregar antes de leer

En lugar de	Haz
cat app.log	grep -c ERROR app.log; luego `grep -E 'ERROR
leer un JSON de 5 MB	`jq '.items
SELECT * FROM orders	SELECT status, count(*) FROM orders GROUP BY 1
git log	git log --oneline -20, git log --format=%s origin/main..HEAD
desplazar un archivo	grep -n 'def handle' file.py, luego leer con offset/límite

2. El filtrado nunca debe ocultar fallos

Una vista truncada que parece verde es peor que ninguna vista.

• Conserva el código de salida: set -o pipefail, o cmd > out.txt 2>&1; echo "exit=$?"; tail -20 out.txt. Piping directamente a tail pierde el código de salida del comando.
• Grep marcadores de fallo además de tail: grep -cE 'FAIL|ERROR|Traceback|panic' out.txt.
• Imprime conteos con denominadores: pasaron 41/42, nunca solo "OK".

pytest -q --tb=short > /tmp/t.out 2>&1; echo "exit=$?"
grep -cE 'FAILED|ERROR' /tmp/t.out; tail -15 /tmp/t.out

3. Muchas comprobaciones similares → un script, una tabla

Diez endpoints, veinte archivos, treinta filas para validar: escribe un script que itere e imprima una tabla compacta (nombre | estado | detalle) más totales. No diez llamadas a herramientas con diez salidas completas.

for u in / /api/health /api/items; do
  printf "%-14s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "localhost:8000$u")"
done

4. Verifica el resumen por su significado, no por su forma

Un resultado con apariencia válida puede seguir siendo incorrecto. Compáralo con un valor esperado o un total de cordura: los conteos suman al tamaño de entrada, una fila conocida está presente, el número de archivos coincide con ls | wc -l. Si un resumen no se puede verificar, dilo.

5. Tests

Modo silencioso, trazas cortas, cola de la sección de fallos:

• pytest -q --tb=short
• vitest run --reporter=dot, jest --silent
• go test ./... 2>&1 | grep -E '^(FAIL|ok|---)'
• cargo test -q

6. Comprobaciones en el navegador

Evalúa un script que devuelva JSON compacto ({title, errors: n, buttons: n, overflowX: bool}) en lugar de instantáneas DOM completas. Toma una instantánea solo cuando la estructura DOM en sí es la pregunta. Capturas de pantalla para comprobaciones visuales, no para leer texto.

7. Investigación amplia → subagente

Búsquedas grandes, análisis forense de logs, volcados de base de datos: delega a un subagente que devuelva conclusiones con referencias archivo:línea. Su resultado sigue siendo una afirmación — verifica los puntos clave antes de actuar sobre ellos.

8. Secretos y datos personales

Nunca imprimas secretos o PII reales en resúmenes o diagnósticos. Enmascara (postgres://***) o cuéntalos (correos encontrados: 12). Enmascara cadenas de conexión y claves dentro de mensajes de excepción capturados también.

9. Lectura de archivos

• grep -n primero, luego solo el rango relevante con offset/límite.
• El código fuente que estás a punto de editar se lee completo — las lecturas parciales causan ediciones rotas.
• No vuelvas a leer un archivo justo después de editarlo para "verificar"; la herramienta de edición ya informa errores en caso de fallo.

10. Regla de parada

La misma corrección falló dos veces → para. Encuentra la causa raíz desde la línea exacta del error, o pregunta. Sin tercer reintento ciego.

11. Higiene del contexto

• Limpia el contexto entre tareas no relacionadas; compacta sesiones largas.
• Deshabilita plugins, skills y servidores MCP que no uses en este proyecto: cada uno cuesta tokens de prompt en cada solicitud.
• Juzga los ahorros por números reales de uso (ej. /cost), no por porcentajes declarados.