القائمة
用于生成对外api文档，当用户说生成接口文档，生成接口说明，增加接口说明，增加接口文档时使用该skill
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
HIXL 代码检视技能。用于检视 GitCode 上的 HIXL 项目 PR，当用户要求检视PR，审查PR时调用此skill。 自动分析代码变更，检查内存泄漏、安全漏洞和可读性，生成结构化报告并发布评论。
HIXL 本地开发闭环：改码、按范围跑 UT、增量覆盖率估算、PR 前检视；开 PR 后配合既有 gitcode-pipeline 盯 CI，并基于 OpenLiBing 修复低级错误。修改 HIXL 源码/测试/构建脚本、 本地验证、/hixl-dev、CI 失败修复时使用。创建 PR 用 gitcode-pr，流水线轮询用 gitcode-pipeline。
在 Ascend 上定位 HIXL/ADXL/HIXL_CS 建链、传输问题。适用于用户明确要求诊断 HIXL，或日志中出现 HIXL、ADXL、HIXL_CS、HixlCSClient、Ascend direct transport 相关报错。
触发 GitCode PR 流水线，并循环查询流水线状态直到完成。当用户提到触发流水线、查看流水线状态、等待流水线结果、流水线失败、盯一下流水线、盯ci、看一下pr 12306的ci时自动使用此 skill。
读取 GitCode issue 详情和评论。当用户提到 GitCode issue 时必须使用此技能。 **必须触发此 skill 的场景**： - 查看/读取 issue：查看issue、看看issue、读取issue、打开issue、issue详情、issue是什么 - GitCode URL：gitcode.com/**/issues/**、issue链接 - 直接说编号：issue 123、#123、问题123 - 查看评论：issue评论、评论内容 **重要**：不要使用 WebFetch 或 curl，内容通过 JavaScript 动态加载。使用 GitCode API 获取。
使用 GitCode API 创建 Pull Request 和获取 PR 评论。当用户需要**创建** GitCode PR、将代码**推送并创建合并请求**、**获取 PR 评论**、**查看 PR 讨论**、**查看 PR 改动**或**删除 PR 评论**时使用此 skill。支持读取普通评论和行内(diff)评论，包括评论内容、文件路径、代码行号等详细信息。 **必须触发此 skill 的场景**（用户提到以下任何内容时使用）： - 创建/提交 PR：创建PR、提个PR、发PR、做个PR、帮我PR、生成PR、需要PR、pull request、merge request - 推送代码到远程：push代码、推代码、把代码推上去、提交到远程、推送到gitcode、提交代码到GitCode - 合并请求：合并请求、代码合入请求、请求合并、merge request - PR模板/描述：PR模板、PR描述、PR格式 - 关联issue创建PR：关issue的PR、关联issue创建PR - 获取PR改动：查看PR变更、PR文件列表、PR改了什么、看PRdiff、获取PR文件 - **获取 PR 评论**：查看PR评论、PR评论、获取评论、read comments - **查看 PR 讨论**：PR discussions、查看讨论、discussions - **删除 PR 评论**：删除评论、删除PR评论、移除评论、delete comment、移除这条评论
| name | api-doc-generator |
| description | 用于生成对外api文档，当用户说生成接口文档，生成接口说明，增加接口说明，增加接口文档时使用该skill |
| 规则 | 说明 |
|---|---|
| 1. 中文标点符号 | 中文描述中使用中文标点符号，不要出现英文符号（如括号、逗号、句号等），注意不要出现多余或缺失标点。注意：markdown 表格格式符号（|、:、-）不属于此规则检查范围 |
| 2. 概念规范 | 尽量不要出现术语表之外的无法理解的私有概念，首次出现专业术语时应提供解释 |
| 3. 数据类型规范 | 描述数据类型时需要和代码中的数据类型一致；只和位宽有关时可以通过位宽表达 b8\b16\b32\b64 |
| 4. 逻辑通顺 | 前后逻辑通顺，下文不要出现上文没介绍的内容 |
| 5. 语言规范 | 写作时避免口语化，比如避免使用倒装句 |
| 6. 标题一致性 | 一级标题名和 markdown 文件名称应保持一致 |
| 7. 引用接口验证 | 文档中引用其他 API 接口时，必须确保该接口确实存在 |
标准 API 文档必须包含以下章节：
例外：结构体说明文档和通用说明文档不受此规则约束。
产品支持情况章节必须满足以下格式规范要求（按接口实际支持度检查，不强制要求写全）：
| 要求 | 说明 |
|---|---|
| 1. 产品型号名称 | 必须使用规范的产品型号名称：• Ascend 950PR/Ascend 950DT • Atlas A3 训练系列产品/Atlas A3 推理系列产品 • Atlas A2 训练系列产品/Atlas A2 推理系列产品 |
| 2. 顺序要求 | 多个产品型号必须按以下顺序填写（950 → A3 → A2） |
| 3. cann-filter标签 | 当文档中混合不同产品内容时，Ascend 950PR/Ascend 950DT 需要使用 cann-filter 标签包裹整行；如果整个 markdown 文件都是 Ascend 950PR/Ascend 950DT 的内容则不需要 |
| 4. 表格格式 | 表格必须有"产品"和"是否支持"两列，支持标记使用"√"，markdown 表格能正常渲染即可 |
示例格式：
| 产品 | 是否支持 |
| :----------- | :------: |
| Ascend 950PR/Ascend 950DT | √ |
| Atlas A3 训练系列产品/Atlas A3 推理系列产品 | √ |
功能说明章节必须满足以下要求：
| 要求 | 说明 |
|---|---|
| 1. API作用与目的 | 必须清晰说明该 API 的作用和目的 |
| 2. API配合关系 | 如果与其他 API 有配合关系，需要说明（也可在约束说明中体现） |
| 3. 复杂接口说明 | 复杂的接口需要提供公式或配图辅助说明 |
函数原型章节必须满足以下要求：
| 要求 | 说明 |
|---|---|
| 1. 与头文件一致 | 函数原型必须与头文件中的定义严格一致 |
| 2. 多原型区分与列表缩进 | 多个原型需要通过无序列表（-）区分，无序列表本身需要正确的缩进格式，并说明不同原型之间的区别 |
| 3. 无分号 | 函数原型末尾不需要分号 |
参数说明章节必须满足以下要求：
| 要求 | 说明 |
|---|---|
| 1. 与函数原型一致 | 参数必须与函数原型严格保持一致 |
| 2. 输入/输出标识 | "输入"表示入参，"输出"表示出参，按实际情况正确填写 |
| 3. 数值类参数 | 需要列出取值范围、单位（取值范围在原型中已明确体现的可省略） |
| 4. 结构体参数 | 需要添加到结构体参数介绍的链接 |
| 5. 特殊取值解释 | 有特殊含义的参数取值需要增加解释 |
| 6. 复杂参数配图 | 复杂参数解释需要在表格后配图说明 |
| 7. 表格格式 | 表格必须有"参数名"、"输入/输出"、"描述"三列；markdown 表格格式符号（|、:、-）不属于文字标点符号检查范围 |
/home/developer/Ascend或者/usr/local/Ascend路径，如果还找不到，不要再尝试了，直接询问用户cann-toolkit包的安装路径