@ericrisco/rsc 0.1.38 → 0.1.40

package/README.md

@@ -12,7 +12,7 @@
   ██    ██   ███████     ███████ 
 ```
 
-# `rsc` — 248 agent skills, one CLI, zero bloat
+# `rsc` — 256 agent skills, one CLI, zero bloat
 
 **A self-recommending skill catalog for 17 coding assistants** — Claude Code,
 Codex, GitHub Copilot, Cursor, Gemini, Windsurf, Cline, Antigravity, Zed and more.
@@ -243,7 +243,7 @@ just asks in plain language.
 
 ## The catalog
 
-249 skills, grouped by what you're trying to do. Click any skill to read its
+257 skills, grouped by what you're trying to do. Click any skill to read its
 `SKILL.md`. It fires on its own when a task matches.
 
 ### 🧭 Core & control plane
@@ -324,6 +324,12 @@ Operate the big automation platforms **programmatically or via MCP** — create
 
 [replicate](skills/replicate/) · [runpod](skills/runpod/) · [modal](skills/modal/) · [huggingface](skills/huggingface/) · [ollama](skills/ollama/) · [together-fireworks](skills/together-fireworks/) · [fal](skills/fal/)
 
+### 🎓 AI — train it
+
+Train and adapt open models end to end: classic ML, deep learning, NLP, fine-tuning (with Unsloth), building training datasets, choosing open-weight models by license/size, and serving them at throughput with vLLM. Facts that move monthly (versions, model licenses) are verified at author time and hedged.
+
+[machine-learning](skills/machine-learning/) · [deep-learning](skills/deep-learning/) · [nlp](skills/nlp/) · [finetuning](skills/finetuning/) · [training-data](skills/training-data/) · [unsloth](skills/unsloth/) · [open-weights](skills/open-weights/) · [vllm](skills/vllm/)
+
 ### 🗣️ Languages
 
 [typescript](skills/typescript/) · [python](skills/python/) · [java](skills/java/) · [csharp-dotnet](skills/csharp-dotnet/) · [php](skills/php/) · [ruby](skills/ruby/) · [cpp](skills/cpp/) · [elixir](skills/elixir/) · [bash-scripting](skills/bash-scripting/) · [sql](skills/sql/) · [go](skills/go/)

package/manifest.json

@@ -1,7 +1,7 @@
 {
-  "version": "0.1.38",
+  "version": "0.1.40",
   "counts": {
-    "skills": 249
+    "skills": 257
   },
   "skills": [
     {
@@ -1191,6 +1191,32 @@
       ],
       "profiles": []
     },
+    {
+      "id": "deep-learning",
+      "description": "Use when training or debugging a neural network in PyTorch — writing the training loop, chasing loss that won't drop or goes NaN, adding mixed precision (AMP), scaling across GPUs, or making a run reproducible. Covers tensors/autograd/nn.Module, torch.compile, the forward→loss→backward→step→zero_grad loop and its silent bugs, AdamW + cosine/warmup schedulers, DDP vs FSDP vs DeepSpeed ZeRO, checkpointing and seeds. PyTorch-first (JAX/TF exist). Triggers: 'my training loss isn't decreasing', 'loss becomes NaN after a few steps', 'how do I use torch.autocast and GradScaler', 'train this model across 4 GPUs', 'val accuracy is worse than train and I forgot model.eval()', 'gradients seem to add up across batches', 'build a CNN from scratch and train it', 'entrenar una xarxa neuronal des de zero amb PyTorch'. NOT adapting a pretrained LLM with LoRA/QLoRA (that is finetuning); NOT classic/tabular models like XGBoost or sklearn (that is machine-learning); NOT tokenization or NLP task metrics (that is nlp).",
+      "tags": [
+        "pytorch",
+        "deep-learning",
+        "neural-networks",
+        "training-loop",
+        "autograd",
+        "mixed-precision",
+        "amp",
+        "ddp",
+        "fsdp",
+        "optimizer",
+        "lr-scheduler",
+        "reproducibility",
+        "torch-compile"
+      ],
+      "recommends": [
+        "machine-learning",
+        "finetuning",
+        "nlp",
+        "python"
+      ],
+      "profiles": []
+    },
     {
       "id": "deployment",
       "description": "Use when containerizing an app, writing a Dockerfile, setting up GitHub Actions CI/CD, choosing a deploy target, or deploying to Coolify, Vercel, or a Hetzner VPS — multi-stage builds (FastAPI/uv, Go/distroless, Next.js standalone, Flutter web, Postgres), BuildKit build secrets, image scanning (trivy/hadolint), OIDC to registries (no long-lived secrets), least-privilege GITHUB_TOKEN, zero-downtime/rolling deploys, env/secrets flow GitHub→Coolify, healthchecks, rollback, and a hosting decision matrix (Vercel vs Hetzner+Coolify vs a third option). Trigger phrases: 'dockerize', 'write a Dockerfile', 'CI pipeline', 'GitHub Actions', 'deploy', 'ship it', 'where should I host this', 'Coolify', 'Vercel', 'Hetzner', 'VPS', 'docker-compose for local dev'.",
@@ -1697,6 +1723,30 @@
       ],
       "profiles": []
     },
+    {
+      "id": "finetuning",
+      "description": "Use when adapting an open-weight model to a target FORM or BEHAVIOR — tone, output format, domain style, a reasoning/tool-calling pattern — via LoRA/QLoRA or full fine-tuning with TRL SFTTrainer and then preference optimization (DPO/ORPO/KTO/GRPO); when choosing fine-tune vs prompt vs RAG vs longer context; when setting LoRA r/alpha/target_modules; when eval loss climbs while train loss keeps falling; when the adapter seems to have learned nothing; when inference outputs garbage after a run. Triggers: 'fine-tune Llama/Qwen on our data', 'LoRA vs QLoRA vs full fine-tune', 'SFT then DPO/ORPO/KTO/GRPO', 'set target_modules / rank / alpha', 'my fine-tune overfits', 'the model forgot everything after training', 'write a GRPO reward function', 'ajustar un modelo amb LoRA amb les nostres dades'. NOT adding facts or fresh knowledge to a model (that is rag); NOT the fast single-GPU Unsloth backend or GGUF export (that is unsloth); NOT serving the trained model (that is vllm).",
+      "tags": [
+        "finetuning",
+        "lora",
+        "qlora",
+        "sft",
+        "dpo",
+        "grpo",
+        "peft",
+        "trl",
+        "preference-optimization"
+      ],
+      "recommends": [
+        "training-data",
+        "unsloth",
+        "open-weights",
+        "huggingface",
+        "vllm",
+        "rag"
+      ],
+      "profiles": []
+    },
     {
       "id": "firebase",
       "description": "Use when building on Firebase — modeling Firestore data, writing or auditing Security Rules, wiring Auth, shipping Cloud Functions, storing files in Cloud Storage, or choosing modular Web/Admin SDK imports — and when symptoms appear like 'my database is open to the internet', 'rules reject my query', a counter stuck at 1 write/sec, custom-claim RBAC, or a callable function. Triggers: 'firestore.rules audit', 'denormalize for read paths', 'collection vs subcollection', 'my query works in the emulator but fails in prod with requires-an-index', 'set a custom admin claim', 'regles de seguretat de Firestore', 'mi base de datos está abierta a internet'. NOT managed-Postgres BaaS with SQL and RLS (that is supabase).",
@@ -2203,7 +2253,7 @@
     },
     {
       "id": "huggingface",
-      "description": "Use when running open models or working on the Hugging Face platform: calling a model via the Inference Providers router or InferenceClient, downloading/uploading/versioning repos on the Hub with the hf CLI, deploying a dedicated Inference Endpoint with scale-to-zero, hosting a Gradio Space with ZeroGPU, picking an open model by task/license/size, or loading a model locally with transformers. Triggers: 'call an open model through Hugging Face', 'InferenceClient embeddings', 'hf download/upload', 'write a model card', 'router.huggingface.co', 'my hf-inference serverless call 404s on a 70B model', 'scale-to-zero endpoint', 'ZeroGPU Space', 'desplegar un modelo de Hugging Face con escalado a cero', 'necesito controlar el coste de inferencia en HF'. NOT serving a model locally on your own machine (that is ollama), NOT renting and operating your own GPU box (that is runpod), NOT generating creative images via a hosted API (that is replicate-images).",
+      "description": "Use when running open models or working on the Hugging Face platform: calling a model via the Inference Providers router or InferenceClient, downloading/uploading/versioning repos on the Hub with the hf CLI, deploying a dedicated Inference Endpoint with scale-to-zero, hosting a Gradio Space with ZeroGPU, picking an open model by task/license/size, or loading a model locally with transformers. Triggers: 'call an open model through Hugging Face', 'InferenceClient embeddings', 'hf download/upload', 'write a model card', 'router.huggingface.co', 'my hf-inference serverless call 404s on a 70B model', 'scale-to-zero endpoint', 'ZeroGPU Space', 'desplegar un modelo de Hugging Face con escalado a cero'. NOT serving a model locally on your own machine (that is ollama), NOT renting and operating your own GPU box (that is runpod), NOT generating creative images via a hosted API (that is replicate-images), NOT fine-tuning with trl/peft (that is finetuning), NOT building training datasets (that is training-data).",
       "tags": [
         "huggingface",
         "inference-providers",
@@ -2688,6 +2738,31 @@
       ],
       "profiles": []
     },
+    {
+      "id": "machine-learning",
+      "description": "Use when the task is a classic/tabular machine-learning problem — predict a column from rows of features with trees and scikit-learn: fit a RandomForest / XGBoost / LightGBM classifier or regressor, build a leak-proof Pipeline + ColumnTransformer, choose a cross-validation scheme (stratified / k-fold / time-series / grouped), pick the right metric on imbalanced classes (precision/recall/F1/ROC-AUC/PR-AUC, not accuracy), or debug a model that aced CV then collapsed in production. Triggers: 'train a model to predict churn/fraud/price', 'my ROC-AUC is 0.99 — is that leakage', 'which metric for imbalanced classes', 'cross-validation without leaking', 'XGBoost vs LightGBM', 'add a DummyClassifier baseline', 'entrena un modelo de clasificación tabular con scikit-learn'. NOT neural-net / PyTorch training (that is deep-learning), NOT cleaning the raw dirty table first (that is data-cleaning), NOT BI dashboards or forecasting a dated series (that is analytics/forecasting), NOT text/token modeling (that is nlp).",
+      "tags": [
+        "machine-learning",
+        "scikit-learn",
+        "sklearn",
+        "xgboost",
+        "lightgbm",
+        "tabular",
+        "gbdt",
+        "cross-validation",
+        "data-leakage",
+        "classification",
+        "regression",
+        "pipeline"
+      ],
+      "recommends": [
+        "deep-learning",
+        "data-cleaning",
+        "python",
+        "training-data"
+      ],
+      "profiles": []
+    },
     {
       "id": "make",
       "description": "Use when operating Make.com (formerly Integromat) programmatically — driving its REST API v2 or the Make MCP server from code or an agent to create, read, update, activate, run, clone, or delete scenarios, connections, hooks, and data stores. Triggers: 'create a Make scenario via the API', 'export a scenario blueprint, mutate it, and push it back', 'start/stop/run a Make scenario from a script', 'clone this Integromat scenario into another team', 'connect the Make MCP server so an agent runs my scenarios as tools', 'my valid Make API token returns an auth error' (zone trap), 'automatiza escenarios de Make.com desde la API'. NOT designing what the flow should do — trigger, branching, mapping, dedup, error path (automation-flows), NOT choosing Make vs n8n vs Zapier by billing model (automation-strategy), NOT operating n8n / Zapier / Power Automate (their skills), NOT a generic typed REST client with pagination/backoff (api-connector-builder) or an inbound webhook receiver in your own app (webhooks).",
@@ -3035,6 +3110,29 @@
       ],
       "profiles": []
     },
+    {
+      "id": "nlp",
+      "description": "Use when choosing how to tokenize text or which transformer type fits an NLP task, when a tokenizer over-fragments non-English text or inflates token cost, when picking a language metric, or when classification / NER / summarization output looks wrong and you can't tell whether the tokenizer, the architecture, or the metric is at fault. Covers BPE / WordPiece / SentencePiece-Unigram / byte-level BPE, special tokens, encoder (BERT) vs decoder (GPT) vs encoder-decoder (T5) choice, classification, NER, seq2seq, sentence embeddings, and metrics (F1, entity-F1, BLEU / ROUGE / chrF, perplexity, LLM-as-judge). Triggers: 'BPE or WordPiece', 'BERT vs GPT vs T5 for this task', 'tokenizer splits Catalan into too many tokens', 'is BLEU good for summaries', 'entity F1 for NER', 'quin model faig servir per classificar text'. NOT retrieval / vector search (that is embeddings-search), NOT the RAG loop (that is rag), NOT prompt wording (that is prompt-engineering), NOT training the net (that is finetuning / deep-learning).",
+      "tags": [
+        "nlp",
+        "tokenization",
+        "bpe",
+        "wordpiece",
+        "ner",
+        "text-classification",
+        "bleu",
+        "rouge",
+        "perplexity",
+        "transformers"
+      ],
+      "recommends": [
+        "deep-learning",
+        "embeddings-search",
+        "rag",
+        "training-data"
+      ],
+      "profiles": []
+    },
     {
       "id": "no-code-app",
       "description": "Use when building an app on a no-code/low-code platform (Bubble, Softr, Glide, with Airtable/Xano backends) — picking the tool, modeling the data, taming usage/cost metering, or planning the exit before lock-in. Triggers: 'build a CRM without code', 'Bubble or Glide for my MVP', 'monta una app sin codi per reserves', 'my Bubble bill suddenly exploded' (workload-unit metering), 'Glide updates overage', 'how do I avoid getting locked into a no-code tool', 'when should I stop and write real code'. NOT a coded web app (that is nextjs).",
@@ -3134,6 +3232,24 @@
       ],
       "profiles": []
     },
+    {
+      "id": "open-weights",
+      "description": "Use when choosing an open-weight LLM and clearing it for use — which family and size fit a task, hardware and budget, and above all whether the license lets you ship (Llama, Qwen, Mistral/Mixtral, Gemma, DeepSeek, Phi, gpt-oss, and others). Owns the license-CLASS map (OSI-open Apache/MIT vs custom-community like Llama/Gemma vs non-commercial/restricted like the original Codestral) and the always-verify-the-model-card rule, plus size-to-VRAM budgeting and quant formats (GGUF/AWQ/GPTQ, what Q4_K_M means). Triggers: 'which open model should I use', 'can I use Llama/Gemma commercially', 'is Qwen Apache-2.0', 'what open LLM fits a 24GB GPU', 'is this license safe to ship in a product', 'quin model obert puc fer servir legalment'. NOT how to download or host on HF (that is huggingface), NOT running it locally (that is ollama), NOT serving at throughput (that is vllm), NOT fine-tuning it (that is finetuning) — this layer only tells you WHICH model and whether the license permits it, then hands off.",
+      "tags": [
+        "open-weights",
+        "open-source-llm",
+        "model-selection",
+        "model-licenses",
+        "llama-qwen-mistral-gemma"
+      ],
+      "recommends": [
+        "huggingface",
+        "ollama",
+        "finetuning",
+        "vllm"
+      ],
+      "profiles": []
+    },
     {
       "id": "orient",
       "description": "Always-on. The brújula: after every action keep the human oriented — situate them on the project map, say what just happened, teach the why at their level, and propose the next step as a question. NEVER end a turn in seco (dead-end). Reads technical_level + accompaniment_level from 02-DOCS/wiki/harness/user-profile.md and calibrates how much it explains; rewrites the dial when the user asks for more/less ('explícame más', 'explícame menos', 'no me expliques tanto', 'enséñame'). Complements suggest (which installs missing skills) — orient guides the person, not the toolbox. Fires on every turn that finishes an action, reaches a decision fork, or leaves the user unsure what to do next.",
@@ -4731,6 +4847,29 @@
       ],
       "profiles": []
     },
+    {
+      "id": "training-data",
+      "description": "Use when assembling or curating the corpus a fine-tune trains on: turning raw examples into JSONL in the format a trainer expects (Alpaca instruction, conversational messages, DPO preference pairs, KTO binary-label), matching your data to the model's chat template, generating synthetic or distilled examples, deduplicating and decontaminating against eval sets, or quality-filtering. Triggers: 'what format should my fine-tuning dataset be in', 'build a DPO preference dataset', 'convert my Q&A into the messages/chat format', 'my chat template does not match my training data', 'generate synthetic instruction data with distilabel', 'dedup and decontaminate my training set', 'quants exemples necessito i com filtro la qualitat del dataset abans d'entrenar'. NOT cleaning tabular rows/nulls/dtypes (that is data-cleaning), NOT building a retrieval corpus of chunks+embeddings (that is embeddings-search), NOT running the trainer or picking LoRA hyperparameters (that is finetuning/unsloth).",
+      "tags": [
+        "training-data",
+        "fine-tuning-dataset",
+        "jsonl",
+        "chat-template",
+        "preference-data",
+        "dpo",
+        "kto",
+        "synthetic-data",
+        "decontamination",
+        "dataset-curation"
+      ],
+      "recommends": [
+        "finetuning",
+        "unsloth",
+        "huggingface",
+        "data-cleaning"
+      ],
+      "profiles": []
+    },
     {
       "id": "translation-l10n",
       "description": "Use when adding a second or Nth language to a web/app product, wiring i18n plumbing (extract strings, ICU messages, locale routing), fixing broken plurals or dates, or making a UI survive other languages (RTL, text expansion). Triggers: 'ship the app in French and Arabic', 'set up next-intl routing with generateStaticParams', 'our Russian plurals always show the singular', 'German text overflows the buttons', 'dates still show American format for Spanish users', 'the Arabic layout is mirrored wrong', 'traducir la app al árabe y montar el glosario', 'necessito localitzar el producte'. NOT defining the brand's tone in one language (that is brand-voice).",
@@ -4839,6 +4978,26 @@
         "full"
       ]
     },
+    {
+      "id": "unsloth",
+      "description": "Use when fine-tuning an open-weight LLM fast on ONE GPU with low VRAM — Unsloth's FastLanguageModel/FastModel + 4-bit QLoRA + trl SFTTrainer, response-only loss masking via get_chat_template/train_on_responses_only, GRPO reasoning FT, and export to merged-16bit / GGUF / push_to_hub for Ollama or vLLM. Triggers: 'fine-tune Llama/Qwen/Gemma/gpt-oss on a single 16GB/24GB GPU', 'QLoRA OOMs on my GPU, make it fit', 'train ~2x faster with less VRAM', 'why is my loss covering the prompt / how do I mask the user turn', 'save my LoRA as GGUF Q4_K_M for Ollama', 'ajustar un modelo en una sola GPU sense quedar-me sense VRAM'. NOT whether/why/which method to fine-tune or trl/peft theory (that is finetuning), NOT running the exported GGUF locally (that is ollama), NOT serving-engine flags/throughput (that is vllm), NOT building the JSONL dataset (that is training-data).",
+      "tags": [
+        "unsloth",
+        "qlora",
+        "lora",
+        "single-gpu",
+        "gguf",
+        "fine-tuning"
+      ],
+      "recommends": [
+        "finetuning",
+        "training-data",
+        "open-weights",
+        "ollama",
+        "huggingface"
+      ],
+      "profiles": []
+    },
     {
       "id": "vector-db",
       "description": "Use when operating a vector store as a data layer — choosing or migrating between Pinecone, Qdrant, Weaviate, or pgvector; designing a collection/index (distance metric, dimensions, HNSW m/ef_construction, named vectors); filtering on metadata/payload; running hybrid dense+sparse search; or picking quantization to cut RAM and cost. Symptoms: search returns garbage, filters get silently ignored, recall is low, queries are slow, the bill is too high, a filtered query returns fewer than k rows. Triggers: 'set up a vector database', 'my similarity search ignores the metadata filter', 'ef_search vs recall', 'move off Pinecone to pgvector to cut cost', 'hybrid search with RRF', 'why does my filtered query return fewer than k results', 'crear una colección en Qdrant con cuantización binaria', 'la cerca vectorial retorna resultats dolents'. NOT how to produce, chunk, or judge embeddings (that is embeddings-search).",
@@ -4919,6 +5078,25 @@
       ],
       "profiles": []
     },
+    {
+      "id": "vllm",
+      "description": "Use when self-hosting an open-weight LLM for high-throughput, concurrent serving with vLLM — running `vllm serve` as an OpenAI-compatible endpoint, splitting a model across GPUs with tensor/pipeline parallelism, loading AWQ/GPTQ/FP8/compressed-tensors quants, serving one or many LoRA adapters, or debugging KV-cache OOM from --gpu-memory-utilization / --max-model-len. Triggers: 'serve a 70B to many users at once', 'point my OpenAI client at a self-hosted model', 'split a model across 4 GPUs with tensor parallel', 'why does vllm OOM at long context', 'serve my fine-tuned LoRA adapter', 'health check my vllm server', 'servir un modelo abierto con alta concurrencia en mis propias GPUs'. NOT renting/provisioning the GPU box itself (that is runpod / modal), NOT single-user laptop inference (that is ollama), NOT a hosted inference API you do not operate (that is together-fireworks / huggingface).",
+      "tags": [
+        "vllm",
+        "llm-serving",
+        "inference-server",
+        "tensor-parallel",
+        "quantization"
+      ],
+      "recommends": [
+        "open-weights",
+        "finetuning",
+        "runpod",
+        "modal",
+        "ollama"
+      ],
+      "profiles": []
+    },
     {
       "id": "vue-nuxt",
       "description": "Use when building, reviewing, or optimizing a Vue 3 + Nuxt 4 app — Composition API/`<script setup>`, SSR/SSG/hybrid rendering, the `app/`+`server/` structure, SSR-safe data fetching and shared state, Nitro server routes, reactivity/hydration discipline. Triggers: `.vue` SFCs, `useFetch`/`useAsyncData`/`$fetch`, `useState`/Pinia, `defineModel`/`useTemplateRef`, hydration node mismatch, double-fetch on SSR, `server/api` handlers, `routeRules`, Nuxt 3→4 migration, `nuxt.config.ts`, 'app SSR no hidrata', 'per què es fa doble fetch'. NOT React/RSC (that is nextjs), NOT a static multi-framework site (that is astro).",

package/package.json

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

package/scripts/lib/domains.js

@@ -16,6 +16,7 @@ export const DOMAINS = [
   { title: 'Data & analytics', ids: ['analytics', 'dashboard', 'kpi-framework', 'reporting', 'ab-testing', 'forecasting', 'data-cleaning', 'business-intelligence'] },
   { title: 'AI — build it in', ids: ['building-agents', 'rag', 'embeddings-search', 'prompt-engineering', 'llm-pipeline', 'agent-eval', 'chatbot', 'ai-media', 'replicate-images', 'structured-extraction', 'agent-safety', 'cost-tracking'] },
   { title: 'AI — run it on', ids: ['replicate', 'runpod', 'modal', 'huggingface', 'ollama', 'together-fireworks', 'fal'] },
+  { title: 'AI — train it', ids: ['machine-learning', 'deep-learning', 'nlp', 'finetuning', 'training-data', 'unsloth', 'open-weights', 'vllm'] },
   { title: 'Languages', ids: ['typescript', 'python', 'java', 'csharp-dotnet', 'php', 'ruby', 'cpp', 'elixir', 'bash-scripting', 'sql', 'go'] },
   { title: 'Frameworks & app stacks', ids: ['fastapi', 'nextjs', 'react', 'react-native', 'vue-nuxt', 'angular', 'svelte', 'astro', 'solid-js', 'htmx', 'nodejs', 'nestjs', 'django', 'laravel', 'rails', 'spring-boot', 'phoenix', 'flutter', 'swift-ios', 'kotlin-android', 'compose-multiplatform', 'expo', 'tauri', 'electron', 'rust', 'wordpress', 'shopify', 'no-code-app', 'chrome-extension', 'api-design'] },
   { title: 'Game development', ids: ['godot', 'unity', 'unreal', 'game-design', 'game-storytelling', 'level-design', 'gamedev-shaders', 'gamedev-multiplayer', 'gamedev-physics', 'gamedev-pathing', 'gamedev-shipping'] },

package/scripts/lib/recommend.js

@@ -21,6 +21,12 @@ const OUTCOMES = {
   unreal: 'Your game (Unreal)',
   'game-design': "Design a game that's fun",
   'fable-operator': 'Reason it through, reliably',
+  finetuning: 'Fine-tune an open model',
+  'machine-learning': 'Build a classic ML model',
+  'deep-learning': 'Train a neural network',
+  nlp: 'Do NLP the right way',
+  'open-weights': 'Pick an open-weight model',
+  vllm: 'Serve open models at scale',
   'automation-strategy': 'Decide what to automate',
   n8n: 'Automate with n8n (API/MCP)',
   make: 'Automate with Make (API/MCP)',

package/skills/automation-strategy/SKILL.md

@@ -78,9 +78,9 @@ Pick on **billing unit first** — it's the axis that dictates cost at scale, an
 | **Billing unit** | per **execution** (whole run = 1, any # of steps); self-host = $0 | per **credit** (each module action = 1; was "operations", renamed 2025-08-27) | per **task** (every action counts) | per **user** or per **flow** (premium); bundled with many M365 plans |
 | **Best cost shape** | few long/complex flows, high volume | moderate multi-step flows | many short simple flows | teams already paying for M365 |
 | **Self-host / data residency** | **yes** — your infra, your data | no (EU/US regions only) | no | Microsoft cloud / Dataverse regions |
-| **Ecosystem fit** | technical teams, raw HTTP, code nodes | mid-market, deep per-app modules | widest app catalog (~8,000+) | **native to Microsoft 365** — Teams, SharePoint, Outlook, Dataverse |
+| **Ecosystem fit** | technical teams, raw HTTP, code nodes | mid-market, deep per-app modules | widest app catalog (~9,000+) | **native to Microsoft 365** — Teams, SharePoint, Outlook, Dataverse |
 | **Programmatic + MCP maturity** | public REST API to CRUD workflows; community MCP; strongest for code-driven ops | management API + MCP support maturing | rich API for actions + Zapier MCP to expose actions to agents — **but no public API to create Zaps** | Flow management APIs + solutions/ARM — **but no clean public API to create end-user "My flows"** |
-| **Portability** | high — export/import JSON | low — no portable export | low — no portable export | low — tied to MS solutions |
+| **Portability** | high — export/import JSON + self-hostable runtime | medium — blueprint export/import, but runs only on Make | low — no portable export | low — tied to MS solutions |
 
 **Routing shortcuts:** already living in Microsoft 365 → **Power Automate** (`../power-automate/SKILL.md`). Data must stay on your own infra, or high volume where execution-billing wins → **n8n** (`../n8n/SKILL.md`). Obscure app, non-technical owner → **Zapier** (`../zapier/SKILL.md`). Deep per-app modules, mid volume → **Make** (`../make/SKILL.md`).
 

package/skills/automation-strategy/references/platform-selection-matrix.md

@@ -33,10 +33,10 @@ because it rides existing M365 licenses.
 | Axis | n8n | Make | Zapier | Power Automate |
 | --- | --- | --- | --- | --- |
 | Free / entry | self-host free; cloud Starter ≈ €20/mo | ≈ 1,000 credits free; Core ≈ $9/mo | 100 tasks/mo free; Pro ≈ $19.99/mo | bundled in many M365 plans; premium add-ons |
-| App breadth | ~1,000 nodes + generic HTTP + code | ~1,500, often deep per app | ~8,000+ — widest catalog | strong on MS + growing 3rd-party connectors |
+| App breadth | ~1,000 nodes + generic HTTP + code | ~1,500, often deep per app | ~9,000+ apps — widest catalog | strong on MS + growing 3rd-party connectors |
 | Self-host / data residency | **yes — your infra** | no (EU/US regions) | no | Microsoft cloud / Dataverse regions |
 | Who runs/maintains it | technical; you run the box | mid; visual but rich | non-technical-friendly | IT/business in a Microsoft shop |
-| Portability | high (export/import JSON) | low (no portable export) | low (no portable export) | low (tied to MS solutions) |
+| Portability | high (export/import JSON + self-hostable runtime) | medium (blueprint export/import, runs only on Make) | low (no portable export) | low (tied to MS solutions) |
 | Complex logic / code | code nodes, sandboxed by default (n8n 2.0) | functions + routers | limited (Code by Zapier) | expressions + Azure Functions escape hatch |
 
 ## Programmatic + MCP maturity (honest)

package/skills/deep-learning/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: deep-learning
+description: "Use when training or debugging a neural network in PyTorch — writing the training loop, chasing loss that won't drop or goes NaN, adding mixed precision (AMP), scaling across GPUs, or making a run reproducible. Covers tensors/autograd/nn.Module, torch.compile, the forward→loss→backward→step→zero_grad loop and its silent bugs, AdamW + cosine/warmup schedulers, DDP vs FSDP vs DeepSpeed ZeRO, checkpointing and seeds. PyTorch-first (JAX/TF exist). Triggers: 'my training loss isn't decreasing', 'loss becomes NaN after a few steps', 'how do I use torch.autocast and GradScaler', 'train this model across 4 GPUs', 'val accuracy is worse than train and I forgot model.eval()', 'gradients seem to add up across batches', 'build a CNN from scratch and train it', 'entrenar una xarxa neuronal des de zero amb PyTorch'. NOT adapting a pretrained LLM with LoRA/QLoRA (that is finetuning); NOT classic/tabular models like XGBoost or sklearn (that is machine-learning); NOT tokenization or NLP task metrics (that is nlp)."
+tags: [pytorch, deep-learning, neural-networks, training-loop, autograd, mixed-precision, amp, ddp, fsdp, optimizer, lr-scheduler, reproducibility, torch-compile]
+recommends: [machine-learning, finetuning, nlp, python]
+origin: risco
+---
+
+# deep-learning — train a neural net in PyTorch without the silent bugs
+
+You own **training and understanding neural networks in PyTorch**: the loop, autograd, mixed
+precision, optimizers/schedulers, multi-GPU, and the reproducibility/checkpoint hygiene that
+separates a real result from a lucky one. Nets from scratch, vision, custom architectures — all
+here. This is PyTorch-first by design: JAX and TensorFlow are real and fine, but the patterns,
+APIs, and gotchas below are Torch's.
+
+**Version reality (verify at author time).** Current stable is PyTorch **2.x** — ~**2.13** as of
+mid-2026 (`pytorch.org/get-started`, releases move fast; don't hard-pin a minor). Everything below
+is stable 2.x API. The one namespace shift to know: AMP now lives under `torch.amp`
+(`torch.amp.GradScaler("cuda")`), not the old `torch.cuda.amp.*`.
+
+## Am I in the right skill?
+
+| You are doing… | Skill |
+|---|---|
+| Training/debugging a net in PyTorch (from scratch, vision, custom loop, AMP, multi-GPU) | **deep-learning (here)** |
+| Adapting a *pretrained LLM* — LoRA/QLoRA, SFT, trl/peft | [`finetuning`](../finetuning/SKILL.md) |
+| Classic/tabular — sklearn, XGBoost/LightGBM, feature engineering | [`machine-learning`](../machine-learning/SKILL.md) |
+| Tokenization, NLP task modeling, task metrics (F1/BLEU/ROUGE) | [`nlp`](../nlp/SKILL.md) |
+
+If the model is a from-scratch or vision/custom net and you're writing the loop yourself, stay.
+
+## 1. PyTorch essentials
+
+Three objects carry everything.
+
+- **Tensor** — an n-d array on a `device` (`cpu`/`cuda`/`mps`) with a `dtype`. `requires_grad=True`
+  makes autograd track ops on it. `.to(device)` / `.detach()` / `.item()` are the moves you use
+  constantly; `.item()` pulls a Python scalar and **drops the graph** (see the loop bugs below).
+- **autograd** — a tape. Every op on a `requires_grad` tensor records a node; `loss.backward()`
+  walks it and *accumulates* into each leaf's `.grad`. "Accumulates" is the word that bites people
+  (§2). Wrap read-only regions in `torch.no_grad()` to skip taping.
+- **`nn.Module`** — the model container. `__init__` registers submodules/params; `forward` defines
+  compute. `model.parameters()` feeds the optimizer; `model.train()` / `model.eval()` flip
+  train-vs-eval behavior for Dropout and BatchNorm.
+
+```python
+import torch, torch.nn as nn
+device = "cuda" if torch.cuda.is_available() else "cpu"
+
+class MLP(nn.Module):
+    def __init__(self, d_in, d_h, d_out, p=0.1):
+        super().__init__()
+        self.net = nn.Sequential(nn.Linear(d_in, d_h), nn.ReLU(),
+                                 nn.Dropout(p), nn.Linear(d_h, d_out))
+    def forward(self, x):
+        return self.net(x)
+
+model = MLP(784, 256, 10).to(device)
+```
+
+**`torch.compile`** — wrap the model once and get a JIT-optimized (Dynamo→Inductor) graph, often a
+real speedup with no code change: `model = torch.compile(model)`. Modes: `"default"` (balanced),
+`"reduce-overhead"` (CUDA graphs, best for small batches), `"max-autotune"` (Triton autotuning,
+slowest to warm up). First step(s) are slow — that's compilation, not your model. Keep it *after*
+`.to(device)` and before the loop. (`pytorch.org/docs/stable/generated/torch.compile.html`)
+
+## 2. The training loop — and its classic bugs
+
+The whole game is five ordered steps. Get the order or the resets wrong and it fails *silently* —
+no exception, just a model that won't learn.
+
+```python
+model.train()                                    # Dropout/BN in TRAIN mode
+for epoch in range(epochs):
+    for x, y in train_loader:
+        x, y = x.to(device), y.to(device)
+        optimizer.zero_grad(set_to_none=True)    # clear LAST step's grads
+        out  = model(x)                          # forward
+        loss = loss_fn(out, y)                    # loss  (raw logits in, e.g. CrossEntropyLoss)
+        loss.backward()                          # autograd fills .grad (ACCUMULATES)
+        optimizer.step()                         # update weights from .grad
+        scheduler.step()                         # if a per-step scheduler
+```
+
+The load-bearing traps (all in the gotchas table, worth stating once here):
+
+- **Missing `optimizer.zero_grad()` → gradients silently add up across batches.** PyTorch
+  *accumulates* `.grad` by design (so you can split a batch); if you never zero it, every step
+  updates on the sum of all prior batches' grads and training destabilizes. Zero every step.
+  (`pytorch.org/tutorials` optimization tutorial; `torch.optim` docs.) `set_to_none=True` is the
+  default in modern Torch and is slightly faster.
+- **`CrossEntropyLoss` eats raw logits.** It applies `log_softmax` internally — do **not** put a
+  `Softmax`/`Sigmoid` before it or you double-activate and learning stalls. Same for
+  `BCEWithLogitsLoss`.
+- **Accumulating `loss` without `.item()` leaks memory.** `total += loss` keeps the whole autograd
+  graph alive across the epoch. Use `total += loss.item()` (or `.detach()`).
+- **`backward()` twice on one graph** raises unless you meant it (`retain_graph=True`) — usually a
+  sign you forgot to zero or re-ran forward.
+
+## 3. Mixed precision (AMP)
+
+Run forward/loss in low precision for speed and memory, keep a master copy for the update. Two
+pieces: `torch.autocast` (picks per-op precision) + `torch.amp.GradScaler` (rescues fp16 gradients
+from underflow). Verified against `pytorch.org/docs/stable/notes/amp_examples.html`.
+
+```python
+scaler = torch.amp.GradScaler("cuda")            # current namespace (not torch.cuda.amp)
+for x, y in train_loader:
+    x, y = x.to(device), y.to(device)
+    optimizer.zero_grad(set_to_none=True)
+    with torch.autocast(device_type="cuda", dtype=torch.bfloat16):
+        out  = model(x)                          # forward + loss ONLY under autocast
+        loss = loss_fn(out, y)
+    scaler.scale(loss).backward()                # backward OUTSIDE autocast, on scaled loss
+    scaler.step(optimizer)                        # unscales, skips step if inf/NaN grads
+    scaler.update()                               # adjusts the scale for next step
+```
+
+**bf16 vs fp16 — the choice that matters:**
+
+| dtype | Exponent range | Needs GradScaler? | Use when |
+|---|---|---|---|
+| **bf16** (`bfloat16`) | same as fp32 | **No** (range can't underflow) | Ampere+ (A100/H100/…) or CPU — **prefer this**, it's the robust default |
+| **fp16** (`float16`) | narrow → underflows | **Yes** — scaler is mandatory | older GPUs without bf16; squeeze extra range with the scaler |
+
+- With **bf16 you can skip `GradScaler`** entirely (`GradScaler(enabled=False)` or just don't use
+  it) — its whole job is fp16 underflow. With **fp16 the scaler is not optional.**
+- **Gradient clipping under AMP:** `scaler.unscale_(optimizer)` first, *then*
+  `torch.nn.utils.clip_grad_norm_(...)`, then `scaler.step`. Clipping scaled grads clips the wrong
+  magnitude.
+- Autocast wraps **forward + loss only**. Never wrap `backward()`.
+
+## 4. Optimizers and LR schedules
+
+- **`torch.optim.AdamW`** is the default for most modern nets (transformers, and increasingly
+  vision): Adam with *decoupled* weight decay (correct L2, unlike plain `Adam(weight_decay=)`).
+  **SGD + momentum + Nesterov** still wins on many CNNs and generalizes well — worth trying.
+- **Don't weight-decay everything.** Biases and Norm (LayerNorm/BatchNorm) weights should get
+  `weight_decay=0`; use two param groups. Decaying them hurts with no upside.
+- **The LR is the hyperparameter.** Too high → loss NaNs or oscillates; too low → crawls. A warmup
+  then cosine decay is the reliable modern recipe.
+
+```python
+opt = torch.optim.AdamW(model.parameters(), lr=3e-4, weight_decay=0.01, betas=(0.9, 0.999))
+
+# Warmup (linear ramp) THEN cosine decay, composed with SequentialLR — verified 2.x API.
+from torch.optim.lr_scheduler import LinearLR, CosineAnnealingLR, SequentialLR
+warmup = LinearLR(opt, start_factor=0.1, total_iters=500)          # 500 steps ramp-in
+cosine = CosineAnnealingLR(opt, T_max=total_steps - 500, eta_min=3e-5)
+scheduler = SequentialLR(opt, [warmup, cosine], milestones=[500])  # switch at step 500
+# call scheduler.step() every STEP here (T_max/total_iters are in steps).
+```
+
+Alternatively `OneCycleLR(opt, max_lr=..., total_steps=...)` bakes warmup+anneal into one
+scheduler. **Match `step()` cadence to the scheduler's units** — per-step schedulers stepped once
+per epoch (or vice-versa) silently give the wrong curve. (`pytorch.org/docs/stable/optim.html`)
+
+## 5. Distributed training — pick by what doesn't fit
+
+One line each on *when*; mechanics and launch commands in `references/distributed.md`.
+
+- **DDP** (`torch.nn.parallel.DistributedDataParallel`) — replicate the **whole model** on each GPU,
+  all-reduce grads every step. Use when **the model fits on one GPU** and you just want more
+  throughput / a larger effective batch. Default choice; one process per GPU via `torchrun`.
+- **FSDP2** (`torch.distributed.fsdp.fully_shard`) — **shard** parameters, gradients, and optimizer
+  states across GPUs (gather just-in-time). Use when **the model does NOT fit on one GPU.** FSDP2 is
+  the current DTensor-based, per-parameter API; apply it bottom-up (wrap layers, then the root).
+- **DeepSpeed ZeRO** (external Microsoft library, not in core Torch) — config-driven sharding:
+  **ZeRO-1** shards optimizer states, **ZeRO-2** adds gradients, **ZeRO-3** adds parameters
+  (≈ FSDP), plus CPU/NVMe **offload**. Use when you want offload or config-first scaling, or already
+  live in the DeepSpeed/Accelerate ecosystem. Verify the current version — it moves independently.
+
+Rule of thumb: fits on one GPU → **DDP**; too big → **FSDP2** (or ZeRO-3); need to offload to
+CPU/NVMe → **ZeRO**.
+
+## 6. Regularization, checkpointing, reproducibility
+
+**Regularization** (reach for these when val loss diverges from train — i.e. overfitting):
+weight decay (AdamW), `nn.Dropout`, data augmentation, early stopping on a val metric, label
+smoothing (`CrossEntropyLoss(label_smoothing=0.1)`), and gradient clipping for stability (not
+generalization).
+
+**Checkpointing — save `state_dict`s, not the model object.** Pickling the module ties the file to
+your code layout and breaks on refactor.
+
+```python
+torch.save({"epoch": epoch,
+            "model": model.state_dict(),          # DDP/FSDP: model.module.state_dict(), rank 0 only
+            "optimizer": opt.state_dict(),
+            "scheduler": scheduler.state_dict(),
+            "scaler": scaler.state_dict()},        # AMP scale must survive a resume
+           "ckpt.pt")
+# Resume: load model FIRST, then optimizer/scheduler; move optimizer state to device if needed.
+```
+
+Save optimizer + scheduler + scaler too, or a resumed run restarts its LR schedule and loss scale.
+
+**Reproducibility — seed everything, and know the ceiling.** From
+`pytorch.org/docs/stable/notes/randomness.html`, quoted: *"Completely reproducible results are not
+guaranteed across PyTorch releases, individual commits, or different platforms. Furthermore,
+results may not be reproducible between CPU and GPU executions, even when using identical seeds."*
+So bit-exact reproducibility is a debugging/regression tool, not a guarantee.
+
+```python
+import random, numpy as np, torch
+seed = 42
+random.seed(seed); np.random.seed(seed); torch.manual_seed(seed)   # covers CPU + all CUDA devices
+torch.use_deterministic_algorithms(True)          # errors on ops with no deterministic impl
+torch.backends.cudnn.deterministic = True
+torch.backends.cudnn.benchmark = False            # benchmark=True picks fastest algo → nondeterministic
+# For CUDA >= 10.2, deterministic matmul also needs, set BEFORE launch:
+#   export CUBLAS_WORKSPACE_CONFIG=:4096:8
+```
+
+DataLoader workers need their own seeding (each worker forks its RNG), via `worker_init_fn` +
+a seeded `generator` — full snippet in `references/training-recipes.md`. Determinism costs speed
+(`benchmark=False` disables autotuned convs).
+
+## Guardrails (the silent killers)
+
+- **`optimizer.zero_grad()` every step.** Skipping it makes `.grad` accumulate across batches — no
+  error, just diverging training. (`torch.optim` / optimization tutorial, pytorch.org)
+- **`model.eval()` + `torch.no_grad()` at inference/validation.** Forgetting `eval()` leaves Dropout
+  dropping and BatchNorm using *batch* stats instead of running stats, so val numbers are wrong;
+  forgetting `no_grad()` builds the autograd graph and can OOM. Flip back to `model.train()` after.
+  (`nn.Module.eval` / autograd docs, pytorch.org)
+- **Determinism is not guaranteed across releases/platforms/CPU-vs-GPU** even with identical seeds —
+  seed for debugging, don't promise bit-exactness. (randomness note, pytorch.org)
+- **fp16 without `GradScaler`** underflows to zero grads → no learning. bf16 doesn't need it.
+- **`CrossEntropyLoss`/`BCEWithLogitsLoss` take raw logits** — no Softmax/Sigmoid before them.
+- **Everything on the same device** — a stray CPU tensor in a CUDA graph is a hard error you'll hit
+  fast; `.to(device)` inputs, targets, and model.
+- **NaN loss?** LR too high, no AMP scaler on fp16, unclipped exploding grads, or a `log(0)`/`0/0`
+  in a custom loss. Bisect: drop LR 10×, clip grads, switch fp16→bf16.
+
+## Related skills
+
+- [`finetuning`](../finetuning/SKILL.md) — adapting a **pretrained LLM** (LoRA/QLoRA, SFT via
+  trl/peft). If the base is a foundation model you're specializing, that's the skill; this one is
+  general/from-scratch net training.
+- [`machine-learning`](../machine-learning/SKILL.md) — classic/**tabular** (sklearn, GBDT). No
+  autograd, no GPU loop.
+- [`nlp`](../nlp/SKILL.md) — tokenization, NLP **task** modeling and metrics. Route text task
+  specifics there; route the raw training loop back here.
+- [`python`](../python/SKILL.md) — env/packaging, testing, general Python hygiene under the model
+  code.
+
+## Checklist
+
+- [ ] Right skill: from-scratch/vision/custom net in PyTorch (not finetuning / ML / nlp).
+- [ ] Loop has all five steps in order; `zero_grad(set_to_none=True)` every step.
+- [ ] Loss takes raw logits (no double activation); running loss uses `.item()`.
+- [ ] `model.train()` for training; `model.eval()` **and** `torch.no_grad()` for val/inference.
+- [ ] AMP: `torch.autocast` on forward+loss only; fp16 → `GradScaler`, bf16 → skip it; clip after
+      `unscale_`.
+- [ ] AdamW (decoupled decay) with no weight decay on bias/Norm params; LR warmup→cosine, `step()`
+      cadence matches scheduler units.
+- [ ] Multi-GPU chosen by fit: DDP (fits) vs FSDP2 (doesn't) vs ZeRO (offload/config).
+- [ ] Checkpoint saves model+optimizer+scheduler+scaler `state_dict`s; resume loads model first.
+- [ ] Seeds set; determinism flags on if needed, with the "not guaranteed across releases/devices"
+      caveat acknowledged.
+- [ ] Version claims hedged to "PyTorch 2.x (~2.13, verify)"; no hard minor pin presented as current.

package/skills/deep-learning/evals/README.md

@@ -0,0 +1,11 @@
+# Evals — deep-learning
+
+Routing and capability checks for a human or LLM grader, not an automated test suite. To run them:
+read each `should_trigger` prompt and confirm an agent would reach for `deep-learning` (PyTorch
+training/loop/AMP/distributed/reproducibility); read each `should_not_trigger` prompt and confirm it
+routes to the named sibling (`finetuning`, `machine-learning`, `nlp`, `vllm`, `python`) for the
+stated reason. Then grade the `capability` scenario against every `must_include` bullet — the
+correct five-step loop with per-step `zero_grad`, AMP with the bf16/fp16 + scaler rule, `model.eval()`
++ `no_grad()` at validation, AdamW + warmup→cosine, checkpoint hygiene, and the "determinism is not
+guaranteed across releases/platforms/devices" caveat. A pass covers all routing cases plus full
+rubric coverage on the capability scenario.