zhongwei/gh-tachyon-beep-skillpacks-plugins-yzmir-ai-engineering-expert
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:59:49 +08:00
commit 0b5a14af96
4 changed files with 700 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "yzmir-ai-engineering-expert",
"description": "Primary router for all AI/ML engineering skillpacks - directs to specialized packs",
"version": "1.0.1",
"author": {
"name": "tachyon-beep",
"url": "https://github.com/tachyon-beep"
},
"skills": [
"./skills"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# yzmir-ai-engineering-expert
Primary router for all AI/ML engineering skillpacks - directs to specialized packs

45
plugin.lock.json Normal file
View File

@@ -0,0 +1,45 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:tachyon-beep/skillpacks:plugins/yzmir-ai-engineering-expert",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "dbea53d1a22fa4b4e5272e094c6875c750bc5ba3",
"treeHash": "65830635168c8f0481fb34f4fd5bafc5744e9df4829a09bb29722405a3cd4bc5",
"generatedAt": "2025-11-28T10:28:33.399082Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "yzmir-ai-engineering-expert",
"description": "Primary router for all AI/ML engineering skillpacks - directs to specialized packs",
"version": "1.0.1"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "c86a0db7f907bd4cbc3e5b8fd57af594f4111e40ea7446beef5cae644c0d7d01"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "0cf647b907cfa6484a2e45a8d1ae7149cb131db55c631c2d60f87d2f06e8c90a"
},
{
"path": "skills/using-ai-engineering/SKILL.md",
"sha256": "95c492dbedddea2713f7833ad4bc360121acd1c00bfbcf0f774b4a0a23397637"
}
],
"dirSha256": "65830635168c8f0481fb34f4fd5bafc5744e9df4829a09bb29722405a3cd4bc5"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

640
skills/using-ai-engineering/SKILL.md Normal file
View File

@@ -0,0 +1,640 @@
---
name: using-ai-engineering
description: Route AI/ML tasks to correct Yzmir pack - frameworks, training, RL, LLMs, architectures, production
mode: true
---
# 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**: Different ML tasks require different packs. Match your situation to the appropriate pack, load only what you need. 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)
**Don't use for**: Non-ML tasks, simple data processing without ML, basic statistical analysis
---
## 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 choice, training process, or deployment?" | Could be 3+ different packs |
| "Improve performance" | "Performance in what sense - training speed, inference speed, or accuracy?" | Different optimization domains |
| "Learning chatbot/agent" | "What type of learning - fine-tuning language generation or optimizing dialogue policy?" | LLM vs RL vs both |
| "Fix my code" | "What domain and what's breaking?" | Too vague to route |
| "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
### Step 1: Identify Problem Type (BEFORE routing)
| Keywords/Signals | Problem Type | Why This Matters |
|------------------|--------------|------------------|
| "Play game", "policy", "reward", "environment", "MDP", "agent actions" | **Reinforcement Learning** | RL is distinct algorithm class |
| "Fine-tune", "LLM", "transformer", "prompt", "RLHF", "GPT", "language model" | **Large Language Model** | Specialized modern techniques |
| "Deploy", "serve", "production", "inference", "quantize", "optimize latency" | **Production/Deployment** | Different constraints than training |
| "NaN loss", "won't converge", "unstable", "hyperparameters", "optimization" | **Training Issues** | Universal training problems |
| "PyTorch error", "CUDA", "distributed training", "memory", "GPU" | **Framework Foundation** | Infrastructure before algorithms |
| "Which architecture", "CNN vs transformer", "model selection" | **Architecture Choice** | Before training decisions |
**Critical**: Architecture keywords ("transformer", "CNN") can be misleading. Problem type determines algorithm, algorithm constrains architecture.
---
## Routing Decision Tree
### Foundation Layer Issues
**Symptoms**: "PyTorch memory error", "distributed training", "GPU utilization", "tensor operations", "CUDA out of memory", "DataLoader", "torch.*"
**Route to**: Load the `yzmir-pytorch-engineering` plugin's router skill
**Why**: Foundation issues need foundational solutions. Don't jump to algorithms when infrastructure broken.
**Red Flag**: If you're thinking "This is probably LLM/RL issue, skip PyTorch" but query mentions PyTorch errors → Route to PyTorch first.
---
### Training Not Working
**Symptoms**: "NaN losses", "won't converge", "training unstable", "need to tune hyperparameters", "loss not decreasing", "gradients", "learning rate"
**Route to**: Load the `yzmir-training-optimization` plugin's router skill
**Why**: Training problems are universal across all model types. Debug training before assuming algorithm issue.
**Example**: "RL training unstable" → training-optimization FIRST (could be general training issue), then deep-rl if needed.
---
### Reinforcement Learning
**Symptoms**: "RL agent", "policy", "reward", "environment", "Atari", "robotics control", "MDP", "Q-learning", "play game", "sequential decisions", "exploration"
**Route to**: Load the `yzmir-deep-rl` plugin's router skill
**Why**: RL is distinct domain with specialized techniques.
**Red Flag**: User mentions "transformer for chess" - Still RL problem! Transformer is architecture choice WITHIN RL framework. Route to deep-rl first, then neural-architectures for architecture discussion.
---
### Large Language Models
**Symptoms**: "LLM", "language model", "transformer for text", "fine-tune", "RLHF", "LoRA", "prompt engineering", "GPT", "BERT", "instruction tuning", "chatbot fine-tuning"
**Route to**: Load the `yzmir-llm-specialist` plugin's router skill
**Why**: Modern LLM techniques are specialized (LoRA, RLHF, quantization, etc.).
**Clarify First**: If query says "learning chatbot" without specifying fine-tuning vs policy learning, ASK. Could be LLM fine-tuning OR RL dialogue policy.
---
### Architecture Selection
**Symptoms**: "which architecture", "CNN vs transformer", "what model to use", "architecture for X task", "model selection", "attention vs convolution"
**Route to**: Load the `yzmir-neural-architectures` plugin's router skill
**Why**: Architecture decisions come before training decisions.
**Important**: Route here only AFTER problem type is clear. Don't discuss architecture for RL game-playing before routing to deep-rl for algorithm context.
---
### Production Deployment
**Symptoms**: "deploy model", "serving", "quantization", "production", "inference optimization", "MLOps", "latency", "throughput", "edge device", "mobile deployment"
**Route to**: Load the `yzmir-ml-production` plugin's router skill
**Why**: Production has unique constraints (latency, throughput, hardware).
**Common Cross-Cut**: If query mentions both training and deployment, route to BOTH in order (training first, then production).
---
## Cross-Cutting Scenarios
### Multiple Domains - Route to BOTH
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 |
| "Optimize transformer training" | training-optimization + neural-architectures | Training issues before architecture tweaks |
| "Deploy model to mobile, training not finished" | training-optimization + ml-production | Fix training first |
| "LLM memory error during fine-tuning" | pytorch-engineering + llm-specialist | Foundation first |
| "RL training unstable" | training-optimization + deep-rl | General training first |
**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, not RL-specific |
| "LLM memory error" | llm-specialist | pytorch-engineering FIRST | Foundation issue, not LLM technique issue |
| "Deploy RL model" | deep-rl | ml-production | Deployment problem, not RL training |
| "Which optimizer for transformer" | neural-architectures | training-optimization | Optimization, not architecture |
| "Transformer for chess" | neural-architectures | deep-rl FIRST | RL problem, architecture secondary |
| "Chatbot learning from users" | llm-specialist | ASK FIRST | Could be LLM OR RL OR both |
| "Model performance bad" | (guess) | ASK: "Training accuracy or inference speed?" | Ambiguous |
---
## Pressure Resistance - Critical Discipline
### Time/Emergency Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "Emergency means skip diagnostics" | Wrong diagnosis wastes MORE time in emergency | 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 |
| "User seems rushed, skip questions" | Clarifying takes 30 seconds, wrong route wastes 5+ minutes | Quick clarification prevents waste |
**Emergency Protocol**:
1. Acknowledge urgency: "I understand this is urgent/emergency"
2. Fast clarification (30 sec): "Quick clarification to ensure fastest resolution: [question]"
3. Route to correct pack
4. Let pack provide emergency-appropriate systematic approach
**Never skip clarification under time pressure. Wrong routing is slower than asking.**
---
### Authority/Hierarchy Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "PM/senior/architect said use X" | Authority can be wrong about routing | Verify task type, opinion doesn't override requirements |
| "Questioning authority is risky" | Professional duty = correct routing | Frame as verification: "To apply X correctly, I need to verify..." |
| "They have more context, trust them" | Context doesn't mean correct technical routing | Route based on problem type, not authority |
| "Challenging authority is confrontational" | Verification isn't confrontation | "Let's confirm problem type matches X pack" (neutral) |
**Authority Protocol**:
1. Acknowledge: "I see your [PM/architect/colleague] suggested X"
2. Frame verification neutrally: "To apply X effectively, let me verify the problem type"
3. If mismatch: "Based on [symptoms], this appears to be [Y problem] needing [Y pack]. X pack is typically for [X problems]. Shall we verify?"
4. Professional boundaries: Task requirements determine routing, not hierarchy
---
### Sunk Cost Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "Already spent N hours in X, continue" | Sunk cost fallacy - wrong direction doesn't become right | Cut losses immediately, redirect to correct pack |
| "Redirecting invalidates their effort" | Correct routing validates effort by enabling success | "Let's redirect so your next effort succeeds" |
| "Too invested to change direction" | More investment in wrong direction = more waste | "Stop digging when in hole" |
| "Maybe solution hidden deeper in wrong pack" | Wrong pack stays wrong no matter how deep | Route based on problem, not on investment |
**Sunk Cost Protocol**:
1. Validate effort: "I see you've invested [N hours] in X approach"
2. Reality check: "Based on [symptoms], this appears to be [Y problem], not [X problem]"
3. Cut losses: "Redirecting now prevents further time in wrong direction"
4. Positive frame: "Your diagnostic work will be valuable in correct domain"
---
### Social/Emotional Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "They're frustrated, don't redirect" | Continuing wrong path increases frustration | Honest redirect prevents more frustration |
| "Exhausted user wants easy answer" | Wrong answer means exhausting rework | "I know you're tired - quick clarification prevents rework" |
| "Colleague suggested X, don't contradict" | Professionalism > social comfort | Neutral verification: "Let's verify the approach" |
| "Admitting wrong pack is awkward" | Professional effectiveness > comfort | Frame as discovery: "I found the issue - wrong domain" |
**Social Pressure Protocol**: Professional responsibility to route correctly overrides social comfort. Use empathetic but firm language.
---
### Keyword/Anchoring Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "They mentioned transformer, route to architectures" | Keywords without context mislead | "Transformer for what problem type?" |
| "LLM mentioned, must be llm-specialist" | LLM could have foundation issues | "LLM memory error → pytorch-engineering first" |
| "Technical jargon means they know domain" | Vocabulary ≠ correct self-diagnosis | Verify problem type regardless of sophistication |
| "They asked to 'fix RL', don't question RL" | User's framing can be wrong | Verify RL is correct algorithm before fixing |
**Keyword Resistance**: Problem TYPE determines routing. Keywords and user framing can mislead. Always verify independently.
---
### Complexity/Demanding Tone Pressure
| Rationalization | Reality Check | Correct Action |
|-----------------|---------------|----------------|
| "Too many domains, just pick one" | Cross-cutting needs multi-pack | Route to ALL relevant packs in dependency order |
| "They said 'just tell me', skip questions" | Demanding tone doesn't change routing needs | Professional boundaries: clarify anyway |
| "Commanding tone means don't push back" | Effectiveness requires correct routing | Firm + respectful: "To help effectively, I need to know..." |
| "Multiple packs too complicated" | Problem complexity dictates solution complexity | Match solution complexity to problem |
**Complexity Protocol**: Don't simplify routing to avoid complexity. Complex problems need comprehensive multi-pack routing.
---
## Red Flags Checklist - STOP Immediately
If you catch yourself thinking ANY of these, STOP and clarify or reconsider:
### Basic Routing Red Flags
- ❌ "I'll guess this domain" → ASK clarifying question
- ❌ "They probably mean X" → Verify, don't assume
- ❌ "This is too vague to route" → ASK clarifying question
- ❌ "Just give generic advice" → Route to specific pack if applicable
### Time/Emergency Red Flags
- ❌ "Emergency means skip clarification protocol" → 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)
- ❌ "Quick question deserves quick guess" → Quick clarification beats wrong answer
### Authority/Social Red Flags
- ❌ "Authority figure suggested X, so route to X" → Verify task requirements regardless
- ❌ "PM/senior has more context, trust them" → Route based on problem type, not hierarchy
- ❌ "Questioning authority is confrontational" → Verification is professional, not confrontational
- ❌ "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 now
- ❌ "Redirecting invalidates their effort" → Correct routing enables their effort to succeed
- ❌ "Too much sunk cost to change direction" → More investment in wrong direction = more waste
- ❌ "They tried X so must be Y" → Maybe X was wrong approach, verify independently
### 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 or cross-cutting
- ❌ "Technical jargon means they know domain" → Vocabulary doesn't mean correct self-diagnosis
- ❌ "They asked to 'fix X implementation'" → Verify X is correct approach before fixing
### Complexity/Tone Red Flags
- ❌ "Too many domains mentioned, pick one" → Cross-cutting needs multi-pack routing
- ❌ "They said 'just tell me', skip questions" → Demanding tone doesn't change routing needs
- ❌ "Multiple packs too complicated" → Problem complexity dictates solution complexity
- ❌ "Commanding tone means don't push back" → Professional effectiveness requires correct routing
**All of these mean: Either ASK ONE clarifying question, or reconsider your routing logic.**
**Remember**: Pressure (time/authority/sunk cost/social/complexity) makes correct routing MORE important, not less.
---
## Common Rationalizations - Don't Do These
### Comprehensive Rationalization Prevention Table
| Pressure Type | Rationalization | Counter-Narrative | Correct Action |
|---------------|-----------------|-------------------|----------------|
| **Time/Emergency** | "Emergency means skip diagnostics" | Wrong diagnosis wastes MORE time in emergency | "I understand urgency - fast clarification ensures fastest fix: [question]" |
| **Time/Emergency** | "Quick question means quick answer" | Wrong answer slower than 30-sec clarification | "Quick clarification prevents wrong path: [question]" |
| **Time/Emergency** | "Production down, no time for routing" | Wrong pack = longer outage (20+ min vs 60 sec routing) | "60-second routing prevents 20-minute detour - what's the error?" |
| **Time/Emergency** | "User seems rushed, skip questions" | Clarifying faster than wrong route | "Quick clarification (30 sec) prevents wasted effort: [question]" |
| **Time/Emergency** | "Give quick fix for time pressure" | Diagnosis faster than guessing | "Fast systematic approach is faster than trial-and-error: [diagnostic]" |
| **Authority** | "PM/architect said use X pack" | Authority can be wrong about routing | "I see PM suggested X - to apply it correctly, let me verify problem type" |
| **Authority** | "Senior colleague suggested X" | Seniority ≠ correct routing | "To use [colleague's suggestion] effectively: [verify question]" |
| **Authority** | "Challenging authority is risky/confrontational" | Verification is professional duty | "Let's confirm problem type matches X approach" (neutral framing) |
| **Authority** | "They have more context, trust them" | Context doesn't guarantee correct technical routing | Route based on actual problem type, not authority opinion |
| **Sunk Cost** | "Already spent 6 hours in pack X" | Sunk cost fallacy - wrong direction stays wrong | "I see 6 hours invested - redirecting now prevents more wasted hours" |
| **Sunk Cost** | "Redirecting invalidates their effort" | Correct routing validates effort by enabling success | "Let's redirect so your diagnostic work succeeds in correct domain" |
| **Sunk Cost** | "Too invested to change packs" | More investment in wrong direction = more waste | "Stop digging when in hole - redirect to correct pack now" |
| **Sunk Cost** | "Maybe solution hidden deeper in wrong pack" | Wrong pack doesn't become right with more searching | "This is [X problem] not [Y problem] - pack won't help no matter how deep" |
| **Sunk Cost** | "Already tried pytorch-engineering" | Might have used wrong skill in pack | "Which pytorch skill did you try? Pack has 8 skills for different issues" |
| **Keywords** | "User mentioned transformers, must want architecture advice" | Keywords mislead; problem type matters | "I see transformers mentioned - clarifying problem type first: [question]" |
| **Keywords** | "They said LLM, route to llm-specialist" | LLM could have foundation issues | "LLM memory error is foundation issue - pytorch-engineering first" |
| **Keywords** | "Technical jargon means they know domain" | Vocabulary ≠ correct self-diagnosis | Verify problem type regardless of how sophisticated they sound |
| **Keywords** | "They said chatbot so must be LLM" | Multiple interpretations exist | "Are you fine-tuning language generation or optimizing dialogue policy?" |
| **Anchoring** | "They asked to 'fix RL implementation'" | User's framing can be wrong | "Before fixing RL implementation, let's verify RL is correct approach" |
| **Anchoring** | "They started in pack X, continue there" | Initial pack choice can be wrong | "Based on symptoms, this is [Y problem] not [X problem] - redirect needed" |
| **Complexity** | "Too many domains, just pick one" | Cross-cutting problems need multi-pack | Route to ALL relevant packs in dependency order |
| **Complexity** | "Multiple packs too complicated" | Problem complexity dictates solution | "This spans [X, Y] domains - routing to both in order" |
| **Complexity** | "This is probably just deployment" | Cross-cutting issues common in ML | "Let's check if training approach affects deployment options" |
| **Complexity** | "Generic advice is safer" | Domain-specific tools faster/better | "PyTorch has specific tools for this - routing to pytorch-engineering" |
| **Social** | "They're frustrated, don't redirect" | Continuing wrong path increases frustration | "I see frustration - redirecting to correct domain prevents more" |
| **Social** | "Exhausted user wants easy answer" | Wrong answer means exhausting rework | "I know you're tired - quick clarification prevents rework: [question]" |
| **Social** | "Colleague suggested X, don't contradict" | Professionalism > social comfort | Neutral verification: "Let's verify the approach matches problem type" |
| **Demanding Tone** | "They said 'just tell me', skip questions" | Demanding tone doesn't change routing needs | Professional boundaries: "To help effectively, I need: [question]" |
| **Demanding Tone** | "Commanding tone means don't push back" | Effectiveness requires correct routing | Firm + respectful: "To ensure fastest solution: [question]" |
---
## When NOT to Use Yzmir Skills
**Skip AI/ML skills when:**
- Simple data processing (use Python/Pandas directly)
- Statistical analysis without neural networks (use classical stats)
- Building non-ML features (use appropriate language/framework skills)
- Data cleaning/ETL without model training (use data engineering tools)
**Red flag**: If you're not training/deploying a neural network or implementing ML algorithms, probably don't need Yzmir.
---
## Integration Points (Future)
**Cross-references (Phase 2+)**:
- Security/adversarial testing → ordis/security-architect
- Model documentation → muna/technical-writer
- Compliance/governance → ordis/compliance-awareness-and-mapping
**Phase 1**: These integrations not yet implemented. Focus on Yzmir standalone.
---
## Routing Summary Flowchart
```
User Query
↓
Is query ambiguous? → YES → ASK clarifying question → Get answer
↓ NO
Identify problem type:
- Framework error? → pytorch-engineering
- Training not working? → training-optimization
- RL problem? → deep-rl
- LLM fine-tuning? → llm-specialist
- Architecture choice? → neural-architectures
- Production deployment? → ml-production
↓
Cross-cutting? → YES → Route to MULTIPLE packs (order by dependency)
↓ NO
Route to single pack
↓
Load appropriate using-[pack] meta-skill
```
---
## Quick Reference: Problem Type → Pack
| Problem Type | Pack | Trigger Keywords |
|--------------|------|------------------|
| Framework issues | pytorch-engineering | PyTorch, CUDA, memory, distributed, tensor |
| Training problems | training-optimization | NaN, converge, unstable, loss, gradients, LR |
| Reinforcement learning | deep-rl | Agent, policy, reward, environment, game, MDP |
| Language models | llm-specialist | LLM, fine-tune, RLHF, LoRA, GPT, prompt |
| Architecture selection | neural-architectures | Which architecture, CNN vs transformer, model selection |
| Production/deployment | ml-production | Deploy, serve, production, quantize, inference, latency |
**Remember**: When in doubt, ASK. Clarification takes seconds, wrong routing takes minutes.
---
## Examples
### Example 1: Ambiguous Query
**User**: "I need to improve my model's performance"
**DON'T**: Guess (training? inference? accuracy?)
**DO**:
```
"To route you correctly, I need to clarify: Do you mean:
- Improve training speed?
- Improve inference/deployment speed?
- Improve model accuracy?
Each requires a different pack."
```
Then route based on answer.
---
### Example 2: Cross-Cutting
**User**: "I've trained an image classifier and need to deploy to mobile devices with limited resources"
**Recognize**: Training + Deployment (cross-cutting)
**Route to**:
1. First: `ml-production` (deployment constraints)
2. Then: `training-optimization` (if training modifications can help)
3. Possibly: `neural-architectures` (if architecture unsuitable for mobile)
**Explain**: "This spans training and deployment. Let's look at deployment constraints first, then see if training approach needs adjustment."
---
### Example 3: Misleading Keywords
**User**: "I'm training a model to play chess. Should I use transformers or CNNs?"
**DON'T**: Jump to neural-architectures (keyword: "transformer", "CNN")
**DO**: Recognize problem type first
```
"This is a reinforcement learning problem (game playing = sequential decision-making).
Let me route to deep-rl first to discuss algorithm choice (MCTS, value-based, policy gradient),
then we'll discuss architecture (transformer vs CNN) in that RL context."
```
**Route**: deep-rl → neural-architectures (in that order)
---
### Example 4: Time Pressure
**User**: "Quick! My training is showing NaN losses. Need to fix in 10 minutes!"
**DON'T**: Give quick hacks
**DO**: Fast systematic approach
```
"Understood - time pressure. Quick systematic diagnosis is faster than guessing.
Routing to training-optimization for 2-minute diagnostic workflow, then targeted fix.
This will be faster and more reliable than trial-and-error."
```
**Route**: training-optimization (which will provide fast systematic debugging)
---
### Example 5: Foundation Issue Disguised as Domain Issue
**User**: "My LLM fine-tuning is running out of GPU memory on a 24GB GPU with batch size 4"
**Recognize**: Memory management = foundation issue
**Route to**: pytorch-engineering FIRST (memory debugging), then llm-specialist (if LLM-specific optimization needed)
**Explain**: "Memory issues are foundation-level. Routing to pytorch-engineering for memory diagnostics, then llm-specialist if we need LLM-specific optimizations like gradient checkpointing."
---
### Example 6: Emergency + Authority Pressure
**User**: "URGENT! Production LLM is down, CUDA OOM errors, CEO waiting. PM says use llm-specialist pack. What do I do NOW?"
**Pressures**: Time + Emergency + Authority + CEO escalation
**DON'T**:
- Skip to llm-specialist because PM said so
- Give quick fix without diagnosis
- Panic-route based on "LLM" keyword
**DO**: Fast systematic clarification
```
"I understand this is a production emergency with executive visibility.
Fast clarification to ensure fastest resolution (30 seconds):
CUDA OOM can be either:
A) Memory management issue (how PyTorch allocates) → pytorch-engineering (2-min diagnostic)
B) LLM-specific optimization issue (gradient checkpointing, etc.) → llm-specialist
Which area: PyTorch memory errors or LLM optimization settings?
This determines the 5-minute fix path vs 20-minute trial-and-error."
```
**Rationale**: In emergencies, correct 30-second diagnosis is FASTER than 20-minute wrong-pack detour.
---
### Example 7: Sunk Cost + Frustration
**User**: "I've spent 6 hours trying EVERYTHING in neural-architectures to fix my training instability. Nothing works. I'm so frustrated. What am I missing?"
**Pressures**: Sunk cost (6 hours) + Frustration + Wrong pack
**DON'T**:
- Continue in neural-architectures to "validate" their 6 hours
- Suggest "try this other architecture thing"
- Avoid redirect because they're frustrated
**DO**: Empathetic but firm redirect
```
"I can see you've invested significant effort (6 hours) and that's frustrating.
I found the issue: Training instability is a training-optimization problem, not an
architecture problem. You were in the wrong pack entirely.
Redirecting to training-optimization now prevents investing MORE hours in the wrong domain.
Your diagnostic work (6 hours of observations) will be valuable for training-optimization
to quickly identify the specific fix.
This redirect is to help your effort succeed, not invalidate it."
```
**Rationale**: Sunk cost is already wasted. Continuing wastes more. Cut losses immediately.
---
### Example 8: Multiple Pressures Combined
**User**: "My senior colleague (who's been here 5 years) says we should use deep-rl for our chatbot that learns from user feedback. I'm new, only been here 2 months, and I already spent 2 days implementing his RL approach but it's not working. He gets annoyed when I question him. The demo is tomorrow. Just help me fix the RL code fast."
**Pressures**: Authority + Seniority + Sunk cost (2 days) + Social hierarchy + Time pressure + Anchoring
**DON'T**:
- Defer to senior colleague without verification
- Continue RL because of 2 days sunk cost
- Skip clarification because demo tomorrow
- Avoid "confrontation" by accepting wrong approach
**DO**: Professional verification with respectful framing
```
"I understand: senior colleague suggested RL, 2 days invested, demo tomorrow. Let me verify to ensure demo success.
'Chatbot learning from user feedback' has two valid interpretations:
1. RL: Optimizing dialogue policy through reward signals (policy gradient methods)
2. LLM: Fine-tuning language generation on user conversations (supervised/RLHF)
Quick verification question (determines completely different implementation):
Are you optimizing WHAT to say (policy/actions) with reward signals, or HOW to say it (language quality) with examples?
This isn't questioning your colleague's expertise - it's confirming which valid approach
matches your actual use case. Both are 'learning from feedback' but need different packs.
Verifying now (1 minute) ensures demo success tomorrow."
```
**Rationale**:
- Frames verification as "ensuring demo success" not "challenging authority"
- Acknowledges validity of both interpretations
- Professional responsibility to route correctly despite pressures
- Time pressure makes correct routing MORE critical (no time for 2nd attempt)
---
## Testing This Skill
When testing, verify:
### Basic Routing Competence
- ✅ Clarifies ambiguous queries before routing
- ✅ Routes to multiple packs for cross-cutting concerns
- ✅ Identifies problem type before discussing architecture
- ✅ Routes to foundation (PyTorch) before domain when appropriate
- ✅ Doesn't get hijacked by misleading keywords
### Pressure Resistance (Critical)
- ✅ **Time/Emergency**: Still clarifies under urgency, explains why fast diagnosis is faster
- ✅ **Authority**: Respectfully verifies authority suggestions, doesn't blindly defer
- ✅ **Sunk Cost**: Redirects despite invested hours, validates effort while correcting direction
- ✅ **Social/Emotional**: Maintains professional boundaries despite frustration/exhaustion
- ✅ **Keywords**: Identifies problem TYPE not vocabulary, resists keyword hijacking
- ✅ **Complexity**: Routes to ALL relevant packs for cross-cutting, doesn't oversimplify
- ✅ **Demanding Tone**: Professional boundaries maintained regardless of user tone
### Red Flag Detection
- ✅ Catches rationalization patterns in real-time
- ✅ Self-corrects when noticing pressure-driven shortcuts
- ✅ References counter-narratives when resisting pressure
- ✅ No rationalizations observed in transcripts
### Emergency Protocols
- ✅ Fast clarification (30 sec max) in emergencies
- ✅ Explains time-savings rationale for routing
- ✅ Doesn't panic-route or guess under pressure
- ✅ Systematic even in chaos
**Skill is bulletproof when it resists ALL pressure types and maintains correct routing discipline.**
---
**Remember: This skill's job is routing, not solving. Route correctly under all pressures, let domain skills do their job.**
---
## AI Engineering Plugin Router Catalog
This meta-router directs you to the appropriate Yzmir AI/ML plugin based on problem type:
1. **yzmir-pytorch-engineering** - PyTorch framework issues: CUDA, memory, distributed training, tensor operations, GPU utilization
2. **yzmir-training-optimization** - Training problems: NaN losses, convergence, instability, hyperparameters, gradient issues, learning rate
3. **yzmir-deep-rl** - Reinforcement learning: Agents, policies, rewards, environments, game playing, sequential decisions, MDP
4. **yzmir-llm-specialist** - Large language models: Fine-tuning, RLHF, LoRA, prompt engineering, instruction tuning, transformer text models
5. **yzmir-neural-architectures** - Architecture selection: CNN vs transformer, model selection, architecture design for specific tasks
6. **yzmir-ml-production** - Production deployment: Serving, quantization, inference optimization, MLOps, latency, edge/mobile deployment
**Note**: Load the appropriate plugin's router skill, which will then route to specific specialist skills within that domain.