permissions-tune

JTBD

"Me pide permiso para todo y me cansa ir dando allow de a uno." El usuario no debería tener que explicar qué va a construir: la evidencia de lo que necesita ya está en disco.

De dónde saca el contexto (sin preguntar)

Comandos

SK="<ruta>/permissions_tune.py"

python3 "$SK" .                  # vista previa (no escribe nada)
python3 "$SK" . --apply          # escribe, dejando backup
python3 "$SK" . --apply --local  # forzar settings.local.json
python3 "$SK" . --apply --shared # forzar settings.json
python3 "$SK" . --revert         # restaurar el último backup
python3 "$SK" . --min-count 1    # bajar el umbral de evidencia

Dónde escribe

Lo decide por proyecto, y siempre lo dice en el reporte:

• Repo con remote → settings.local.json. Puede ser compartido; no se commitea.
• Repo sin remote → settings.json del proyecto.

Se puede forzar con --local / --shared.

Reglas duras (están en el código, no en el prompt)

Un skill que se auto-otorga permisos es una puerta trasera si no tiene límites. Estos están implementados y verificados, no son recomendaciones:

1. Nunca comodines de intérpretes, shells ni package runners. python3:*, node:*, bash:*, npx:*, make:*, eval, ssh — todos equivalen a ejecución de código arbitraria, y permitirlos vuelve decorativa cualquier lista de deny. En su lugar propone el script concreto que el usuario ya corre (Bash(python3 /ruta/al/script.py:*)).
2. Nunca npm run:* ni equivalentes. El nombre del script es parte de la identidad del comando: Bash(npm run build) sí, Bash(npm run:*) no.
3. Nunca destructivos ni de sistema. rm, chmod, chown, kill, pkill, dd, launchctl, crontab, defaults… Si el usuario los quiere, los agrega a mano y asume la decisión.
4. Nunca instaladores. brew install, pip install, npm install, cargo install — instalar software de internet es ejecución de código con otro nombre.
5. Nunca awk / find / xargs con comodín. Tienen system() y -exec.
6. Nunca toca deny ni ask. Solo suma a allow. Sacar una denegación es decisión manual del usuario.
7. Nunca git:* pelado — incluiría push y reset --hard. Solo subcomandos.
8. Descarta lo que Claude Code ya auto-permite (ls, cat, grep, git status, gh pr view…). Una entrada ahí es ruido, no permiso.
9. Solo propone comandos que existan en el sistema (which) y scripts que existan en disco. Sin esto se cuelan fragmentos de rutas con espacios.
10. Por defecto no escribe. Solo con --apply, y siempre con backup.

Behavior spec

1. Corré la vista previa primero y mostrala tal cual. El reporte es el entregable; no lo resumas en tus palabras ni escribas un .md aparte.
2. Explicá el destino. Decí si va a settings.json o settings.local.json y por qué, antes de aplicar.
3. Aplicá solo con el sí del usuario. El default es vista previa a propósito: ampliar permisos es difícil de revertir mentalmente aunque haya backup.
4. Si una propuesta te parece de más, decilo. El script filtra por reglas, no por criterio. Revisá la lista antes de recomendarla.
5. Distinguí permanente de temporal. Si el usuario quiere amplitud "por un rato" (prototipo, sandbox), el allowlist es la herramienta equivocada: deja permisos permanentes por una necesidad de una tarde. Para eso están los permission modes de sesión. Decilo en vez de engordar el archivo.
6. Nunca sugieras desactivar permisos en general ni pases por alto las reglas duras porque el usuario tenga apuro.

Límites conocidos

• Lee los transcripts del proyecto donde corre; no cruza proyectos a propósito.
• La detección de stack cubre Node, Python, Rust, Go, Ruby y Make. Otros stacks caen al camino de evidencia (transcripts + aprobaciones previas).
• No sabe si un comando es peligroso en tu contexto: aplica listas fijas. Revisá la propuesta.