メニュー
用于生成对外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包的安装路径