Thanks for sending an requirement! Please fill in the following template to help quickly solve your problem.

Backgroud（背景信息）

当前 ops-blas 仓的 agent/ 目录维护了一套自包含的算子开发工作流（blas-new-op-workflow、blas-new-op-workflow-maintain、各 blas-* skill），编排逻辑与领域知识耦合在同一套 skill 中，存在以下问题：

1. 编排重复建设：每个算子仓（ops-blas、ops-sparse 等）各自维护一套完整工作流编排，跨仓无法复用，编排升级需逐仓同步。
2. 领域知识与编排耦合：blas-new-op-workflow SKILL.md 中同时包含流程编排（角色分工、CP 门控）和领域知识（cuSPARSE 对齐、描述符生命周期、异步 kernel 等硬规则），职责混杂。
3. skill 命名私有化：skill 以 blas-* 前缀命名，无法与基类通用逻辑名对齐，无法被基类工作流通过逻辑名引用。

cannbot-skills 仓的 cuda2ascend 插件已采用面向对象设计，提供基类工作流（ops-direct-invoke-workflow 等，FINAL 不可变），各算子仓作为子类通过 --override 机制以相同逻辑名覆写 6 个虚拟 skill（repo-*）。ops-sparse 仓已完成此迁移，验证了该架构的可行性。

本次需求：将 ops-blas 仓的 agent/skills 迁移至 cuda2ascend 基类继承架构，与 ops-sparse 保持一致。

Origin（信息来源）

CANN生态开发者

Benefit / Necessity （价值/作用）

价值：

• 消除编排重复：编排逻辑由基类统一维护，ops-blas 只需覆写与稀疏算子耦合的领域知识，升级基类即可获得流程改进。
• 职责清晰：编排（FINAL）与领域知识（virtual skill）分离，领域知识按功能域拆分到独立 skill，单一职责。
• 跨仓一致：ops-sparse 与 ops-blas 采用相同的 skill 逻辑名和目录结构，降低维护成本和认知负担。
• 可扩展性：新增算子仓时只需覆写 6 个虚拟 skill，无需重新搭建完整工作流。

应用场景：所有使用 CANNBot Agent 进行 ops-blas 算子开发的场景。

必要性：若不迁移，ops-blas 将持续维护独立的编排逻辑，与基类演进脱节，跨仓一致性无法保证。

Design（设计方案）

迁移核心变换

1. 重命名为基类通用逻辑名：blas-* → repo-*，name: 字段同步更新
2. 解耦工作流步骤引用：去掉 SKILL.md 中对特定步骤的引用（如 "2.x.2 联调前"、"CP1.1.A"），改为通用场景描述
3. 代码模板重构：templates/ → references/，改为嵌套目录结构 references/<model>/blas/{op}/archXX/
4. 内联代码抽取为模板：测试 SKILL.md 中的代码示例抽取为独立模板文件