claude-code-arcane 2.1.0 → 2.3.0

package/skills/audio-spec/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: audio-spec
+description: "SFX spec sheets y audio event lists: trigger, prioridad, concurrencia, cooldown, variaciones, propiedades espaciales. Usar para: especificar sonidos, event list por sistema, brief para sound designer."
+category: "audio"
+argument-hint: "[system-name | all | events]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+# audio-spec — SFX Specs & Event Lists
+
+Convierte dirección sonora en especificaciones que un sound designer externo puede producir sin más briefing, y en event lists que un programador puede implementar sin adivinar.
+
+Dos entregables distintos y complementarios:
+- **Spec sheet** — describe *el sonido*: cómo suena, cuánto dura, cuántas variantes
+- **Event list** — describe *el contrato*: qué lo dispara, con qué prioridad, cuántas instancias, qué parámetros recibe
+
+## Cuándo usar
+
+- Después de `/audio-bible` (la dirección tiene que existir primero)
+- Cuando vas a tercerizar producción de SFX y necesitás un brief cerrado
+- Cuando el código necesita saber qué eventos postear antes de que existan los assets
+- Antes de `/middleware-integration` — la event list es su input
+
+## Modos
+
+| Modo | Qué hace |
+|---|---|
+| `system-name` | Especifica un sistema concreto: spec sheets + event list de, por ejemplo, `combat` |
+| `all` | Barre todos los sistemas del proyecto, uno por vez |
+| `events` | Solo la event list, sin spec sheets. Para cuando el código necesita el contrato antes de que existan los assets |
+
+## Input
+
+1. Leer audio bible (paleta, frequency allocation, mix hierarchy, standards). Si no existe, avisar y ofrecer `/audio-bible` primero
+2. Identificar el sistema a especificar (combate, locomoción, UI, ambiente, props...) o `all`
+3. Leer el código/GDD del sistema para extraer los momentos que piden sonido
+4. Preguntar al usuario: nivel de detalle (spec completo vs event list sola) y si hay assets existentes que reusar
+
+---
+
+## Spec sheet — campos obligatorios
+
+Cada sonido lleva estos campos. Un campo vacío es una decisión que alguien va a tomar por vos:
+
+| Campo | Qué define | Ejemplo |
+|---|---|---|
+| **ID** | Nombre canónico, matchea naming del bible | `sfx_weapon_shotgun_fire` |
+| **Descripción** | Qué es, en una línea funcional | Disparo de escopeta de doble caño, seco, sin cola de reverb |
+| **Referencias** | 1-3 sonidos concretos con qué tomar de cada uno | — |
+| **Carácter frecuencial** | Dónde vive, contra la allocation del bible | Sub-punch 50-70 Hz + crack 3-5 kHz, vacío en mids |
+| **Duración** | Rango, no valor único | 180-260 ms |
+| **Envolvente** | Attack / body / tail explícitos | Attack <5 ms, body 60 ms, tail 120 ms |
+| **Rango de volumen** | Nivel relativo a la categoría | −6 dB a −3 dB del bus SFX |
+| **Propiedades espaciales** | 2D/3D, curva de atenuación, min/max distance | 3D, 2-40 m, log |
+| **Variaciones** | Cuántas variantes y qué randomización | 5 variantes, pitch ±3%, volumen ±1.5 dB |
+| **Prioridad** | Qué se cae primero bajo presión de voces | Alta (feedback de acción del jugador) |
+
+## Event list — campos obligatorios
+
+| Campo | Qué define |
+|---|---|
+| **Evento** | Nombre que postea el código |
+| **Trigger** | Condición exacta de gameplay que lo dispara |
+| **Sonidos** | Qué IDs de spec resuelve (uno o un container) |
+| **Concurrencia** | Máximo de instancias simultáneas + qué hacer al exceder (drop oldest / drop newest / reject) |
+| **Cooldown** | Mínimo entre disparos, para eventos que pueden spamearse |
+| **Parámetros** | RTPCs que recibe, con rango normalizado |
+| **Stop condition** | Cómo termina: one-shot, loop con stop explícito, o fade |
+
+**Concurrencia y cooldown no son opcionales.** Son la diferencia entre un sistema que sobrevive 40 enemigos en pantalla y uno que satura el voice budget. Todo evento que puede dispararse más de una vez por frame necesita ambos.
+
+---
+
+## Proceso
+
+1. **Barrer el sistema** — listar cada momento que pide sonido, incluyendo los negativos (dónde el silencio es la decisión)
+2. **Agrupar** — sonidos que comparten carácter van juntos; identificar qué puede ser variación de un mismo asset en vez de asset nuevo
+3. **Draftar** specs y event list del grupo
+4. **Presentar** al usuario para review
+5. **Escribir** — preguntar "¿Escribo el spec de `<sistema>` a `<path>`?" antes de usar Write
+
+No batchear sistemas: cerrar uno antes de abrir el siguiente.
+
+### Reducción de assets
+
+Antes de especificar N sonidos nuevos, preguntar si el caso se resuelve con variación o con síntesis. El caso canónico: 20 samples × 6 superficies × 3 intensidades = 360 archivos (~180 MB) vs footsteps procedurales (~50 KB) con variación infinita. Si el sistema es de alta frecuencia y muchas dimensiones, derivar a `/procedural-audio` antes de escribir el spec.
+
+---
+
+## Verdict
+
+Por sistema especificado:
+
+- **READY** — todo sonido tiene los 10 campos, todo evento tiene concurrencia y cooldown. Un externo puede producir y un programador puede implementar
+- **CONCERNS** — hay campos vacíos o eventos sin límites; listar cuáles
+- **BLOCKED** — falta el audio bible, o el sistema de gameplay no está definido lo suficiente para saber qué momentos existen
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/middleware-integration` para implementar la event list en Wwise/FMOD
+- `/procedural-audio` para los sistemas de alta frecuencia que no conviene samplear
+- `/sfx-design` para profundizar el diseño de los sonidos hero
+- `/audio-audit` para verificar los assets entregados contra el spec

package/skills/audio-spec/references/anti-patterns.md

@@ -0,0 +1,45 @@
+# Audio Spec — Anti-patterns
+
+## Spec sin números
+
+"Impacto potente y satisfactorio" no es producible. Duración, envolvente, bandas de frecuencia y nivel relativo sí. Si el campo no tiene número o rango, no está especificado.
+
+## Duración como valor único
+
+"200 ms" fuerza al sound designer a mentir o a pedir aprobación. Un rango (180-260 ms) le da lugar a que el sonido termine donde tiene que terminar.
+
+## Eventos sin concurrencia
+
+El spec dice "sonido de casquillo al caer". Llegan 40 enemigos, 300 casquillos, el voice budget explota y el mix desaparece. Todo evento que puede dispararse más de una vez por frame necesita máximo de instancias y política de descarte.
+
+## Cooldown ausente en eventos de UI
+
+Navegación rápida en un menú dispara el mismo tick 15 veces en 200 ms. Suena como un glitch. Cooldown mínimo, siempre.
+
+## Una variante
+
+Un sonido sin variantes se vuelve audible como *sonido* en vez de como evento en unos 20 minutos de juego. Si el evento es frecuente, mínimo 4-5 variantes o randomización de pitch, y preferentemente ambas.
+
+## Pitch randomization exagerada
+
+±3% es variación. ±20% cambia el objeto: el arma parece otra arma. Rango chico y round-robin le gana a rango grande.
+
+## Specs 3D sin curva
+
+Marcar "3D" y no definir min/max distance ni forma de la curva deja la atenuación en el default del middleware, que casi nunca es el correcto. El sonido se oye a 200 m o desaparece a 3 m.
+
+## Especificar antes de decidir procedural
+
+Escribir 360 spec sheets de footsteps es trabajo perdido si la respuesta correcta era síntesis. Evaluar el eje frecuencia × dimensiones antes de especificar.
+
+## Event list sin stop condition
+
+Los loops son la fuente número uno de audio colgado. Todo sonido que loopea necesita decir explícitamente quién lo para y qué pasa si el objeto dueño se destruye primero.
+
+## Prioridades todas iguales
+
+Si todo es prioridad alta, el voice limiter descarta al azar y se cae el feedback de la acción del jugador antes que un ambiente lejano. Las prioridades solo sirven si están diferenciadas.
+
+## IDs que no siguen el naming del bible
+
+`shotgun2_FINAL_v3` rompe búsqueda, batch processing y automatización de banks. El ID sale del pattern del bible, sin excepciones.

package/skills/career-registry/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: career-registry
+description: "Traceability across the whole career workspace: check whether you already applied somewhere before spending another application, export everything to CSV, and audit the registry for gaps and drift. Covers job applications, freelance proposals and contracts. Triggers: ya me postule a, ya aplique aca, exportar postulaciones a csv, registro de aplicaciones, trazabilidad, historial de postulaciones, cuantas mande, planilla de postulaciones, auditar el registro."
+argument-hint: "[check <empresa|url> | export | stats | audit]"
+category: "career"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+# Career Registry - Trazabilidad y registro
+
+Contestás la pregunta que grepear a mano contesta mal: **¿ya me postulé acá?** Y das el registro completo en CSV para mirarlo en una planilla.
+
+Sirve a los dos perfiles: `+job-hunt` (empleo) y `+freelance` (proyectos). Rutas relativas al career workspace (`--workspace`, env `CAREER_WORKSPACE`, o `./career-workspace/`).
+
+Modo: `$ARGUMENTS`
+
+## La regla que sostiene todo esto
+
+**Las notas son la fuente de verdad. El CSV se deriva de ellas, siempre.**
+
+No hay una segunda base que mantener sincronizada, y no la va a haber: una segunda base diverge en dos semanas y después nadie sabe cuál miente. Es el mismo flujo unidireccional que el dedup de `/job-scrape` (`seen_jobs` → nota → vista, nunca de vuelta).
+
+Consecuencia práctica: si el CSV está mal, se arregla la nota, no el CSV. Y si el usuario pide "guardame el CSV para editarlo a mano", avisale que en la próxima corrida se pisa.
+
+## Los cuatro modos
+
+```bash
+python .claude/skills/career-registry/scripts/career_registry.py check "Acme"
+python .claude/skills/career-registry/scripts/career_registry.py check "https://www.linkedin.com/jobs/view/123"
+python .claude/skills/career-registry/scripts/career_registry.py export --csv registro.csv
+python .claude/skills/career-registry/scripts/career_registry.py stats
+python .claude/skills/career-registry/scripts/career_registry.py audit
+```
+
+### `check` - antes de gastar otra postulación
+
+Busca por **tres claves** porque el usuario pega cualquiera de las tres: nombre de la contraparte, URL de la oferta, o título de la nota.
+
+Es tolerante donde importa: `acme` encuentra a "Acme Inc" (ignora sufijos legales), `tecnologia latam` encuentra a "Tecnología Latam SA" (ignora acentos), y una URL con `?utm_source=...` distinto encuentra la misma oferta (canoniza el link, igual que el dedup).
+
+Devuelve un veredicto de tres valores, y la diferencia entre los dos primeros importa:
+
+| Veredicto | Qué significa |
+|---|---|
+| `YA TE POSTULASTE` | Hay una nota en estado enviado. No repitas |
+| `YA LO VISTE, NO TE POSTULASTE` | Hay nota o entrada de dedup, pero nunca se envió. Vale revisarla antes de descartarla de nuevo |
+| `SIN REGISTRO` | Nunca apareció |
+
+Cuándo correrlo: **antes de `/client-screen` o `/job-aplicar`**, cuando el nombre suena conocido. Un screen sobre algo que ya descartaste hace tres meses es trabajo repetido, y peor, te hace repetir el descarte sin recordar por qué.
+
+### `export` - el CSV
+
+Una fila por nota, con `tipo` discriminando empleo / freelance / contrato. Columnas: contraparte, título, estado, si está abierta, plataforma, `match_score`, riesgo del cliente, perfil usado, bid o monto, costo de postularse, fechas, **días sin movimiento**, link y la ruta de la nota.
+
+Sin `--csv` va a stdout; con `--csv <archivo>` lo escribe en UTF-8 con BOM para que Excel no rompa los acentos. `--tipo` filtra a un solo tipo.
+
+`dias_sin_movimiento` es la columna más útil de la planilla: ordenando por ahí aparece lo que quedó colgado.
+
+### `stats` - conteos
+
+Total y abiertas por tipo, desglose por estado, cuántas se enviaron y el costo de postulaciones registrado.
+
+Trae `muestra_suficiente_para_tasas`: **con menos de 10 enviadas es `false`, y ahí no hay que calcular tasas de conversión**. Diez rechazos no son un patrón, y tratarlos como tal manda al usuario a arreglar lo que no estaba roto.
+
+### `audit` - las divergencias
+
+Lo que hace que la trazabilidad sea real y no una intención:
+
+- Notas sin `estado` o sin contraparte
+- Enviadas sin fecha de envío (rompe cualquier cálculo de tiempos)
+- **Abiertas frenadas hace 21+ días** - candidatas a follow-up con `/cold-outreach` o a cerrar como `sin_respuesta`
+- Posibles duplicados: misma contraparte, mismo título, dos notas
+- **Contratos con horas reales arriba de lo estimado**, con el exceso en horas y en porcentaje. Cada uno es trabajo regalado si no hubo change order
+- Punteros del dedup que apuntan a notas que ya no existen
+
+## Proceso
+
+1. Correr el modo pedido. Si el workspace no existe, el script lo dice y sugiere `/freelance-hunt setup` o `/job-hunt setup`.
+2. **Mostrar el resultado en el chat, no solo el JSON crudo.** Para `check`, el veredicto y una línea por coincidencia con su estado. Para `audit`, agrupado por severidad: primero lo que cuesta plata (horas de más, enviadas sin fecha), después lo cosmético.
+3. Para cada hallazgo de `audit`, ofrecer la acción concreta: follow-up, cerrar como `sin_respuesta`, change order, o completar el campo que falta.
+4. Los arreglos se hacen **en la nota** con approval del usuario, una por una. Nunca en masa.
+
+## Reglas
+
+- **Nunca editar el CSV como si fuera la fuente de verdad.** Se regenera; los cambios van a la nota.
+- **No editar notas en masa.** Cada arreglo se muestra y se aprueba.
+- Nunca inventar un dato que falta: si una nota no tiene fecha de envío, se pregunta o se deja el hueco reportado.
+- No cambiar `estado`: eso lo hace `/job-outcome`, que es el único que mueve el pipeline.
+- El CSV puede tener nombres de clientes y montos: **no commitearlo a un remoto sin confirmación explícita**.
+- Sin guiones largos en el texto agregado a las notas.
+
+## Handoff
+
+Pedí aprobación (approval) antes de escribir el CSV o tocar una nota. Registro COMPLETE cuando el modo corrió y el usuario sabe qué hacer con cada hallazgo. Según el caso, el siguiente paso es `/cold-outreach` (follow-up de lo frenado), `/job-outcome` (cerrar lo que no va a responder), `/contract-and-proposal-writer` (change order de las horas de más) o `/freelance-pipeline` (si hay 10+ resueltas y querés el diagnóstico del embudo).