As we add more skills for frameworks, and support more Intel CPU and GPU families, I think we should define a simple routing and namespacing model early.
The current skills already cover different levels of abstraction: some are framework-specific, some are profiling or setup skills, and some are closer to higher-level planning or routing. Because of that, I would avoid introducing another parallel hierarchy and instead define a clear way to compose and route through the skills we already have.
The main goal is to make requests such as:
- "Deploy vLLM on Xeon"
- "Optimize vLLM on BMG"
- "Profile SGLang on CRI"
- "Optimize a Triton kernel for this Intel GPU"
route through the right framework, task, platform, and hardware-specific knowledge without creating a separate skill for every possible combination.
The basic model would be:
use case
→ framework/task skill
→ shared platform / profiling skills
→ hardware-family-specific guidance
→ validation / benchmark
Example: optimize vLLM on BMG
Optimize vLLM on BMG
→ vLLM optimization/profile path
→ xpu-discover
→ vllm-xpu-profile
→ xpu-profile-unitrace when lower-level profiling is needed
→ detect BMG
→ BMG-specific optimization guidance
→ Triton / SYCL / oneDNN optimization as appropriate
→ vllm-xpu-bench
Example: optimize vLLM on Xeon
Optimize vLLM on Xeon
→ vLLM optimization/profile path
→ cpu-discover
→ vllm-cpu-profile
→ detect Xeon family
→ Xeon-specific optimization guidance
→ shared kernel optimization skills
→ vllm-xeon-bench
The workflow is mostly the same as BMG. Only the hardware-specific guidance changes, so we should not need separate copies of the full optimization skill.
Example: deploy vLLM on Xeon
Deploy vLLM on Xeon
→ deployment router / plan
→ detect CPU
→ detect Xeon family
→ shared system/deployment skills
→ Xeon-family-specific guidance
→ configure vLLM CPU deployment
→ validate deployment
So, the BMG knowledge should be reusable across vLLM, SGLang, PyTorch, and standalone kernel optimization instead of being duplicated under every framework.
Example: optimize a specific Triton kernel
Optimize this Triton kernel for Intel GPU
→ discover target hardware
→ identify GPU family
→ Triton optimization skill
→ load BMG / CRI / PVC-specific guidance
→ correctness validation
→ benchmark
In this case, there may be no vLLM or SGLang routing involved at all.
Namespacing
I would keep namespaces focused on the responsibility of the skill rather than encoding every hardware combination into the skill name.
For example:
vllm/*
sglang/*
pytorch/*
xpu/*
cpu/*
triton/*
sycl/*
onednn/*
Hardware families would be specialization/guidance used by those skills:
gpu:
bmg
cri
pvc
cpu:
granite-rapids
sierra-forest
emerald-rapids
This avoids creating combinations like:
vllm-bmg-optimize
vllm-cri-optimize
vllm-granite-rapids-optimize
sglang-bmg-optimize
sglang-cri-optimize
pytorch-bmg-optimize
...
Instead, the routing composes the existing pieces dynamically.
For example:
vLLM + optimize + GPU + BMG
→ vLLM workflow
→ shared XPU profiling
→ BMG guidance
→ shared kernel optimization
and:
vLLM + deploy + CPU + Granite Rapids
→ deployment workflow
→ shared CPU/system setup
→ Granite Rapids guidance
The important part is to separate:
framework/use case
vLLM
SGLang
PyTorch
task
deploy
profile
optimize
benchmark
platform
CPU
GPU/XPU
hardware family
BMG
CRI
PVC
Granite Rapids
Sierra Forest
implementation/runtime
Triton
SYCL
oneDNN
The router should combine these dimensions rather than requiring us to encode all of them into individual skill names.
This should let us add the skill set while keeping existing skills reusable and avoiding duplication as we add more platforms and specificc use cases. Additionally, reusable things such as vLLM, Triton kernels, or vLLM SYCL kernels should be treated as another routing dimension, so the same hardware and optimization skills can be reused while only the codebase-specific guidance changes.
As we add more skills for frameworks, and support more Intel CPU and GPU families, I think we should define a simple routing and namespacing model early.
The current skills already cover different levels of abstraction: some are framework-specific, some are profiling or setup skills, and some are closer to higher-level planning or routing. Because of that, I would avoid introducing another parallel hierarchy and instead define a clear way to compose and route through the skills we already have.
The main goal is to make requests such as:
route through the right framework, task, platform, and hardware-specific knowledge without creating a separate skill for every possible combination.
The basic model would be:
Example: optimize vLLM on BMG
Example: optimize vLLM on Xeon
The workflow is mostly the same as BMG. Only the hardware-specific guidance changes, so we should not need separate copies of the full optimization skill.
Example: deploy vLLM on Xeon
So, the BMG knowledge should be reusable across vLLM, SGLang, PyTorch, and standalone kernel optimization instead of being duplicated under every framework.
Example: optimize a specific Triton kernel
In this case, there may be no vLLM or SGLang routing involved at all.
Namespacing
I would keep namespaces focused on the responsibility of the skill rather than encoding every hardware combination into the skill name.
For example:
Hardware families would be specialization/guidance used by those skills:
This avoids creating combinations like:
Instead, the routing composes the existing pieces dynamically.
For example:
and:
The important part is to separate:
The router should combine these dimensions rather than requiring us to encode all of them into individual skill names.
This should let us add the skill set while keeping existing skills reusable and avoiding duplication as we add more platforms and specificc use cases. Additionally, reusable things such as vLLM, Triton kernels, or vLLM SYCL kernels should be treated as another routing dimension, so the same hardware and optimization skills can be reused while only the codebase-specific guidance changes.