技能介绍

要解决什么问题

在 Python/Triton 项目里手写 GPU 算子，往往还要分别处理 FlagGems、vLLM 的目录约定、注册方式和集成模式；优化与「从 GPU 迁到 Ascend NPU」又是另一套流程。Kernelgen FlagOS 把「生成 → 优化 → 平台特化」收成一个统一入口，由技能先识别仓库类型，再加载对应子技能，避免在通用流程和框架专用流程之间选错文件。

技能如何工作

执行顺序是固定的路由协议：

Phase 0：先走 kernelgen-mcp-setup.md，确认 kernelgen-server MCP 已配置（URL 内置，用户主要提供 Token）；未就绪则停在配置步骤，不继续生成。
Phase 1：用 pyproject.toml / setup.py 等判断项目名，并结合目录结构（如 src/flag_gems/、vllm/ + csrc/）区分 FlagGems、vLLM 或未知仓库。
Phase 2：按用户意图分发——新建算子读 generate 系列；提到 optimize / speedup 读 optimize 系列；提到 specialize / 迁 NPU 读 specialize 系列；用户点名某子技能则优先遵从。

硬性约束：所有算子代码必须经 MCP 工具完成——mcp__kernelgen-mcp__generate_kernel、optimize_kernel、specialize_kernel；Agent 不得自行编写 Triton kernel 或 PyTorch 包装。MCP 不可用或重试失败时应停止并报告，不能退化为手写实现。

同目录下的子技能文件（如 kernelgen-generate-for-flaggems.md、kernelgen-optimize-for-vllm.md）各自包含完整步骤；入口技能要求整文件读完再执行，且一次任务只跟一条子技能走到底。

适用边界与注意点

面向 Triton / GPU 算子 工作流；FlagGems 优化/integration 有 built-in、external、experimental 等模式，vLLM 侧涉及 CustomOp 注册，细节以对应子技能为准。
vLLM 的 specialize 分支在决策表里未单独列出，非 FlagGems 场景会走通用 kernelgen-specialize.md。
流程中可随时通过 kernelgen-submit-feedback.md 走 GitHub 或邮件反馈；提交后由用户决定是否继续算子任务。