@ericrisco/rsc 0.1.52 → 0.1.54

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.52",
+  "version": "0.1.54",
   "counts": {
     "skills": 258
   },
@@ -1950,7 +1950,7 @@
     },
     {
       "id": "gamedev-shaders",
-      "description": "Use when writing shaders, materials, VFX, or post-processing for a game engine, or asking \\\"how do I make this effect\\\" — covers the vertex→fragment pipeline, UVs / normals / coordinate spaces, and per-engine authoring in Godot 4.x (shader_type spatial/canvas_item/particles, source_color, hint_screen_texture, ShaderMaterial), Unity 6 (Shader Graph vs HLSL, URP/HDRP, ShaderLab), and Unreal 5.x (Material graph, material domains, Custom HLSL node). Includes recipes for dissolve, rim/outline, toon/cel, water/flow, force field, hologram; full-screen post-process; and shader performance (overdraw, texture-sample cost, branching, mobile). Triggers: \\\"write a dissolve shader\\\", \\\"rim light\\\", \\\"toon shading\\\", \\\"screen-space effect\\\", \\\"my shader is slow on mobile\\\", \\\"cómo hago un shader de agua\\\". NOT gameplay or engine-API code (→ godot / unity / unreal) and NOT physics simulation, collision, or rigid bodies (→ gamedev-physics).",
+      "description": "Use when authoring or debugging a shader, material, VFX, or full-screen post-process in a game engine — Godot 4.x `.gdshader`, Unity 6 URP/HDRP, Unreal 5.x Materials, effect recipes, shader performance. NOT gameplay or engine-API code (that is `godot`/`unity`/`unreal`), NOT physics (`gamedev-physics`), NOT build variant stripping (`gamedev-shipping`).",
       "tags": [
         "shaders",
         "vfx",
@@ -1995,7 +1995,7 @@
     },
     {
       "id": "gcp-essentials",
-      "description": "Use when running a small product on the core of Google Cloud with the gcloud CLI: creating a project, deploying a container to Cloud Run, standing up a Cloud Storage bucket, a managed Cloud SQL Postgres/MySQL, and wiring them together with least-privilege IAM. Triggers: 'deploy to Cloud Run', 'gcloud run deploy', 'set up a GCP project', 'crear bucket en GCP', 'desplegar a Cloud Run', 'service account sin claves JSON', 'why is my Cloud Run running as the default service account', 'connect Cloud Run to Cloud SQL', 'turn off the bucket public access'. NOT AWS (that is aws-essentials).",
+      "description": "Use when running a small product on core Google Cloud via the gcloud CLI: a project, Cloud Run deploys, a locked-down Cloud Storage bucket, managed Cloud SQL, and least-privilege IAM wiring them together. NOT AWS (that is `aws-essentials`), NOT the CI pipeline that ships the image (that is `deployment`), NOT Postgres schema/query tuning (that is `postgresdb`).",
       "tags": [
         "gcp",
         "cloud-run",
@@ -2192,7 +2192,7 @@
     },
     {
       "id": "hetzner",
-      "description": "Use when provisioning or hardening a Hetzner Cloud VPS to host real apps: picking a plan/location (CX/CPX/CAX/CCX), bringing a box up reproducibly with the hcloud CLI + cloud-init, locking down SSH, and wiring the Hetzner Cloud Firewall before handing off a Docker/Coolify-ready host. Triggers: 'set up a Hetzner server', 'provision a Hetzner VPS', 'harden SSH on my box', 'which Hetzner plan for a small API', 'configure the Hetzner Cloud Firewall', the non-obvious 'my ipv6-only box is cheaper but docker pull can't reach the registry', and the Spanish/Catalan 'monta un servidor en Hetzner', 'configura el firewall de Hetzner'. NOT deploying apps through Coolify (that is coolify).",
+      "description": "Use when provisioning or hardening a Hetzner Cloud VPS: picking the plan/location (CX/CPX/CAX/CCX), bringing it up reproducibly with hcloud + cloud-init, locking down SSH, and wiring the Cloud Firewall to hand off a Docker-ready host. NOT app deploys on Coolify (that is `coolify`), NOT Dockerfiles (that is `docker`), NOT another provider (that is `digitalocean`).",
       "tags": [
         "hetzner",
         "vps",
@@ -2439,7 +2439,7 @@
     },
     {
       "id": "knowledge-ops",
-      "description": "Use when an already-running 02-DOCS/ wiki needs day-to-day gardening — too many half-finished articles, a 600-line page that covers three unrelated topics, a note with no obvious home, orphan pages nothing links to, stale answers and superseded articles piling up, or two articles that contradict each other. This is the judgment layer over harness's automation: decide what is worth capturing (default: nothing), where it goes, how to title/split/merge it, build the See Also web, and prune to _archive (never delete). Triggers: 'limpia mi wiki', 'organiza mis notas', 'esto dónde va en la wiki', 'ordena la base de conocimiento', 'split this bloated article', 'where should this note live', 'scores.json says these three are orphans — fix the cross-links', 'prune the stale and superseded stuff'. NOT building, bootstrapping or sweeping the wiki engine (that is harness).",
+      "description": "Use when an already-running 02-DOCS/ wiki needs gardening judgment — what is worth capturing (default: nothing), where a loose note belongs, whether to split a bloated article or merge near-duplicates, how to link orphans back in, and what retires to _archive (never delete). NOT building or sweeping the wiki engine itself (that is `harness`).",
       "tags": [
         "knowledge-ops",
         "wiki",
@@ -2549,7 +2549,7 @@
     },
     {
       "id": "lead-gen",
-      "description": "Use when you need to find and qualify prospects, build a target list, or score and prioritize leads before anyone reaches out — defining an ICP, sourcing named accounts/contacts from Apollo/ZoomInfo/Clay, deduping against the CRM, and ranking with a fit+intent+engagement model. Triggers: 'build me a prospect list', 'who should we sell to', 'score these leads', 'which accounts do we call first', 'tighten our ICP', 'is this cold list GDPR-safe', 'necesito una lista de clientes potenciales', 'califica estos leads', 'a qui truquem primer'. NOT writing or sending the outreach (that is cold-outreach), NOT tracking the deal after first contact (that is sales-pipeline).",
+      "description": "Use when building and qualifying a prospect list before anyone reaches out — a falsifiable ICP, named accounts/contacts from Apollo/ZoomInfo/Clay, deduped against the CRM, tiered by fit+intent+engagement. NOT writing or sending the outreach (that is cold-outreach), NOT tracking the deal after first contact (that is sales-pipeline).",
       "tags": [
         "lead-generation",
         "prospecting",
@@ -2609,7 +2609,7 @@
     },
     {
       "id": "linkedin-carousels",
-      "description": "Use when designing a LinkedIn carousel / document post — the swipeable multi-page PDF that is currently the highest-reach native LinkedIn format — and you need the slide-by-slide build: a scroll-stopping cover hook, a narrative arc that pulls swipe-to-swipe, one focused idea per slide with real visual hierarchy, a payoff + CTA closer, and a PDF export spec. Triggers: 'turn this into a LinkedIn carousel', 'design a swipeable PDF document post', 'my carousel cover gets no swipes fix the hook', 'how many slides and what goes on each', 'restructure one-idea-per-slide', 'what size to export so it isnt cropped on mobile', 'convierte este post en un carrusel de LinkedIn', 'dissenya'm un carrusel de LinkedIn amb portada i CTA'. NOT the account/format plan (that is linkedin-strategy), NOT a text or single-image feed post (that is linkedin-content), NOT a spoken-to talk deck (that is presentations).",
+      "description": "Use when building a LinkedIn carousel / document post — the swipeable multi-page PDF — slide by slide: cover hook, narrative arc, one idea per slide, CTA closer, PDF export spec. NOT the account/format plan (that is `linkedin-strategy`), NOT a text or single-image feed post (that is `linkedin-content`), NOT a 16:9 talk deck (that is `presentations`).",
       "tags": [
         "linkedin",
         "carousel",
@@ -2694,7 +2694,7 @@
     },
     {
       "id": "llm-pipeline",
-      "description": "Use when wiring several LLM calls into one production flow, when random 429s/timeouts/provider outages take a feature down, when adding a fallback model or a gateway in front of OpenAI/Claude, or when the bill explodes from uncached or flagship-everywhere calls. Triggers: 'chain these LLM calls', 'step 1 extracts step 2 summarizes', 'add a fallback if GPT fails use Claude', 'route easy requests to Haiku escalate to Opus', 'put a LiteLLM gateway in front', 'our bill tripled because we re-call the model on every request', 'semantic cache the responses', 'encadenar llamadas y cachear respuestas', 'cadena de crides a l'LLM amb fallback'. NOT prompt wording (that is prompt-engineering).",
+      "description": "Use when wiring several LLM calls into a production flow: typed contracts between steps, a router/gateway so 429s, timeouts and outages fail over instead of taking you down, and cost control via caching, model tiers and abort caps. NOT single-prompt wording (that is `prompt-engineering`), NOT a model-driven tool loop (that is `building-agents`).",
       "tags": [
         "llm-orchestration",
         "llm-gateway",
@@ -2827,7 +2827,7 @@
     },
     {
       "id": "medium-publishing",
-      "description": "Use when getting a finished article onto Medium correctly — choosing profile vs publication, cross-posting from your own site without an SEO duplicate-content hit, the import tool, the 5-tag limit, and Medium's pseudo-Markdown formatting gotchas. Triggers: 'cross-post to Medium', 'republish on Medium with a canonical link', 'submit my draft to a Medium publication', 'why are my code blocks broken on Medium', 'can I still automate Medium via the API', 'the Medium import tool failed with a 403', 'importar mi artículo a Medium sin penalización SEO', 'publicar a Medium amb enllaç canònic'. NOT drafting, structuring, or headlining the article itself (that is medium-writing).",
+      "description": "Use when a finished article has to land on Medium correctly — profile vs publication, cross-posting under a canonical link so your own site keeps the SEO credit, import-tool failures, the 5-tag cap, pseudo-Markdown gotchas. NOT writing or headlining the piece (that is `medium-writing`), NOT cadence or earnings (that is `medium-strategy`).",
       "tags": [
         "medium",
         "publishing",
@@ -2912,7 +2912,7 @@
     },
     {
       "id": "modal",
-      "description": "Use when running Python functions or GPU workloads serverlessly on Modal — defining a modal.App with inline container Images, scaling @app.function onto CPU/GPU, persisting weights or datasets in a Volume, scheduling jobs, serving an HTTP/ASGI endpoint, or choosing modal run vs serve vs deploy. Triggers: 'run my embedding job on an H100 without managing servers', 'cache HuggingFace weights across runs', 'my @app.function GPU string errors', 'gpu=modal.gpu.A100() fails', 'modal serve isn't hot-reloading my fastapi_endpoint', 'cold start too slow / keep a warm pool', 'ejecutar Python en GPU serverless', 'desplegar un model de difusió amb GPU sense servidor i exposar-lo per HTTP'. NOT managed prediction endpoints with no infra code (that is replicate) and NOT persistent SSH-able GPU pods rented by the hour (that is runpod).",
+      "description": "Use when running Python or GPU workloads serverlessly on Modal — modal.App, inline container Images, gpu= on @app.function, Volumes for weight caching, Cron schedules, ASGI endpoints, modal run vs serve vs deploy. NOT managed prediction APIs with no container of your own (that is replicate); NOT SSH-able GPU boxes rented by the hour (that is runpod).",
       "tags": [
         "modal",
         "serverless",
@@ -2992,7 +2992,7 @@
     },
     {
       "id": "n8n",
-      "description": "Use when operating a live n8n instance programmatically — driving its public REST API (`{host}/api/v1`, `X-N8N-API-KEY`) or the n8n-mcp server to create, validate, test, activate/deactivate, list, update, or delete workflows and read executions, on self-host or `*.app.n8n.cloud`. Triggers: 'deploy this workflow to my n8n over the API', 'push my workflow JSON to n8n with curl', 'I set active:true in the create call but it stays inactive', 'connect n8n-mcp / n8n_create_workflow to Claude', 'validate and autofix my n8n workflow', 'run an n8n workflow by id from a script', 'delete a workflow via the API', 'automatiza n8n por API', 'desplega el workflow a n8n.cloud'. NOT designing the flow's trigger-step-error logic or hand-building the importable workflow JSON (that is automation-flows), NOT operating Make / Zapier / Power Automate (their own skills), NOT a typed API client with auth+pagination+retry (api-connector-builder), NOT the inbound webhook receiver in your own app (webhooks).",
+      "description": "Use when operating a live n8n instance programmatically — its REST API (`{host}/api/v1`, `X-N8N-API-KEY`) or the n8n-mcp server — to create, validate, test, activate, update, delete workflows and read executions on self-host or n8n.cloud. NOT designing the flow or its importable JSON (that is `automation-flows`), NOT another platform (`make`, `zapier`).",
       "tags": [
         "n8n",
         "automation",
@@ -3075,7 +3075,7 @@
     },
     {
       "id": "newsletter",
-      "description": "Use when running an email newsletter as a recurring publication — writing the subject line + preview text, structuring an issue so opens turn into clicks, the welcome/onboarding sequence, send cadence and engagement segmentation, growth loops (referral, signup incentive, double opt-in), and a metric scorecard that survives Apple Mail Privacy Protection. Triggers: 'write the newsletter subject line', 'my newsletter gets opened but nobody clicks', 'set up a welcome sequence', 'grow my newsletter list', 'newsletter referral program', 'how often should I send', 'what metrics matter now that opens are fake', 'click-to-open rate', 'escriu la newsletter d'aquesta setmana', 'campaña de newsletter que convierta'. NOT the one-off product launch or nurture campaign (that is marketing), NOT the SPF/DKIM/DMARC plumbing under the send (that is email-deliverability).",
+      "description": "Use when running an email newsletter as a recurring publication — subject + preview pair, issues that turn opens into clicks, the welcome sequence, cadence and engagement tiering, growth loops, and a post-Apple-MPP click scorecard. NOT one-off launch or nurture sends (that is `marketing`), NOT SPF/DKIM/DMARC (that is `email-deliverability`).",
       "tags": [
         "newsletter",
         "email",
@@ -3177,7 +3177,7 @@
     },
     {
       "id": "notion-connector",
-      "description": "Use when wiring an app, cron job, or service to Notion as an ops backend over the official HTTP API — pushing rows into a Notion database, mirroring a database into your app, syncing both ways without duplicates, building or reading page block content, or fixing an integration that broke after the 2025-09-03 data-source split. Triggers: 'store our tasks in a Notion database from code', 'use Notion as a CRM/content calendar', 'sync our CRM into Notion nightly without duplicates', 'why does POST /v1/databases/:id/query return 404 now', 'integration broke after a teammate added a second data source', 'guardar registros en una base de datos de Notion desde código', 'desar files a una base de dades de Notion'. NOT a generic call-any-REST-API integration (that is api-connector-builder), NOT receiving/verifying inbound Notion webhook events (that is webhooks).",
+      "description": "Use when wiring server code or a cron job to Notion as an ops backend over its HTTP API: pushing or mirroring database rows, two-way sync without duplicates, page blocks, or an integration broken by the 2025-09-03 data-source split. NOT generic REST wiring (that is `api-connector-builder`), NOT inbound Notion webhook events (that is `webhooks`).",
       "tags": [
         "notion",
         "ops-backend",
@@ -3406,7 +3406,7 @@
     },
     {
       "id": "planetscale",
-      "description": "Use when operating PlanetScale serverless MySQL (Vitess) — setting up a database/branch and wiring the pscale CLI, shipping a schema change through branches and deploy requests, debugging a stuck/queued deploy or a cutover that won't finish, designing tables without foreign keys, or picking the serverless HTTP driver for an edge runtime. Triggers: 'schema change without downtime on PlanetScale', 'my migration is stuck in the deploy queue', 'the cutover hung', 'can I still revert 40 minutes after deploy', 'the 30-minute revert window', 'PlanetScale won't let me add a foreign key', 'relationMode prisma', 'MySQL connection times out on Vercel Edge', 'cambio de esquema sin downtime', 'no me deja usar foreign keys'. NOT raw MySQL query tuning, EXPLAIN, or index choice (that is postgresdb's MySQL-engine analogue / the mysql sibling), and NOT generic expand-contract migration theory (that is db-migrations).",
+      "description": "Use when operating PlanetScale (Vitess serverless MySQL) — branches and the `pscale` CLI, schema changes through deploy requests (Online DDL cutover, ~30-min revert window), tables without foreign keys, or the edge HTTP driver. NOT MySQL engine work like EXPLAIN or index choice (that is `mysql`), NOT generic migration theory (that is `db-migrations`).",
       "tags": [
         "planetscale",
         "vitess",
@@ -3609,7 +3609,7 @@
     },
     {
       "id": "prompt-engineering",
-      "description": "Use when one prompt has to give the same right answer across reruns, models, and hostile inputs — a prompt that works sometimes, forcing valid JSON or a fixed schema out of a model, choosing how many few-shot examples and which ones, hardening a prompt against injected instructions, writing a tiny eval set before changing a prompt, or porting a prompt to a new model without behavior drift. Triggers: 'the prompt works sometimes', 'force valid JSON from the model', 'how many few-shot examples', 'outputs drift between reruns', 'the model ignores my instructions on long inputs', 'users can paste instructions into my input field', 'el prompt a veces falla', 'forzar JSON válido del modelo', 'el model no segueix les instruccions'. NOT the agent loop, tool wiring, or RAG retrieval (that is building-agents).",
+      "description": "Use when one prompt must give the same right answer across reruns, models, and pasted-in hostile input: forcing a fixed schema, picking the few-shot set, ordering the prompt blocks, or the inline cases you run while tuning. NOT the agent loop, tools, or retrieval (that is `building-agents`), NOT a standing CI eval harness (that is `agent-eval`).",
       "tags": [
         "prompts",
         "llm",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ericrisco/rsc",
-  "version": "0.1.52",
+  "version": "0.1.54",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

package/skills/gamedev-shaders/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gamedev-shaders
-description: "Use when writing shaders, materials, VFX, or post-processing for a game engine, or asking \"how do I make this effect\" — covers the vertex→fragment pipeline, UVs / normals / coordinate spaces, and per-engine authoring in Godot 4.x (shader_type spatial/canvas_item/particles, source_color, hint_screen_texture, ShaderMaterial), Unity 6 (Shader Graph vs HLSL, URP/HDRP, ShaderLab), and Unreal 5.x (Material graph, material domains, Custom HLSL node). Includes recipes for dissolve, rim/outline, toon/cel, water/flow, force field, hologram; full-screen post-process; and shader performance (overdraw, texture-sample cost, branching, mobile). Triggers: \"write a dissolve shader\", \"rim light\", \"toon shading\", \"screen-space effect\", \"my shader is slow on mobile\", \"cómo hago un shader de agua\". NOT gameplay or engine-API code (→ godot / unity / unreal) and NOT physics simulation, collision, or rigid bodies (→ gamedev-physics)."
+description: "Use when authoring or debugging a shader, material, VFX, or full-screen post-process in a game engine — Godot 4.x `.gdshader`, Unity 6 URP/HDRP, Unreal 5.x Materials, effect recipes, shader performance. NOT gameplay or engine-API code (that is `godot`/`unity`/`unreal`), NOT physics (`gamedev-physics`), NOT build variant stripping (`gamedev-shipping`)."
 tags: [shaders, vfx, materials, post-processing, shadergraph]
 recommends: [godot, unity, unreal, gamedev-shipping]
 profiles: [full]
@@ -11,8 +11,7 @@ origin: risco
 
 Author shaders, materials, and full-screen effects across Godot, Unity, and Unreal. One
 mental model — the GPU pipeline — mapped onto each engine's authoring surface, plus recipes
-for the effects people actually ask for. Fires on writing/debugging a shader or material,
-building a VFX/post-process effect, or "how do I make X look like Y".
+for the effects people actually ask for.
 
 ## Version contract — read first
 
@@ -28,22 +27,6 @@ symbol is current, say so rather than guess.
 `shader_type` tokens in Godot 4 are exact: `spatial`, `canvas_item` (underscore), `particles`
 (plural), `sky`, `fog`.
 
-## When to use / When NOT to use
-
-**Use when:** writing or debugging a `.gdshader`/`ShaderMaterial`, a `.shader`/Shader Graph, or
-a UE Material; building a VFX look (dissolve, rim, toon, water, shield, hologram, trails);
-authoring post-processing / screen-space effects; a shader is slow, flickers, or looks wrong;
-choosing per-vertex vs per-pixel; converting an effect between engines.
-
-**When NOT to use (delegate):**
-
-- Gameplay logic, nodes/components, input, engine APIs, scene setup → [`godot`](../godot/SKILL.md) /
-  [`unity`](../unity/SKILL.md) / [`unreal`](../unreal/SKILL.md). This skill owns the *shading*, not the C#/GDScript/Blueprint around it.
-- Physics simulation, collisions, rigid bodies, character controllers → [`gamedev-physics`](../gamedev-physics/SKILL.md).
-  (A shader that *fakes* refraction is here; simulating fluid dynamics is not.)
-- Shipping, platform export, shader-variant stripping in the build pipeline → [`gamedev-shipping`](../gamedev-shipping/SKILL.md)
-  (this skill keeps the per-shader performance work).
-
 ## Shader fundamentals (the pipeline)
 
 Every engine compiles your material into the same GPU stages. Two you write:
@@ -131,10 +114,10 @@ for high-end):
   blocks; the program goes in an `HLSLPROGRAM … ENDHLSL` block that `#include`s URP's `Core.hlsl`
   / `Lighting.hlsl`. Use for full control, custom lighting, or compute-driven effects.
 
-**Surface shaders are Built-in-RP only** — under URP/HDRP write a lit HLSL pass or a Shader Graph;
-use `TransformObjectToHClip` for the clip transform, not the retired `UnityObjectToClipPos`. Set
-parameters at runtime through a `MaterialPropertyBlock` or `Material.SetFloat/SetColor/SetTexture`.
-Full URP unlit + lit HLSL pass and a Shader Graph mapping → `references/unity-and-unreal-shaders.md`.
+Surface shaders are not an option under URP/HDRP (see the Version contract) — a lit look is an
+HLSL pass or a Shader Graph. Set parameters at runtime through a `MaterialPropertyBlock` or
+`Material.SetFloat/SetColor/SetTexture`. Full URP unlit + lit HLSL pass and a Shader Graph
+mapping → `references/unity-and-unreal-shaders.md`.
 
 ### Unreal 5.x
 
@@ -216,24 +199,27 @@ per engine → `references/effect-recipes.md`.
 - **Mobile / tile GPUs**: bandwidth-bound — keep render targets small, avoid mid-pass framebuffer
   reads, and note that `discard` and large full-screen passes break tile hidden-surface removal.
 
-## Guardrails / gotchas
+## Anti-patterns
 
-- Godot 4: the `SCREEN_TEXTURE`/`DEPTH_TEXTURE` built-ins are gone — declare `hint_screen_texture`
-  / `hint_depth_texture` uniforms. `hint_color` → `source_color`. Author colors as `source_color`
-  so sRGB→linear conversion is correct.
-- Unity: don't write a surface shader or include `UnityCG.cginc` for a URP/HDRP project.
-- Unreal: `SceneTexture` post-process nodes only work in the Post Process domain; match Opacity to
-  the blend mode.
-- Normalize interpolated normals per pixel; unpack normal maps (`×2−1`) and mind tangent handedness.
-- Watch color space (linear vs sRGB) at every texture read and color output — the #1 "looks washed
-  out / too dark" bug.
+| Anti-pattern | Do instead |
+| --- | --- |
+| Porting a tutorial verbatim from Godot 3, Built-in RP, or pre-5.0 UE | Translate it through the Version contract table first — retired symbols still compile in old guides, not in your project. |
+| Reading a texture or writing a color without minding linear vs sRGB | Author color uniforms as `source_color` (Godot) / sRGB-marked properties and check the space at every read and output — the #1 "looks washed out / too dark" bug. |
+| Using interpolated normals raw, or a normal map straight from the sample | Re-normalize per pixel; unpack with `×2−1` and mind tangent handedness. |
+| Writing the shader before choosing the target surface | Pick `shader_type` / render pipeline / material domain first (2D vs 3D, URP vs HDRP, Surface vs Post Process) — it decides which built-ins and blend modes exist. |
+| Fresnel, normalization, or lighting math in the vertex stage | Only linearly-interpolating work goes per-vertex; exact math stays per-pixel. |
+| `discard`/`clip` as a cheap "make it invisible" | Cull it or scale to zero — `discard` disables early-Z and breaks tile hidden-surface removal on mobile. |
+| Stacking additive/translucent layers until the look works | Count the overdraw: each layer re-shades the same pixels. Prefer opaque, minimize overlap, keep particle fill low. |
+| Full-screen effects via `OnRenderImage`/`Graphics.Blit`, or `SceneTexture` outside the Post Process domain | Use the engine's supported path — URP Renderer Feature / Fullscreen Shader Graph, UE Post Process material, Godot `ColorRect` + `hint_screen_texture` or `CompositorEffect`. |
 
 ## Related skills
 
-- [`godot`](../godot/SKILL.md) / [`unity`](../unity/SKILL.md) / [`unreal`](../unreal/SKILL.md) — the
-  engine skills own gameplay code, nodes/components, and scene wiring; this skill owns the shaders/materials.
-- [`gamedev-physics`](../gamedev-physics/SKILL.md) — simulation, collision, rigid bodies (a shader that *fakes* an effect stays here).
-- [`gamedev-shipping`](../gamedev-shipping/SKILL.md) — platform export and shader-variant stripping in the build.
+- [`godot`](../godot/SKILL.md) / [`unity`](../unity/SKILL.md) / [`unreal`](../unreal/SKILL.md) — gameplay
+  code, nodes/components, input, scene wiring; this skill owns the *shading*, not the C#/GDScript/Blueprint around it.
+- [`gamedev-physics`](../gamedev-physics/SKILL.md) — simulation, collision, rigid bodies, character
+  controllers (a shader that *fakes* refraction is here; simulating fluid dynamics is not).
+- [`gamedev-shipping`](../gamedev-shipping/SKILL.md) — platform export and shader-variant stripping in
+  the build (this skill keeps the per-shader performance work).
 
 ## Checklist
 
@@ -244,9 +230,3 @@ per engine → `references/effect-recipes.md`.
 - [ ] Uniforms/parameters exposed and driven from code or an animation track — not hard-coded.
 - [ ] Performance sanity: overdraw, sample count, and branching considered; mobile precision set if targeted.
 - [ ] Post-process uses the engine's supported full-screen path (not a retired Built-in-RP mechanism).
-
-## References
-
-- `references/godot-shading-language.md` — shader types, built-ins per type, render_modes, `varying`, screen/depth reads, ShaderMaterial from code.
-- `references/unity-and-unreal-shaders.md` — Unity URP HLSL pass + Shader Graph mapping; Unreal domains, Custom node HLSL, Material Instances.
-- `references/effect-recipes.md` — dissolve, rim/outline, toon/cel, water/flow, force field, hologram — full code per engine.

package/skills/gamedev-shaders/evals/cases.yaml

@@ -4,13 +4,13 @@ should_trigger:
   - prompt: "Write me a dissolve shader in Godot 4 that burns an object away from bottom to top with a glowing orange edge."
     why: "Dissolve is a named recipe and the core use case; Godot 4 .gdshader authoring is owned here."
   - prompt: "How do I make a rim light / fresnel glow on a 3D character in Unity URP?"
-    why: "Rim/fresnel is a named recipe; 'how do I make X effect' is an explicit trigger; Unity shader authoring is per-engine mapped here."
+    why: "Rim/fresnel is a named recipe; 'how do I make X effect' is the core shape of a shader request; Unity shader authoring is per-engine mapped here."
   - prompt: "My translucent particle shader tanks the framerate on mobile. How do I fix the overdraw?"
     why: "Shader performance — overdraw, transparency, mobile — is a dedicated section; symptom-only trigger routes here, not to a generic profiler."
   - prompt: "Set up a full-screen post-process effect in Unreal that reads scene depth and draws outlines."
     why: "Post-processing / full-screen effects per engine is a core section; Unreal Post Process material + SceneTexture is covered."
   - prompt: "Cómo hago un shader de agua con refracción y espuma en los bordes."
-    why: "Spanish water/flow recipe request; the description carries the Spanish 'cómo hago un shader de agua'."
+    why: "Spanish water/flow recipe request; water/flow is a named recipe and matching is by meaning, not by language."
   - prompt: "Convert this toon/cel shading effect from my Godot project to a Unity Shader Graph."
     why: "Toon/cel is a named recipe and cross-engine conversion is an explicit use case; the skill carries a Godot↔Unity↔Unreal map."
   - prompt: "What coordinate space are NORMAL and VIEW in inside a Godot spatial fragment shader, and why does my world-space fresnel look wrong?"

package/skills/gcp-essentials/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gcp-essentials
-description: "Use when running a small product on the core of Google Cloud with the gcloud CLI: creating a project, deploying a container to Cloud Run, standing up a Cloud Storage bucket, a managed Cloud SQL Postgres/MySQL, and wiring them together with least-privilege IAM. Triggers: 'deploy to Cloud Run', 'gcloud run deploy', 'set up a GCP project', 'crear bucket en GCP', 'desplegar a Cloud Run', 'service account sin claves JSON', 'why is my Cloud Run running as the default service account', 'connect Cloud Run to Cloud SQL', 'turn off the bucket public access'. NOT AWS (that is aws-essentials)."
+description: "Use when running a small product on core Google Cloud via the gcloud CLI: a project, Cloud Run deploys, a locked-down Cloud Storage bucket, managed Cloud SQL, and least-privilege IAM wiring them together. NOT AWS (that is `aws-essentials`), NOT the CI pipeline that ships the image (that is `deployment`), NOT Postgres schema/query tuning (that is `postgresdb`)."
 tags: [gcp, cloud-run, cloud-sql, cloud-storage, iam, gcloud, serverless, devops]
 recommends: [aws-essentials, docker, github-actions, secure-coding, postgresdb, deployment, monitoring, backups]
 origin: risco
@@ -20,12 +20,14 @@ Four primitives carry most products, plus the project/billing scaffold under the
 - **Cloud Storage** — object storage (buckets).
 - **Cloud SQL** — managed Postgres/MySQL.
 
-Out of scope, route elsewhere: AWS -> `aws-essentials`. Building/shipping the image
-itself -> `docker` / `github-actions` / [`../deployment/SKILL.md`](../deployment/SKILL.md).
+Out of scope, route elsewhere: AWS -> [`../aws-essentials/SKILL.md`](../aws-essentials/SKILL.md).
+Building/shipping the image itself -> [`../docker/SKILL.md`](../docker/SKILL.md)
+/ [`../github-actions/SKILL.md`](../github-actions/SKILL.md) / [`../deployment/SKILL.md`](../deployment/SKILL.md).
 Postgres schema/index/query tuning -> [`../postgresdb/SKILL.md`](../postgresdb/SKILL.md).
 App-level injection/secret-handling review -> [`../secure-coding/SKILL.md`](../secure-coding/SKILL.md).
-Logging/alerting/SLOs as a practice -> `monitoring`. Backup strategy as a discipline
--> `backups`. One-click PaaS where you never touch IAM/VPC -> [`../vercel/SKILL.md`](../vercel/SKILL.md)
+Logging/alerting/SLOs as a practice -> [`../monitoring/SKILL.md`](../monitoring/SKILL.md).
+Backup strategy as a discipline -> [`../backups/SKILL.md`](../backups/SKILL.md).
+One-click PaaS where you never touch IAM/VPC -> [`../vercel/SKILL.md`](../vercel/SKILL.md)
 / [`../railway/SKILL.md`](../railway/SKILL.md) / [`../render/SKILL.md`](../render/SKILL.md)
 / [`../fly-io/SKILL.md`](../fly-io/SKILL.md).
 
@@ -96,8 +98,8 @@ Two hard rules, each with teeth:
    Identity Federation for external/CI auth (GitHub Actions). If `... keys create` is
    in your runbook, the runbook is wrong.
 
-WIF for keyless CI, SA impersonation, IAM Recommender and Conditions live in
-[`references/iam-and-auth.md`](references/iam-and-auth.md).
+The predefined-role catalog, WIF for keyless CI, SA impersonation, IAM Recommender and
+Conditions live in [`references/iam-and-auth.md`](references/iam-and-auth.md).
 
 ## 2. Cloud Run
 
@@ -233,8 +235,9 @@ gcloud run deploy api --region=europe-west1 \
 ```
 
 The Cloud SQL **Auth Proxy** (short-lived certs, TLS 1.3) is for connecting from
-*outside* — local dev or a non-serverless host — not for Cloud Run. Private IP, PSC
-and proxy invocation are in [`references/networking-and-sql.md`](references/networking-and-sql.md).
+*outside* — local dev or a non-serverless host — not for Cloud Run. Direct VPC egress vs
+legacy connectors, private IP / PSC, proxy invocation and pooling are in
+[`references/networking-and-sql.md`](references/networking-and-sql.md).
 
 ## 5. Wire it together
 
@@ -267,6 +270,10 @@ Note the scoping: `cloudsql.client` is project-wide (the role needs it), but the
 storage and secret grants are bound to the *specific* bucket and secret, not the
 project. Grant narrow.
 
+Copy-paste runbooks for each piece — image build and push, private container deploy,
+attach SQL, mount a secret, full teardown — are in
+[`references/deploy-recipes.md`](references/deploy-recipes.md).
+
 ## 6. Cost & teardown
 
 - Cloud Run scales to zero by default — an idle service costs ~nothing. Keep
@@ -315,13 +322,3 @@ bash scripts/verify.sh path/to/dir/              # recurse a directory
 
 It prints `PASS`/`FAIL` per check and exits nonzero on any FAIL. An empty or
 clean target passes (exit 0).
-
-## References
-
-- [`references/iam-and-auth.md`](references/iam-and-auth.md) — predefined-role catalog,
-  Workload Identity Federation for GitHub Actions, SA impersonation, IAM Recommender,
-  Conditions.
-- [`references/networking-and-sql.md`](references/networking-and-sql.md) — Direct VPC
-  egress vs legacy connectors, Cloud SQL private IP / PSC, Auth Proxy, pooling.
-- [`references/deploy-recipes.md`](references/deploy-recipes.md) — copy-paste runbooks:
-  container deploy, attach SQL, mount a secret, budget alert, full teardown.

package/skills/hetzner/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hetzner
-description: "Use when provisioning or hardening a Hetzner Cloud VPS to host real apps: picking a plan/location (CX/CPX/CAX/CCX), bringing a box up reproducibly with the hcloud CLI + cloud-init, locking down SSH, and wiring the Hetzner Cloud Firewall before handing off a Docker/Coolify-ready host. Triggers: 'set up a Hetzner server', 'provision a Hetzner VPS', 'harden SSH on my box', 'which Hetzner plan for a small API', 'configure the Hetzner Cloud Firewall', the non-obvious 'my ipv6-only box is cheaper but docker pull can't reach the registry', and the Spanish/Catalan 'monta un servidor en Hetzner', 'configura el firewall de Hetzner'. NOT deploying apps through Coolify (that is coolify)."
+description: "Use when provisioning or hardening a Hetzner Cloud VPS: picking the plan/location (CX/CPX/CAX/CCX), bringing it up reproducibly with hcloud + cloud-init, locking down SSH, and wiring the Cloud Firewall to hand off a Docker-ready host. NOT app deploys on Coolify (that is `coolify`), NOT Dockerfiles (that is `docker`), NOT another provider (that is `digitalocean`)."
 tags: [hetzner, vps, cloud-firewall, hcloud, ssh-hardening, cloud-init, self-hosting]
 recommends: [coolify, docker, secure-coding, domains-dns, backups, monitoring]
 origin: risco
@@ -14,17 +14,8 @@ include 20 TB of egress. The risk is that "cheap" becomes "unhardened and
 unmonitored" — a root-SSH box on a public IPv4 with password auth on. Your job
 is to make the cheap box **safe** and **reproducible**: every server comes up
 from a committed cloud-init file and a Cloud Firewall ruleset, never from
-click-ops in the console.
-
-Operating posture:
-
-- **Reproducible by default.** A box you can't recreate from a file isn't a box,
-  it's a pet. Bake the non-root user, SSH key, and sshd hardening into first
-  boot via cloud-init — not into a post-login checklist you'll forget.
-- **Two firewalls, edge first.** The Hetzner Cloud Firewall stops packets before
-  they reach the VM; host `ufw` is defense-in-depth. You need both.
-- **Honest about the trade-off.** No managed DB, no uptime SLA, phone support
-  only for dedicated-server customers. Name it; don't pretend it's AWS.
+click-ops in the console. A box you can't recreate from a file isn't a box, it's
+a pet.
 
 ## Decide before you create
 
@@ -139,8 +130,8 @@ hcloud firewall add-rule    app-edge --direction in --protocol tcp --port 22 --s
 
 ## SSH hardening rules
 
-- **Key-only auth.** `PasswordAuthentication no`. A password is brute-forceable;
-  an ed25519 key is not.
+- **Key-only auth.** `PasswordAuthentication no`, `PubkeyAuthentication yes`. A
+  password is brute-forceable; an ed25519 key is not.
 - **No root login.** `PermitRootLogin no` + a sudo user. Root over SSH is the
   single most-targeted login on the internet.
 - **fail2ban on.** Bans IPs after repeated failures — cheap insurance for the
@@ -149,16 +140,6 @@ hcloud firewall add-rule    app-edge --direction in --protocol tcp --port 22 --s
   harden anything. Do it if you like clean logs, but never *instead* of key-only
   + a firewall.
 
-Bad → Good:
-
-```diff
-- PermitRootLogin yes
-- PasswordAuthentication yes
-+ PermitRootLogin no
-+ PasswordAuthentication no
-+ PubkeyAuthentication yes
-```
-
 ## Hand off to Docker / Coolify
 
 "Host ready" means all of the following are true:
@@ -169,28 +150,29 @@ Bad → Good:
 - [ ] `ufw status` enabled with the same allowlist.
 - [ ] `unattended-upgrades` and `fail2ban` running.
 
-Then route the install/deploy: Coolify (the self-hosted PaaS) and container
-build/run are not this skill's job. Use the `coolify` skill for the Coolify
-install + app deploy flow, and the `docker` skill for Dockerfiles, compose, and
-image hardening. This skill stops at a clean, hardened host.
+This skill stops at a clean, hardened host. Then route the install/deploy:
+[`coolify`](../coolify/SKILL.md) for the Coolify install + app deploy flow,
+[`docker`](../docker/SKILL.md) for Dockerfiles, compose, and image hardening.
 
 ## Day-2
 
 - **Snapshot ≠ backup.** A snapshot is a one-off manual image you can boot from;
   the **Backups** add-on is automated, rotating, ~20% of the server price. A
-  snapshot you took once in March is not a backup strategy — for that, see the
-  `backups` skill.
+  snapshot you took once in March is not a backup strategy — for that, see
+  [`backups`](../backups/SKILL.md).
 - **Resize grows, never shrinks.** You can scale the disk up; you cannot scale it
   back down. Size conservatively or you're stuck paying for it.
 - **Volumes** for data you want to outlive/detach from the server. Keep databases
   and uploads on a volume so a server rebuild doesn't take the data with it.
 - **Reverse DNS** must match for outbound mail to be accepted — set the PTR in the
-  console/`hcloud` if the box sends email. Forward DNS records belong to the
-  `domains-dns` skill.
-- **No SLA, no managed DB.** There's no uptime guarantee and no managed-database
-  product — you run Postgres yourself, you monitor it yourself. For monitoring
-  and alerting, see the `monitoring` skill; treat the box as something you must
-  watch, not something Hetzner watches for you.
+  console/`hcloud` if the box sends email. Forward DNS records belong to
+  [`domains-dns`](../domains-dns/SKILL.md).
+- **No SLA, no managed DB.** There's no uptime guarantee, no managed-database
+  product, and phone support only for dedicated-server customers — you run
+  Postgres yourself, you monitor it yourself. For monitoring and alerting, see
+  [`monitoring`](../monitoring/SKILL.md); treat the box as something you must
+  watch, not something Hetzner watches for you. Name the trade-off to the user;
+  don't pretend it's AWS.
 
 ## Anti-patterns
 

package/skills/knowledge-ops/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: knowledge-ops
-description: "Use when an already-running 02-DOCS/ wiki needs day-to-day gardening — too many half-finished articles, a 600-line page that covers three unrelated topics, a note with no obvious home, orphan pages nothing links to, stale answers and superseded articles piling up, or two articles that contradict each other. This is the judgment layer over harness's automation: decide what is worth capturing (default: nothing), where it goes, how to title/split/merge it, build the See Also web, and prune to _archive (never delete). Triggers: 'limpia mi wiki', 'organiza mis notas', 'esto dónde va en la wiki', 'ordena la base de conocimiento', 'split this bloated article', 'where should this note live', 'scores.json says these three are orphans — fix the cross-links', 'prune the stale and superseded stuff'. NOT building, bootstrapping or sweeping the wiki engine (that is harness)."
+description: "Use when an already-running 02-DOCS/ wiki needs gardening judgment — what is worth capturing (default: nothing), where a loose note belongs, whether to split a bloated article or merge near-duplicates, how to link orphans back in, and what retires to _archive (never delete). NOT building or sweeping the wiki engine itself (that is `harness`)."
 tags: [knowledge-ops, wiki, 02-docs, knowledge-base, curation, cross-linking, pruning, knowledge-meta]
 recommends: [harness, decision-records, meeting-notes, sop-builder, research-ops, codebase-onboarding]
 origin: risco
@@ -8,7 +8,7 @@ origin: risco
 
 # Knowledge Ops — Garden the 02-DOCS Wiki
 
-*The engine is already running. `harness` built the `02-DOCS/` wiki and owns its automation — the inbox sweep, deterministic lint, scoring, gap detection, the self-improve loop. Your job is the four judgments that automation deliberately leaves to a human: what is worth capturing, how it should be shaped, how it connects, and what should retire. You are the gardener, not the machinery.*
+*The engine is already running. `harness` built the `02-DOCS/` wiki and owns its automation — the inbox sweep, deterministic lint, scoring, gap detection, the self-improve loop — and changing that machinery or filling the wiki in bulk stays with it. Yours are the four judgments automation deliberately leaves to a human: what is worth capturing, how it should be shaped, how it connects, and what should retire. You are the gardener, not the machinery.*
 
 ## Before you touch anything
 
@@ -29,7 +29,7 @@ Every gardening request is one of four operations. Identify which before you act
 | **Link** | Pages are unreachable or under-connected | `scores.json` orphan_penalty (=5), low inbound count | `## See Also` in articles, `index.md` |
 | **Prune** | Answers are stale, articles superseded, conflicts unresolved, gaps bloated | freshness, conflict annotations, old `[FILLED]` gaps | `_archive/`, `log.md`, `gaps.md` |
 
-Whichever you do, record a line in `wiki/log.md`. `log.md` is the OKF reserved change-log: new entries are **prepended at the top (newest first)**, ISO 8601 dates, and past entries are never edited or deleted. (`gaps.md` is the append-only file — new entries go at the bottom.) The exact entry shapes per operation live in `references/gardening-playbook.md`.
+Whichever you do, record a line in `wiki/log.md` under the reserved-file rule in **Safety rails** below. The exact entry shapes per operation live in `references/gardening-playbook.md`.
 
 ## Capture — the bar is high
 
@@ -44,7 +44,7 @@ Walk the altitude ladder, lowest rung first; stop at the first that fits:
 
 Worked examples for each rung are in `references/gardening-playbook.md`.
 
-**Topic choice.** Reuse an existing topic before inventing one, and keep `wiki/` exactly **one level of subdirs** deep (the protocol's rule). 
+**Topic choice.** Reuse an existing topic before inventing one, and keep `wiki/` exactly **one level of subdirs** deep (the protocol's rule).
 
 - Bad: `wiki/payments/stripe/webhooks/retries.md` (four levels deep).
 - Good: `wiki/payments/stripe-webhook-retries.md` (existing `payments/` topic, one level).
@@ -81,20 +81,19 @@ Every article earns **≥1 inbound link** or is a conscious leaf you can justify
 
 - **Conflicts:** you **flag** contradictions and the **human arbitrates**. Once they choose a winner, you may apply the resolution and annotate the loser — but you never auto-pick. Why: silently choosing a side is data corruption.
 - **Stale answers:** mark a page or archived copy with a `> ⚠ Stale — superseded YYYY-MM-DD` note rather than rewriting history.
-- **Compaction is bounded:** only `[FILLED YYYY-MM-DD]` gaps **older than 90 days** may be compacted, and only via a single marker prepended to `log.md`. `gaps.md` is append-only and `log.md` is newest-first (both immutable past entries) — gaps get a `[FILLED]` stamp, never a deletion.
-- **Log every prune** by prepending to `wiki/log.md` (newest first). Exact entry shapes per operation: `references/gardening-playbook.md`.
+- **Compaction is bounded:** only `[FILLED YYYY-MM-DD]` gaps **older than 90 days** may be compacted, and only via a single marker prepended to `log.md` — a gap gets a `[FILLED]` stamp, never a deletion.
+- **Log every prune** by prepending to `wiki/log.md`.
 
-A full worked prune session (stale + superseded + conflict + gap compaction, all logged) is in the playbook.
+A full worked prune session (stale + superseded + conflict + gap compaction, all logged) is in `references/gardening-playbook.md`.
 
-## Safety rails (inherited from the protocol)
+## Safety rails
 
-These are hard constraints, not suggestions. They come from `../harness/references/wiki-protocol.md` — do not override them.
+Inherited from `../harness/references/wiki-protocol.md` — do not override them; each one guards against a loss you cannot undo.
 
 1. **Preserve before overwrite.** Never overwrite an article without first copying the old version to `wiki/<topic>/_archive/<article>__YYYY-MM-DD.md`.
 2. **Never auto-resolve a conflict.** Flag it; the human arbitrates.
-3. **`gaps.md` is append-only; `log.md` is newest-first.** New `gaps.md` entries are appended at the bottom; new `log.md` entries are prepended at the top (the OKF reserved-file rule). Past entries in either are immutable — gaps get `[FILLED YYYY-MM-DD]`, nothing is ever edited out.
-4. **Log every change** by prepending to `wiki/log.md` (newest first).
-5. **Never touch an article whose `timestamp` is < 24h ago** without explicit user say-so. Why: it is likely still being worked. (`timestamp` is the OKF last-meaningful-edit field, ISO 8601 — see `../harness/references/wiki-protocol.md` "## Conventions".)
+3. **The reserved files only grow.** Log every change in `wiki/log.md`, the OKF reserved change-log: new entries are **prepended at the top (newest first)**, ISO 8601 dates. `gaps.md` is the append-only one — new entries go at the bottom. Past entries in either are immutable: a gap gets a `[FILLED YYYY-MM-DD]` stamp, nothing is ever edited out or deleted.
+4. **Never touch an article whose `timestamp` is < 24h ago** without explicit user say-so. Why: it is likely still being worked. (`timestamp` is the OKF last-meaningful-edit field, ISO 8601 — see `../harness/references/wiki-protocol.md` "## Conventions".)
 
 ## Anti-patterns
 
@@ -117,9 +116,7 @@ Route elsewhere when the request is not gardening an existing wiki:
 |---------|----------|
 | Build/bootstrap the wiki, run an inbox sweep, scaffold `01-TOOLS`, generate root `CLAUDE.md` | `harness` (`../harness/SKILL.md`) — it owns the engine |
 | Turn a meeting transcript into a recap with action items + owners | `meeting-notes` (`../meeting-notes/SKILL.md`) |
-| Author a decision record (ADR) with alternatives, status, review cadence | `decision-records` (you may *file* one; that skill *authors* the discipline) |
+| Author a decision record (ADR) with alternatives, status, review cadence | `decision-records` (`../decision-records/SKILL.md`) — you may *file* one; that skill *authors* the discipline |
 | Document a repeatable procedure step by step | `sop-builder` (`../sop-builder/SKILL.md`) |
-| First-pass walkthrough of an unfamiliar codebase | `codebase-onboarding` |
-| Run a literature / source-gathering research project | `research-ops` |
-
-The sharp line: changing the wiki's machinery or filling it in bulk is `harness`. Exercising judgment over what an already-running wiki should contain and how it should be shaped is `knowledge-ops`.
+| First-pass walkthrough of an unfamiliar codebase | `codebase-onboarding` (`../codebase-onboarding/SKILL.md`) |
+| Run a literature / source-gathering research project | `research-ops` (`../research-ops/SKILL.md`) |

package/skills/lead-gen/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lead-gen
-description: "Use when you need to find and qualify prospects, build a target list, or score and prioritize leads before anyone reaches out — defining an ICP, sourcing named accounts/contacts from Apollo/ZoomInfo/Clay, deduping against the CRM, and ranking with a fit+intent+engagement model. Triggers: 'build me a prospect list', 'who should we sell to', 'score these leads', 'which accounts do we call first', 'tighten our ICP', 'is this cold list GDPR-safe', 'necesito una lista de clientes potenciales', 'califica estos leads', 'a qui truquem primer'. NOT writing or sending the outreach (that is cold-outreach), NOT tracking the deal after first contact (that is sales-pipeline)."
+description: "Use when building and qualifying a prospect list before anyone reaches out — a falsifiable ICP, named accounts/contacts from Apollo/ZoomInfo/Clay, deduped against the CRM, tiered by fit+intent+engagement. NOT writing or sending the outreach (that is cold-outreach), NOT tracking the deal after first contact (that is sales-pipeline)."
 tags: [lead-generation, prospecting, icp, lead-scoring, sales]
 recommends: [cold-outreach, sales-pipeline, market-research, data-scraper, spreadsheet-ops, email-deliverability, gdpr-privacy]
 origin: risco
@@ -8,9 +8,7 @@ origin: risco
 
 # Lead Gen — The List and the Model That Ranks It
 
-*You turn "we sell X to Y" into a deduplicated, scored, compliance-cleared roster of named accounts and people. You define the target, you build the list, you rank it — then you stop. You do not write the email and you do not run the deal.*
-
-The identity of this skill is **the list and its scoring model**, not the messages sent to it and not the pipeline it becomes. Everything you produce is a *prioritized roster + the rationale that ranked it*. The hand-off is the finish line, not the campaign.
+*You turn "we sell X to Y" into a deduplicated, scored, compliance-cleared roster of named accounts and people. You define the target, you build the list, you rank it — then you stop. What you produce is a prioritized roster plus the rationale that ranked it; the hand-off is the finish line, not the campaign.*
 
 ## The pipeline — three phases, two gates
 
@@ -151,5 +149,3 @@ This skill stops at a scored, compliance-cleared list. From there:
 - The **A/B tiers + persona context** go to `../cold-outreach/SKILL.md` — that skill writes the message and the cadence; you do not.
 - **Accepted leads** (worked and responsive) go to `../sales-pipeline/SKILL.md` — that skill tracks stages, forecasts, and manages the deal; you do not.
 - If the request is really "how big is this market / which segment?" with no named list, that is `../market-research/SKILL.md`, not this skill.
-
-When the deliverable would be a message, a pipeline stage, or a market sizing — route. Your job ended at the ranked roster.