tachyon-beep/using-ai-engineering

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:

1. Acknowledge urgency
2. Fast clarification (30 sec)
3. Route to correct pack
4. 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:

1. yzmir-pytorch-engineering — PyTorch framework: CUDA, memory, FSDP/torch.compile, distributed, tensor operations.
2. yzmir-training-optimization — Training problems: optimizers, schedules, precision (BF16/FP8), gradients, convergence, hyperparameters.
3. yzmir-deep-rl — Reinforcement learning: agents, policies, rewards, environments, MDP, offline RL, MARL.
4. yzmir-llm-specialist — LLM applications: prompting, RAG, fine-tuning (SFT/DPO/GRPO), reasoning models, agentic patterns / MCP, multimodal use, prompt caching, evaluation, safety.
5. yzmir-neural-architectures — Architecture selection: CNN / transformer / Mamba / GNN / diffusion / DiT / multimodal fusion, capacity and depth-width tradeoffs.
6. yzmir-ml-production — Production: vLLM / SGLang / TensorRT-LLM serving, quantization (torch.ao.quantization, AWQ, GPTQ, FP8), MLOps, observability (Phoenix / Langfuse / OTel GenAI), drift, scaling.
7. 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.
8. 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.
9. yzmir-simulation-foundations — Simulation mathematics: ODEs, integrators, stability, control theory, determinism — often the foundation under RL environments and physics-based systems.
10. 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.