技能介绍

要解决什么问题

TLE（Tensor Language Extension 一类内核/编译栈工作）往往横跨 kernel 编写、API / verifier / lowering / pipeline 改动，以及 correctness、性能与回归排查。团队常见痛点是：文档散落、环境脚本各项目不同、改 native Triton 时缺少统一标记规范，导致验证步骤和合并材料难以复现。

技能如何组织工作

本技能把单次任务当作一条固定流水线：intake → 实现 → 验证 → 产物 → 合并决策。启动任务前必须按顺序阅读 references/tle-sources.md（技术真源：quickstart、语义契约、kernel 模式、功能开发文件地图、debug/perf 流程）与 references/workflow-templates.md（intake、验证矩阵、性能记录、fix summary、lessons、merge package 模板）。

执行层面强调：

不依赖技能文件夹外的文档；深度说明放在 references/。
每轮任务产出 Validation 命令与结果；修 bug/回归时写 Fix Summary 与 Lessons Entry；收尾给出 Merge Decision Package（变更层、风险、后续项）。
完成清单要求：验收标准对应测试、可复现命令验证、模板填齐、残留风险写清楚。

适用边界与硬约束

禁止假设固定的 Python 环境名或固定 build 脚本名；以 tle-sources.md 为准。
修改 native Triton 相关文件时，使用 // begin flagtree tle 与 // end flagtree tle 标记块；不要在 third_party/tle 内添加标记块。
适合已具备 TLE/FlagOS 代码库上下文、需要按工程化模板交付验证与合并材料的开发任务；不适合替代仓库内未收录的私有规范。