| name | using-ai-engineering |
| description | Use when you have an AI/ML task but aren't sure which Yzmir pack handles it - routes frameworks, training, RL, LLMs, architectures, and production to the correct specialist pack and clarifies before guessing |
Using AI Engineering
Overview
This meta-skill routes you to the right AI/ML engineering pack based on your task. Load this skill when you need ML/AI expertise but aren't sure which specific pack to use.
Core Principle: Problem type determines routing - clarify before guessing.
When to Use
Load this skill when:
- Starting any AI/ML engineering task
- User mentions: "neural network", "train a model", "RL agent", "fine-tune LLM", "deploy model"
- You recognize ML/AI work but unsure which pack applies
- Need to combine multiple domains (e.g., train RL + deploy)
How to Access Reference Sheets
IMPORTANT: All reference sheets are located in the SAME DIRECTORY as this SKILL.md file.
When this skill is loaded from:
skills/using-ai-engineering/SKILL.md
Reference sheets are at:
skills/using-ai-engineering/routing-examples.md
NOT at:
skills/routing-examples.md ← WRONG PATH
STOP - Mandatory Clarification Triggers
Before routing, if query contains ANY of these ambiguous patterns, ASK ONE clarifying question:
| Ambiguous Term | What to Ask | Why |
|---|
| "Model not working" | "What's not working - architecture, training, or deployment?" | Could be 3+ packs |
| "Improve performance" | "Performance in what sense - training speed, inference speed, or accuracy?" | Different domains |
| "Learning chatbot/agent" | "Fine-tuning language generation or optimizing dialogue policy?" | LLM vs RL vs both |
| "Train/deploy model" | "Both training AND deployment, or just one?" | May need multiple packs |
| Framework not mentioned | "What framework are you using?" | PyTorch-specific vs generic |
If you catch yourself about to guess the domain, STOP and clarify.
Routing by Problem Type
| Keywords/Signals | Route To | Why |
|---|
PyTorch, CUDA, memory, distributed, tensor, torch.compile, FSDP, GPU | pytorch-engineering | Foundation issues |
| NaN loss, converge, unstable, hyperparameters, gradients, LR, FP8, mixed precision | training-optimization | Training problems |
| Agent, policy, reward, environment, MDP, game, exploration, MARL | deep-rl | RL domain |
| LLM, fine-tune, RLHF, LoRA, prompt, instruction tuning, Claude / o-series / Llama / Mistral / Gemini, RAG, retrieval, embedding, reranker, prompt caching | llm-specialist | Language model applications |
| Reasoning models, "thinking tokens", extended thinking, o-series, R1, test-time compute, reasoning eval | llm-specialist | Inference-time reasoning is an LLM-application concern |
| Agent loop, tool use, MCP server/client, multi-agent orchestration, autonomous agent | llm-specialist | Agentic patterns are LLM-application concerns |
| Multimodal, VLM, vision-language, image+text, audio understanding | llm-specialist (application) and/or neural-architectures (modality fusion) | Routing depends on whether the question is "use a VLM" vs "design a fusion architecture" |
| Diffusion, flow matching, DiT, Stable Diffusion, image / video / audio generation | neural-architectures | Generative-media architecture |
| Which architecture, CNN vs transformer, Mamba vs attention, model selection | neural-architectures | Architecture choice |
| Deploy, serve, production, quantize, inference, latency, mobile, vLLM, SGLang, TensorRT-LLM, observability, drift | ml-production | Deployment |
| Network grows / prunes during training, continual learning, catastrophic forgetting, modular composition, MoE routing, adapter merging, PEFT (LoRA / QLoRA / DoRA / VeRA / PiSSA / LoftQ / LoRA+ / rsLoRA / LongLoRA) | dynamic-architectures | Networks that change topology / adapter composition over time |
| RL controller that decides WHEN / HOW to mutate a network's topology during training, growth actions, governor / safety gates, rollback-as-RL-signal, deterministic morphogenesis, ablation under topology change | morphogenetic-rl | The controller designing growth actions, not the network being grown (companion to dynamic-architectures) |
| ODE, integrator, physics sim, determinism, stability, replay, time-step, numerical methods | simulation-foundations | Simulation mathematics (often underpins RL environments) |
| Causal loop, feedback dynamics, leverage points, system archetypes, stock-flow, behavior-over-time | systems-thinking | Whole-system reasoning |
Cross-Cutting Scenarios
When task spans domains, route to ALL relevant packs in execution order:
| Query | Route To | Order |
|---|
| "Train RL agent and deploy" | deep-rl + ml-production | Train before deploy |
| "Fine-tune LLM with distributed training" | llm-specialist + pytorch-engineering | Domain first, then infrastructure |
| "LLM memory error during fine-tuning" | pytorch-engineering + llm-specialist | Foundation first |
| "RL training unstable" | training-optimization + deep-rl | General training first |
| "RL env determinism / replay broken" | simulation-foundations + deep-rl | Sim correctness before agent |
| "Continual-learning model forgets old tasks" | dynamic-architectures + training-optimization | Lifecycle design first, then training schedule |
| "RL controller decides when to grow my net, but the grown net trains badly" | morphogenetic-rl + dynamic-architectures (+ training-optimization) | Controller design first; HOW the grown net trains second; convergence tuning third |
| "Reasoning model is slow / expensive" | llm-specialist + ml-production | Application strategy first, serving second |
| "Build an agent that uses tools and a vector store" | llm-specialist (agentic + RAG) | Often single-pack; bring in axiom-engineering-foundations for system design if scope grows |
| "Diffusion model training diverges" | training-optimization + neural-architectures | General training first, architecture second |
| "Production LLM hallucinations / drift" | ml-production (observability) + llm-specialist (eval, RAG, prompting) | Detect before redesign |
Principle: Load in order of dependency. Fix foundation before domain. Complete training before deployment.
Common Routing Mistakes
| Symptom | Wrong Route | Correct Route | Why |
|---|
| "Train agent faster" | deep-rl | training-optimization FIRST | Could be general training issue |
| "LLM memory error" | llm-specialist | pytorch-engineering FIRST | Foundation issue |
| "Deploy RL model" | deep-rl | ml-production | Deployment problem |
| "Transformer for chess" | neural-architectures | deep-rl FIRST | RL problem |
| "Chatbot learning" | llm-specialist | ASK FIRST | Could be LLM OR RL |
| "My model forgets old data" | training-optimization | dynamic-architectures FIRST | Continual-learning lifecycle problem |
| "Replay diverges between machines" | deep-rl | simulation-foundations FIRST | Determinism / numerics problem |
| "o3 / extended thinking gives bad answers" | (guess) | llm-specialist (reasoning models sheet) | Reasoning-model prompting and eval differs from chat |
| "Build an MCP server / tool-using agent" | (none) | llm-specialist (agentic patterns) | Agent design lives with LLM applications |
| "RL agent that decides when to grow a network" | deep-rl | morphogenetic-rl FIRST | This is the controller-design pack; deep-rl alone misses governor/safety-gate/rollback patterns |
| "DoRA vs QLoRA for my 70B fine-tune" | llm-specialist | dynamic-architectures (PEFT comparison) + llm-specialist (fine-tune workflow) | Adapter method choice is the lifecycle pack's domain |
Pressure Resistance - Critical Discipline
Time/Emergency Pressure
| Rationalization | Reality Check | Correct Action |
|---|
| "Emergency means skip diagnostics" | Wrong diagnosis wastes MORE time | Fast systematic diagnosis IS emergency protocol |
| "Quick question means quick answer" | Wrong answer slower than 30-sec clarification | Ask ONE clarifying question |
| "Production down, no time for routing" | Wrong pack = longer outage | Correct routing (60 sec) prevents 20-min detour |
Emergency Protocol:
- Acknowledge urgency
- Fast clarification (30 sec)
- Route to correct pack
- Let pack provide emergency-appropriate approach
Authority/Hierarchy Pressure
| Rationalization | Reality Check | Correct Action |
|---|
| "PM/architect said use X" | Authority can be wrong about routing | Verify task type regardless |
| "Questioning authority is risky" | Professional duty = correct routing | Frame as verification |
| "They have more context" | Context ≠ correct technical routing | Route based on problem type |
Authority Protocol: "I see [authority] suggested X - to apply it correctly, let me verify problem type"
Sunk Cost Pressure
| Rationalization | Reality Check | Correct Action |
|---|
| "Already spent N hours in X, continue" | Sunk cost fallacy - wrong direction stays wrong | Cut losses immediately |
| "Redirecting invalidates their effort" | Correct routing validates effort by enabling success | Redirect now |
| "Too invested to change direction" | More investment in wrong direction = more waste | "Stop digging when in hole" |
Sunk Cost Protocol: "I see N hours invested - redirecting now prevents more wasted hours"
Keyword/Anchoring Pressure
| Rationalization | Reality Check | Correct Action |
|---|
| "They mentioned transformer" | Keywords mislead; problem type matters | "Transformer for what problem type?" |
| "LLM mentioned, must be llm-specialist" | LLM could have foundation issues | Check problem type first |
| "They asked to 'fix RL'" | User's framing can be wrong | Verify RL is correct approach |
| "They said 'agent', must be deep-rl" | Modern "agent" usually means tool-using LLM, not RL | Distinguish RL agent (policy + reward) from LLM agent (tool loop + planning) |
| "They mentioned diffusion / DiT" | Could be training instability, serving cost, or architecture | Verify problem type before routing to neural-architectures |
| "They mentioned MoE" | Could be training (load balancing), architecture, or serving | Cross-cutting; clarify which slice of MoE they mean |
Red Flags Checklist - STOP Immediately
Basic Routing Red Flags
- ❌ "I'll guess this domain" → ASK clarifying question
- ❌ "They probably mean X" → Verify, don't assume
- ❌ "Just give generic advice" → Route to specific pack
Time/Emergency Red Flags
- ❌ "Emergency means skip clarification" → Fast clarification IS emergency protocol
- ❌ "Production issue means guess quickly" → Wrong guess = longer outage
- ❌ "I'll skip asking to save time" → Clarifying (30 sec) faster than wrong route (5+ min)
Authority/Social Red Flags
- ❌ "Authority figure suggested X, so route to X" → Verify task requirements
- ❌ "PM/senior has more context, trust them" → Route based on problem type
- ❌ "They're frustrated/exhausted, avoid redirect" → Continuing wrong path makes it worse
Sunk Cost Red Flags
- ❌ "They invested N hours in X, continue there" → Sunk cost fallacy, cut losses
- ❌ "Redirecting invalidates their effort" → Correct routing enables success
- ❌ "Too much sunk cost to change direction" → More investment = more waste
Keyword/Anchoring Red Flags
- ❌ "They mentioned transformer/CNN, discuss architecture" → Check problem type first
- ❌ "LLM/RL mentioned, route to that domain" → Could be foundation issue
- ❌ "Technical jargon means they know domain" → Vocabulary ≠ correct self-diagnosis
All of these mean: Either ASK ONE clarifying question, or reconsider your routing logic.
Comprehensive Rationalization Prevention Table
| Pressure Type | Rationalization | Counter-Narrative | Correct Action |
|---|
| Time | "Emergency means skip diagnostics" | Wrong diagnosis wastes MORE time | "Fast clarification ensures fastest fix" |
| Time | "Quick question means quick answer" | Wrong answer slower than clarification | "Quick clarification prevents wrong path" |
| Time | "Production down, no time for routing" | Wrong pack = longer outage | "60-second routing prevents 20-minute detour" |
| Authority | "PM/architect said use X pack" | Authority can be wrong | "To apply X correctly, let me verify" |
| Authority | "Senior colleague suggested X" | Seniority ≠ correct routing | "To use suggestion effectively: [verify]" |
| Sunk Cost | "Already spent 6 hours in pack X" | Sunk cost fallacy | "Redirecting now prevents more wasted hours" |
| Sunk Cost | "Redirecting invalidates effort" | Correct routing enables success | "Redirect so effort succeeds" |
| Keywords | "User mentioned transformers" | Keywords mislead | "Clarifying problem type first" |
| Keywords | "They said LLM, route to llm-specialist" | LLM could have foundation issues | "Memory error is foundation issue" |
| Anchoring | "They asked to 'fix RL'" | User's framing can be wrong | "Before fixing, verify RL is correct" |
| Complexity | "Too many domains, just pick one" | Cross-cutting needs multi-pack | Route to ALL relevant packs |
| Social | "They're frustrated, don't redirect" | Continuing wrong path increases frustration | "Redirecting prevents more frustration" |
| Demanding | "They said 'just tell me', skip questions" | Tone doesn't change routing needs | "To help effectively, I need: [question]" |
When NOT to Use Yzmir Skills
Skip AI/ML skills when:
- Simple data processing without ML.
- Statistical analysis without neural networks.
- Data cleaning / ETL without model training.
- The task is pure system architecture (route to
axiom-solution-architect), pure DevOps (route to axiom-devops-engineering), or pure security threat modeling for the surrounding system (route to ordis-security-architect).
Edge cases worth naming:
- "Build a chatbot" with no ML training and no fine-tuning — usually a Yzmir question (
llm-specialist: prompting, RAG, agent loop) but bring in axiom-solution-architect if the request is really about system design.
- "Why does my agent's tool call fail?" — usually
llm-specialist (agentic patterns), but if it's a tool-runtime / sandbox / IPC issue it's axiom-engineering-foundations.
- "Make my LLM responses cheaper" —
llm-specialist (prompt caching, model routing, smaller models) and/or ml-production (serving stack). Both are valid.
Red flag: If you're not training, deploying, prompting, retrieving for, or evaluating a model, you probably don't need Yzmir.
Routing Summary Flowchart
User Query
↓
Is query ambiguous? → YES → ASK clarifying question
↓ NO
Identify problem type:
- Framework error / PyTorch API? → pytorch-engineering
- Training not working / optimizer / precision? → training-optimization
- RL problem? → deep-rl
- LLM application (prompt, RAG, fine-tune, reasoning, agent, MCP)? → llm-specialist
- Architecture choice (CNN/transformer/Mamba/diffusion)? → neural-architectures
- Production deployment / serving / observability? → ml-production
- Network grows/prunes / continual learning / PEFT (LoRA/QLoRA/DoRA/...) / MoE composition? → dynamic-architectures
- RL controller deciding WHEN/HOW to grow a network (governor, safety gates, rollback)? → morphogenetic-rl
- Simulation math / determinism / ODEs? → simulation-foundations
- Whole-system feedback / causal loops / leverage? → systems-thinking
↓
Cross-cutting? → YES → Route to MULTIPLE packs (order by dependency)
↓ NO
Route to single pack
Examples
See routing-examples.md for detailed worked examples:
- Ambiguous queries
- Cross-cutting scenarios
- Misleading keywords
- Time pressure handling
- Foundation issues disguised as domain issues
- Emergency + authority pressure
- Sunk cost + frustration
- Multiple pressures combined
AI Engineering Plugin Router Catalog
This meta-router directs you to the appropriate Yzmir AI/ML plugin. The Yzmir faction ships 10 specialist packs plus this router:
- yzmir-pytorch-engineering — PyTorch framework: CUDA, memory, FSDP/
torch.compile, distributed, tensor operations.
- yzmir-training-optimization — Training problems: optimizers, schedules, precision (BF16/FP8), gradients, convergence, hyperparameters.
- yzmir-deep-rl — Reinforcement learning: agents, policies, rewards, environments, MDP, offline RL, MARL.
- yzmir-llm-specialist — LLM applications: prompting, RAG, fine-tuning (SFT/DPO/GRPO), reasoning models, agentic patterns / MCP, multimodal use, prompt caching, evaluation, safety.
- yzmir-neural-architectures — Architecture selection: CNN / transformer / Mamba / GNN / diffusion / DiT / multimodal fusion, capacity and depth-width tradeoffs.
- yzmir-ml-production — Production: vLLM / SGLang / TensorRT-LLM serving, quantization (
torch.ao.quantization, AWQ, GPTQ, FP8), MLOps, observability (Phoenix / Langfuse / OTel GenAI), drift, scaling.
- yzmir-dynamic-architectures — Networks that grow / prune / adapt: continual learning, gradient isolation, modular composition, MoE routing, adapter merging, PEFT (LoRA / QLoRA / DoRA / VeRA / PiSSA / LoftQ / LoRA+ / rsLoRA / LongLoRA), lifecycle. Owns the HOW: how the growable / adaptable network trains.
- yzmir-morphogenetic-rl — RL controllers that decide WHEN and HOW to mutate a network's topology during training: action/observation/reward design for the controller, governor and safety gates, rollback-as-RL-signal, deterministic morphogenesis, growth-aware ablation. Companion to dynamic-architectures: owns the CONTROLLER that drives growth, not the network being grown.
- yzmir-simulation-foundations — Simulation mathematics: ODEs, integrators, stability, control theory, determinism — often the foundation under RL environments and physics-based systems.
- yzmir-systems-thinking — Systems thinking methodology: causal loops, leverage points, archetypes, stocks-flows, behavior-over-time graphs.
Adjacent (non-Yzmir) routers worth knowing about:
axiom-engineering-foundations — general software-engineering rigor for AI systems (debugging, refactoring, code review).axiom-solution-architect — when AI is one component of a larger system that needs an architecture document.ordis-security-architect — LLM threat modeling, prompt injection, exfil, AI supply chain.axiom-python-engineering — Python tooling foundations underneath PyTorch / Transformers code.
Remember: When in doubt, ASK. Clarification takes seconds, wrong routing takes minutes. Knowledge cutoff awareness: model IDs and provider features evolve quickly — capability-tier framing in downstream packs (frontier reasoning / frontier general / fast-cheap / on-device) is intentional. Check provider docs for current model IDs before quoting them in user-facing answers.
