claude-code-arcane 2.6.1 → 2.7.0

package/skills/blender-modeling/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: blender-modeling
+description: "Modelado en Blender para assets de juego: presupuesto de triangulos, topologia (quads, edge loops, poles), stack de modifiers, booleans, LODs y retopo, bmesh via script. Usar para: modelar en blender, topologia, modifiers, retopo, LOD, decimate."
+category: "gamedev"
+argument-hint: "[asset-slug] [--budget <tris>] [--lod]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit
+---
+# blender-modeling — Geometria
+
+Modela o corrige geometria con destino a un engine. Lo que sale de aca tiene que deformar bien,
+entrar en presupuesto y exportar sin sorpresas.
+
+> Requiere `/blender-context`. Si no corrio, correrlo primero: sin destino definido el presupuesto
+> de tris y los ejes son adivinanza.
+
+---
+
+## Phase 1: Presupuesto antes de modelar
+
+El presupuesto se declara primero y se mide despues. Al reves no funciona: nadie borra la mitad de
+un asset terminado.
+
+| Rol del asset | Rango de tris | Nota |
+|---|---|---|
+| Prop de fondo, mobile | 300 - 2k | Un solo material |
+| Prop interactivo | 2k - 8k | |
+| Personaje mobile / VR | 8k - 20k | VR paga doble: se renderiza dos veces |
+| Personaje desktop | 20k - 60k | |
+| Hero / cinematica | 60k+ | Necesita LODs propios |
+
+Si el usuario da un numero, ese manda. Si no, proponer el rango segun rol y destino y **pedir
+confirmacion** — no elegir en silencio.
+
+En UE5 los static meshes van a Nanite y el presupuesto de tris deja de importar; los **skeletal
+meshes no van a Nanite** y siguen necesitando LODs. Distinguirlo antes de dar un numero.
+
+---
+
+## Phase 2: Diagnostico de la malla
+
+Sobre un asset que ya existe, medir antes de opinar. Headless:
+
+```bash
+blender --background <archivo.blend> --python-expr "
+import bpy
+for o in bpy.data.objects:
+    if o.type != 'MESH': continue
+    m = o.data
+    ngons = sum(1 for p in m.polygons if len(p.vertices) > 4)
+    tris  = sum(len(p.vertices) - 2 for p in m.polygons)
+    print(f'{o.name}: verts={len(m.vertices)} tris={tris} ngons={ngons} '
+          f'uv_layers={len(m.uv_layers)} materials={len(o.material_slots)} scale={tuple(o.scale)}')
+"
+```
+
+Que se mira, en este orden:
+
+1. **Escala distinta de 1** → conversion de unidades sin aplicar. Se arregla antes que nada.
+2. **N-gons en geometria que deforma** → se resuelven, no se documentan.
+3. **Tris fuera de presupuesto** → decidir si se reduce o si se sube el presupuesto, con el usuario.
+4. **Cero UV layers** → el asset no puede texturizarse; es trabajo de `/blender-materials`.
+5. **Muchos materiales** → cada uno es un draw call.
+
+---
+
+## Phase 3: Topologia
+
+Reglas que no se negocian en geometria que deforma:
+
+- **Quads.** Tris solo en estatico, n-gons en nada.
+- **Edge loops en articulaciones**: hombro, codo, rodilla, mandibula. Sin loops no hay deformacion
+  posible, y eso no se arregla con weights.
+- **Poles de 5 aristas o menos.** Un pole de 6+ pincha el shading.
+- Densidad proporcional a la deformacion: la cara lleva mas malla que el torso.
+
+En geometria estatica lo unico que importa es la silueta y la eficiencia. Un cubo con 12 tris esta
+perfecto; subdividirlo "por prolijidad" es desperdicio.
+
+---
+
+## Phase 4: Modifiers
+
+El stack es no destructivo y **el orden cambia el resultado**. Orden que funciona casi siempre:
+
+```
+Mirror → Array → Solidify → Bevel → Subdivision Surface → Triangulate (solo al exportar)
+```
+
+- **Mirror antes de Subdivision**, nunca al reves: si no, la costura queda subdividida dos veces.
+- **Bevel antes de Subdivision** para bordes duros; con `Harden Normals` si el destino no tiene
+  soporte de custom normals.
+- **Triangulate no va en el stack de trabajo.** El exporter triangula solo; tenerlo puesto solo
+  ensucia la edicion.
+- No aplicar el stack "para dejarlo limpio". Se aplica cuando hace falta editar el resultado, y
+  ahi se pierde la vuelta atras.
+
+Booleans: solver `Exact` para precision, `Fast` para volumen. Los dos dejan basura — despues de un
+boolean va limpieza de topologia, siempre. Un boolean sin limpiar en algo que deforma es un bug
+esperando.
+
+---
+
+## Phase 5: LODs y reduccion
+
+| Metodo | Cuando | Que rompe |
+|---|---|---|
+| Decimate `Collapse` | LOD1/LOD2 de props | Topologia; no sirve para deformar |
+| Decimate `Planar` | Geometria dura, superficies planas | Detalle en curvas |
+| Retopo a mano | Heroes, cualquier cosa que deforme | Nada, cuesta tiempo |
+| Remesh (o `meshy_remesh`) | Escaneos y salidas de IA con topologia inservible | UVs, hay que rehacerlas |
+
+Cadena tipica de LODs: 100% → 50% → 25%. Verificar la silueta a distancia de juego, no en el
+viewport de cerca.
+
+**Un Decimate no es un LOD terminado**, es un borrador. Para heroes se dice explicitamente que
+hace falta retopo y no se entrega como final.
+
+---
+
+## Phase 6: Scripting con bmesh
+
+Para ediciones programaticas, `bmesh` sobre `bpy.ops`:
+
+- `bpy.ops.*` depende del contexto (modo, seleccion, area activa) y en `--background` falla o hace
+  otra cosa.
+- `bmesh.from_edit_mesh(me)` / `bmesh.new()` + `bm.to_mesh(me)` es determinista.
+- **Nunca `bpy.ops` dentro de un loop**: cada llamada revalida la escena entera y el costo es
+  cuadratico.
+
+Todo script que borra datos (`bpy.data.meshes.remove`, `objects.remove`) se le muestra al usuario
+antes de correrlo. Sin excepcion.
+
+Los scripts se versionan en el repo. **Pedir aprobacion antes de escribir** cualquier `.py` nuevo o
+de modificar uno existente, mostrando que va a hacer.
+
+---
+
+## Phase 7: Resumen
+
+Reportar por objeto: verts, tris, n-gons, materiales, escala, y tris contra el presupuesto.
+
+**Verdict:**
+- **PASS** — dentro de presupuesto, sin n-gons donde importa, escala aplicada.
+- **CONCERNS** — entra pero con deuda: n-gons en estatico, materiales de sobra, LOD por Decimate
+  en algo que deforma. Listar cada punto.
+- **FAIL** — fuera de presupuesto, n-gons en geometria que deforma, o escala sin aplicar.
+  Indicar el fix por objeto.
+
+## Next Steps
+
+- `/blender-materials` para UVs, shader nodes y bake
+- `/blender-animation` si el asset lleva rig
+- `/blender-export` cuando la geometria esta cerrada
+- `/asset-audit` para validar el resultado ya integrado en el proyecto
+
+---
+
+> → Topologia, presupuestos, ejes y las reglas de scripts destructivos estan en
+> `.claude/rules/blender-pipeline.md`.

package/skills/fiverr-gig/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: fiverr-gig
+description: "Construye el gig de Fiverr: titulo I will, tags de busqueda, los tres packages con precio derivado del piso neto, gallery, FAQ y requirements. Triggers: gig de fiverr, fiverr, packages basic standard premium, precio del gig, tags de fiverr, vender en fiverr."
+argument-hint: "[audit | title | packages | gallery | faq | price]"
+category: "career"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit, WebFetch
+---
+
+# Fiverr Gig - El lado de la oferta
+
+Fiverr funciona al revés que Upwork: **no te postulás, publicás.** El gig queda parado y el
+comprador te encuentra buscando. Los Buyer Requests ya no existen, así que no hay cola de ofertas
+que scorear - por eso `/freelance-scan` excluye Fiverr a propósito, y este skill es el que cubre lo
+que ahí falta.
+
+Consecuencia práctica: un gig es un **activo**, no una postulación. Se escribe una vez bien y se
+itera con datos (impresiones → clicks → órdenes), no se reescribe por cada cliente.
+
+Rutas relativas al career workspace (`--workspace`, env `CAREER_WORKSPACE`, o `./career-workspace/`).
+
+Modo: `$ARGUMENTS`
+
+## Inputs
+
+- **El perfil maestro** de `01-Perfiles/` - la fuente de verdad del nicho, el stack y los números.
+  Si no existe, correr `/master-profile` primero.
+- **El piso de tarifa neto** definido en `/freelance-hunt`. Sin piso no se puede fijar precio: se
+  estaría adivinando.
+- **El gig actual**, si ya existe: URL pública → WebFetch, o pegado.
+
+## Modos
+
+### `audit` - Revisar el gig actual
+
+Recorrer los cinco elementos de abajo y reportar qué falta, priorizado por impacto. Empezar siempre
+por **título, primera imagen de la gallery y precio del Basic**: son los únicos tres que se ven en
+los resultados de búsqueda, antes de que alguien haga click.
+
+### `title` - El título
+
+Arranca con `I will` por convención de la plataforma, y es lo que indexa la búsqueda.
+
+- **Nicho concreto, no rol.** "I will develop your Unity game" compite con todo el mundo. "I will
+  build multiplayer gameplay for your Unity mobile game" compite con pocos y aparece en la búsqueda
+  que importa.
+- Las palabras que usa el comprador, no las tuyas. El comprador no busca "gameplay architecture",
+  busca "multiplayer".
+- Sin superlativos ni "professional": no aportan y ocupan caracteres que sí indexan.
+- **Los tags (hasta 5) son parte del título, funcionalmente.** Elegirlos del mismo vocabulario, sin
+  repetir la misma palabra cinco veces.
+
+Proponer siempre **2 variantes** para elegir.
+
+### `packages` - Los tres niveles
+
+El error clásico es hacer tres versiones del mismo trabajo con distinto precio. Los packages tienen
+que separarse por **alcance**, no por velocidad ni por ganas.
+
+| | Basic | Standard | Premium |
+|---|---|---|---|
+| Qué es | La unidad mínima entregable y útil | **El que se quiere vender** | El techo, para el comprador que ya decidió |
+| Alcance | Una cosa, definida | Lo del Basic más lo que casi todos terminan pidiendo | Alcance completo, con lo que consume tiempo real |
+| Rol | Filtro de entrada y precio de referencia | Ancla: se compara contra los otros dos y gana | Sube el promedio y hace que el Standard parezca razonable |
+
+Reglas duras:
+
+- **El alcance va escrito en el package.** Lo que no está escrito es scope creep sin change order
+  posible: en Fiverr no hay renegociación a mitad de camino, hay una orden con un alcance.
+- **Revisiones con número.** "Unlimited revisions" es una promesa que destruye el margen y no se
+  puede retirar sin cancelar la orden.
+- **Delivery time realista, no competitivo.** Entregar tarde pega en el nivel de la cuenta, que no
+  se edita. Un día extra en el gig cuesta menos que una entrega tarde.
+- Los **gig extras** son para lo que es genuinamente opcional (fuente editable, licencia comercial,
+  entrega express), no para partir en pedazos algo que el package ya prometió.
+
+### `gallery` - Lo que se ve
+
+- **La primera imagen es el gig en la búsqueda.** Tiene que leerse en miniatura: una idea, texto
+  grande, cero decoración.
+- Después: el resultado real, no el proceso. Un before/after gana a cualquier mockup.
+- Video corto si el trabajo se entiende mejor en movimiento (animación, gameplay, motion).
+- Nunca material de un cliente sin permiso ni bajo NDA. Si no se puede mostrar, se reconstruye un
+  ejemplo propio equivalente y **se dice que es un ejemplo**.
+
+### `faq` - Las objeciones, adelantadas
+
+Cada FAQ existe para sacar una objeción del camino antes de que alguien escriba un mensaje. Las que
+casi siempre hacen falta: qué necesitás para arrancar, qué pasa si no gusta, si el precio incluye
+la fuente editable, si se puede usar comercialmente, qué **no** incluye el gig.
+
+Decir qué no hacés filtra al comprador equivocado, que es el que después califica mal.
+
+### `price` - El precio
+
+- Se deriva del **piso neto** de `01-Perfiles/` más la comisión de la plataforma. Fiverr retiene un
+  porcentaje del valor de la orden (históricamente 20%): verificar el vigente antes de fijar, y
+  cargarlo sobre el piso, no descontarlo del precio pensado.
+- El precio del Basic es el que aparece en la búsqueda: es filtro de tráfico, no la venta esperada.
+- **Arrancar barato para conseguir las primeras reviews es una trampa conocida**: atrae compradores
+  de precio, que son los que más piden y peor califican, y las reviews que dejan son las que
+  después determinan el nivel de la cuenta. Si falta historial, la palanca es **acotar el nicho**,
+  no bajar el precio.
+- Un gig con precio arriba del mercado y nicho angosto convierte peor en volumen y mejor en plata.
+  Esa es la elección, y la hace el usuario, no el skill.
+
+## Lo que el gig no controla
+
+El **nivel de la cuenta** (New Seller → Level 1 → Level 2 → Top Rated) y la métrica de respuesta no
+se editan: salen de órdenes completadas, calificaciones, entregas a tiempo y tiempo de respuesta.
+Es el mismo problema que el Job Success Score en Upwork, y se protege igual - eligiendo qué órdenes
+se aceptan y qué alcance se promete, no escribiendo mejor el gig.
+
+Las **impresiones** tampoco: dependen del algoritmo de búsqueda. Lo que el gig sí controla es la
+conversión de impresión a click (título y primera imagen) y de click a orden (packages y FAQ). Si
+las impresiones son bajas, el problema es el nicho o los tags; si son altas y no hay órdenes, el
+problema son los packages o el precio.
+
+## Proceso
+
+1. Leer el perfil maestro y el piso de tarifa. Si falta el piso, parar y mandar a `/freelance-hunt`.
+2. Correr el modo pedido (o `audit` si no se indicó ninguno).
+3. Proponer los textos como borradores en el chat, con 2 variantes de título y la tabla de los tres
+   packages completa, incluyendo delivery time y revisiones.
+4. Con approval, guardar en `01-Perfiles/Fiverr-<slug-del-gig>.md` (derivado del maestro, no
+   reemplazo). El usuario copia y pega en la plataforma - **este skill nunca toca la cuenta.**
+5. Anotar la fecha de publicación o del último ajuste, para poder correlacionarla después con
+   impresiones y órdenes.
+
+Un gig por nicho. Dos gigs que compiten por la misma búsqueda se canibalizan las impresiones.
+
+## Reglas
+
+- Nunca inventar experiencia, clientes ni números.
+- Nunca prometer en el package algo que no está en el alcance escrito.
+- Nunca "unlimited" nada.
+- El precio se deriva del piso, nunca de la competencia.
+- Sin guiones largos en los textos generados.
+
+## Handoff
+
+Pedí aprobación (approval) antes de escribir en `01-Perfiles/`. Gig **READY** cuando título, los
+tres packages con alcance y delivery, primera imagen definida y al menos tres FAQ están completos.
+
+Después: `/freelance-pipeline` para medir el gig con las órdenes que entren (el embudo de Fiverr es
+impresiones → clicks → órdenes, no propuestas enviadas), `/freelance-profile` si además va a
+trabajar en Upwork, y `/portfolio-site` si quiere un portfolio propio fuera de las plataformas.

package/skills/freelance-scan/references/platforms.md

@@ -114,6 +114,8 @@ Nota lateral útil: Lemon.io y Proxify (marketplaces con screening) publican sus
 
 Modelo invertido: no te postulás a trabajos, publicás gigs y el comprador te encuentra. Los "Buyer Requests" ya no existen como los conocía la gente. No hay cola que scorear.
 
+Queda fuera del scanner por eso, no porque no valga la pena: el lado de la oferta lo cubre `/fiverr-gig` (título, packages, gallery, FAQ y precio derivado del piso).
+
 ### Toptal, Gun.io, Braintrust, Arc, Lemon.io
 
 Verticales con screening previo. No hay board público consumible; el acceso se gana pasando su proceso de admisión. Fuera del alcance de un scanner.

package/skills/meshy-derive/SKILL.md

@@ -110,6 +110,9 @@ Reportar: targets generados, creditos gastados reales (delta de `check_balance`)
 
 - `/asset-audit` para validar naming, budgets y formatos contra los standards
 - `/meshy-print <slug>` si ademas va a impresion (tiene su propio flujo de printability)
+- `/blender-context` si el derivado `.blend` necesita limpieza: la topologia que sale de Meshy no
+  esta pensada para deformar, y las UVs suelen necesitar rehacerse. Ahi siguen `/blender-modeling`,
+  `/blender-materials` y `/blender-export` con su validador de glTF
 
 ---