Add Routing and Namespacing for Reusable Skills

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:

```text id="sk5ncx"
use case
→ framework/task skill
→ shared platform / profiling skills
→ hardware-family-specific guidance
→ validation / benchmark
```

### Example: optimize vLLM on BMG

```text id="f90bdu"
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

```text id="sjr7ko"
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

```text id="ryoj14"
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

```text id="p0j08z"
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:

```text id="h254dg"
vllm/*
sglang/*
pytorch/*

xpu/*
cpu/*

triton/*
sycl/*
onednn/*
```

Hardware families would be specialization/guidance used by those skills:

```text id="dzz1dc"
gpu:
bmg
cri
pvc

cpu:
granite-rapids
sierra-forest
emerald-rapids
```

This avoids creating combinations like:

```text id="o32hxw"
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:

```text id="0g3bsb"
vLLM + optimize + GPU + BMG
→ vLLM workflow
→ shared XPU profiling
→ BMG guidance
→ shared kernel optimization
```

and:

```text id="rnjmzh"
vLLM + deploy + CPU + Granite Rapids
→ deployment workflow
→ shared CPU/system setup
→ Granite Rapids guidance
```

The important part is to separate:

```text id="gvb3un"
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.

The issue does not name specific files, tests, or entry points. Start by mapping the existing skills against the proposed framework, task, platform, hardware-family, and runtime dimensions, then identify where routing and namespacing should live. Done means a concrete reusable model is documented and its handling of the listed vLLM, SGLang, PyTorch, and Triton examples is agreed.

Written by the indexing model from the issue text.