本文へ移動
cccskills
無料GitHub で公開

markdown-lint

MindIE-SD 仓库 Markdown 格式 lint 规则。当编写、修改或审查 Markdown 文件(README、文档、 变更日志等)、或 CI 门禁报出 markdownlint 违规时使用此 skill。 即使用户只提到"格式问题"或"MD040报错"而未说 markdownlint,也应触发;Python 格式问题见 code-standards。 通常由 dev-workflow 和 code-standards 在编码/审查阶段指引加载。

インストール方法を見る

含まれるファイル(2)

  • SKILL.md6.1 KB
  • evals/evals.json1.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Markdown 格式 Lint 规范

本 skill 汇总 MindIE-SD 仓库的 Markdown 格式 lint 规则,适用于 .md 文件的编写、修复与审查。

事实来源:

  • .pre-commit-config.yaml(markdownlint 钩子配置)
  • markdownlint-cli v0.44.0 规则集

1. 核心规则

1.1 MD040 — Fenced code blocks should have a language specified

所有围栏代码块(```)必须指定编程语言或内容类型。

正例:

```shell
npu-smi info -l
```python
def foo():
    pass

**反例(触发 MD040):**

```markdown

examples/dummy_run/ ├── model/ ├── wan_infer.py └── README.md

代码块语言选用指南:

内容类型语言标记
Python 代码python
Shell 命令shell 或 bash
目录 / 文件树text
终端输出 / 日志text
纯文本 / 伪代码text
YAML 配置yaml
Markdown 示例markdown
JSON 数据json

1.2 其他常见规则

规则说明
MD009禁止行尾空格(由 trailing-whitespace 钩子覆盖)
MD012禁止连续多个空白行
MD031围栏代码块前后需有空行
MD032列表前后需有空行(**标题**: 段末直接接列表、块引用内列表项前缺空引用行都会触发)
MD047文件末尾需有换行符(由 end-of-file-fixer 钩子覆盖)

2. 验证命令

⚠️ 先读清钩子结构(2026-09 核实):.pre-commit-config.yaml 里有两个同 id: markdownlint 的钩子,别当成一个:

  • markdownlint-manual(alias):exclude: ^\.agents/ + stages: [manual] —— 仓库 .agents/ 之外的 .md 才需要显式触发;
  • markdownlint-agents(alias):files: ^\.agents/.*\.md$,未覆盖 stages ⇒ 走 default_stages: [pre-commit],即提交/CI 默认就会跑 —— 所以「本地 pre-commit run --all-files 通过 ≠ Markdown 合规」这句话对 .agents/** 不成立。

另两条事实:配置为 .markdownlint.json(default: true,关闭 MD013/MD033/MD041/MD046); 版本必须用仓库 pin 的 v0.44.0 —— 更高版本(如 0.49.x)会对同一批文件报上千条 MD060 版本性假违规(实测 0.44.0 = 0 违规 vs 0.49.1 = 1943 条)。

2.1 全量检查

# 检查单个文件(manual 档的钩子必须带 --hook-stage manual,否则被跳过 = 实际没检查)
pre-commit run markdownlint-manual --hook-stage manual --files path/to/file.md

# 检查所有文件(CI 模式)
pre-commit run markdownlint-manual --hook-stage manual --all-files

markdownlint-manual(全仓档)配置为 stages: [manual],必须显式带 --hook-stage manual 才会执行——不带该标志的命令会被 pre-commit 跳过而静默什么都不检查。 .agents/**/*.md 由 markdownlint-agents 在默认档强制执行,无需手动触发。

2.2 提交范围专项检查

对 commit 新增或修改的 .md 文件做独立检查,避免全量噪音:

git diff --name-only HEAD~1..HEAD -- '*.md' | xargs markdownlint -c .markdownlint.json

2.3 配置优先

  • 始终使用 -c .markdownlint.json 配置文件而非 --disable 命令行参数
  • PowerShell 中 --disable MDxxx 的数组传参可能不生效,导致规则未真正禁用

3. 修复模板

3.1 目录树 / 终端输出

<!-- 修改前 -->

examples/ ├── a.py └── b.py


<!-- 修改后 -->
```text
examples/
├── a.py
└── b.py

### 3.2 无明确代码语言的内容

```markdown
<!-- 修改前 -->

Warmup inference (1 step) ... [transformer] 7.1s Inference time: 7.1 s


<!-- 修改后 -->
```text
Warmup inference (1 step) ...
  [transformer] 7.1s
Inference time: 7.1 s

---

## 4. 与 dev-workflow 的关系

本 skill 作为 `dev-workflow` 的补充模块,在以下时机触发:

- 新建或修改 `.md` 文件后,提交前
- CI 门禁报出 `markdownlint` 违规时
- 模板文件(PR/Issue)变更时

`dev-workflow` 的 Test-First 流程中,编码阶段需确保 Python 代码通过 Ruff 检查,同时确保 Markdown 文件通过 `markdownlint` 检查。

---

## 5. 批量修复注意事项

### 5.1 编码安全

PowerShell 5.1 下用 `Get-Content` / `Set-Content` 读写含中文的 UTF-8 文件会导致编码破坏(BOM 注入 + 字节重解释)。

**安全方式:**

- Python:`open(f, 'r', encoding='utf-8')` / `open(f, 'w', encoding='utf-8')`
- Node.js:`fs.readFileSync(f, 'utf-8')` / `fs.writeFileSync(f, content, 'utf-8')`

**避免:** PowerShell `Get-Content` / `Set-Content` / `Out-File` 直接读写 UTF-8 含中文文件。

### 5.2 MD040 修复模式

替换 `` ``` `` → `` ```text `` 时需覆盖两种变体:

- **顶格** `` ``` ``(行首无空白)
- **缩进** ``   ``` ``、``     ``` `` 等(保留前导空白,缩进代码块)

### 5.3 修复后验证

1. 重跑 `markdownlint -c .markdownlint.json {files}` 确认 0 违规
2. `git diff` 检查只有预期替换行变化,无编码污染(BOM、乱码)
3. 确认中文等非 ASCII 字符未损坏

## 6. 维护与更新

当 `markdownlint-cli` 版本升级、`.pre-commit-config.yaml` 中 markdownlint 配置变更、
或新 MD 规则启用时,按 `dev-workflow` 的复盘流程更新本 skill。

> 绑定提示:本 skill 内容与仓库 `.markdownlint.json` / pre-commit 配置强绑定,
> 配置变更(含 MD 规则开关)后须同步本文规则描述与修复模板。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

**精度验收标准**:凡是"改动不应改变结果"的场合(等价替换、算子/子模块融合、并行切分、 编译与图下发、拷贝消减),都按本标准判"合格 / 不合格"——等价分层(L1 逐位 / L2 数值门 / L3 有损门)+ 三级验收序(① 同配置重跑逐位 → ② 跨配置数值门 + 产物 md5 不变 → ③ 质量门)+ 判据不达标时的排障入口。当用户说"这个算子能不能换个写法/换个 kernel/等价实现/ 无损替换""替换后结果会不会变""怎么证明逐位一致""结果不对""花屏""尾部塌了" "CPU 跑对 NPU 跑不对",或发现某个 hotspot 占了大头(例如某类算子在阶段里占 90% 以上)想动手时, 都应触发;即使用户只说"这样改有没有把结果改坏""能不能判它是无损的"也应触发。 覆盖:等价分层与判据、满足本标准的实现约定(per-shape 对拍写进实现,把索引/相位/顺序类重写 错误在首次调用抓住)、per-shape 条件性等价(同一改动在不同形状下结论可能不同)、 判据不达标 → `references/silent-failure-localization.md` 排障入口、否决案例的形态学 (换写法未换 kernel / 差异极小仍非逐位 / 等价但 OOM)、以及收益口径的归属(性能数字一律交 `perf-gate`)。 **近义分流**:选量化档 / 特性选档(要不要开量化、开哪一档)→ `dit-perf-opt`; 并行选型(USP / CP / TP 怎么切)→ `dit-parallel-opt`;本技能只判"结果是否被改变", 不负责选档与选型。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

NPU 图批量下发能力(aclgraph / aclgraph_ex 家族)的开发与调优。覆盖 mindiesd 的 aclgraph_backend:NPUGraph 静态 capture、全局 graph pool、 lazy capture、专用 copy stream + event 管线、shape/dtype 校验、max_entries 驱逐。 当用户需要减少 host launch 开销、静态 shape 大 batch 场景加速、 或排查 NPUGraph replay 输入不匹配问题时使用此 skill。 即使用户只提"批量下发""graph capture""图捕获"而未说 aclgraph,也应触发; pattern/Inductor 融合(default 后端)见 pattern-dev,算子本体见 operator-dev, 本技能只覆盖图批量下发。由 dev-workflow 的编译开发阶段与 model-auto-optimization 的 图下发场景指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD 核心算子(FA/BSA/GMM/MM)性能基准工具链。使用:模型优化(model-auto-optimization 的 S1/S4 选型)中用 mindie_bench 对单算子做实现级实测,按 dtype/量化档/稀疏度/形态对比 选出最优配置(产物:选型证据;稀疏度-性能曲线供 S4 稀疏度选型);开发:benchmarks/ 工具链扩展与新算子接入测试(供 operator-dev / pattern-dev 调用)。 当用户需要对比算子实现选型、新增或修改 benchmark 代码、排查 benchmark 数据异常、 给基准加算子/指标时使用;即使用户只说"benchmark 数据不对""给基准加个算子" "对比下这几个 FA 实现哪个快"也应触发;特性级方案选档请走 dit-perf-opt (本 skill 只做实现级实测)。 由 model-auto-optimization 的 S1/S4 选型场景与 operator-dev 的算子接入验证场景调用, 亦由 dev-workflow 在基准开发时指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD Python 代码格式与 lint 规则。当编写、格式化、lint 检查或审查 MindIE-SD 项目的 Python 代码时使用此 skill。 即使用户只提到"提个MR"或"代码好像有 lint 问题"而未明确说格式化,也应触发;Markdown 格式问题见 markdown-lint,提交/PR 规范见 mindie-sd-community-governance。 通常由 dev-workflow 在编码阶段指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD 仓库开发总入口(侧轨)。当用户进行 MindIE-SD 的任何代码开发工作时使用此 skill—— 包括但不限于写 pattern、改测试、部署到昇腾、跑 benchmark、性能分析、多卡并行、复盘归档。 模型/三方框架自动优化类任务(非本仓代码改动)由 model-auto-optimization 入口承接, 本入口只在优化流程需要新增 pattern/算子/部署代码时承接其指向的开发子任务。 即使用户未明确提到"开发流程",只要涉及 MindIE-SD 代码改动都应触发。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

分布式并行策略选型与实测(USP / CP 通信掩盖 / CFG / TP/RSP/PP 概览;含拓扑相关选型 (按实测拓扑分域条件化:域内 bulk vs 跨域 head-parallel 翻转)与 AlltoAllV 缺陷绕过)。在 model-auto-optimization 中承担 S3:优先 USP、结合拓扑带宽差异选 CP,少量 step + 多 rank 验证特性开启与掩盖(产物:并行方案 + 多 rank 证据)。当用户需要多卡并行 策略选择、**序列并行形态抉择**(纯 Ulysses vs 复合 AllGather-KV×Ulysses:按 GQA / 跨域带宽 / 形态 plumbing 条件化定胜负)、**并行 × 稀疏叠加**(seam 契约:先汇聚后稀疏、 窗口偏移、块对齐、per-head 掩码;含「稀疏看似生效实则未生效」判定)、通信掩盖调优 (含**掩盖率上限**:1-1/n 何时成立、c/f 决定的真实上限、没生效的排查)、**并行方案 差异归因**(阶段 Δ 分解 / 集合通信按 communicator 归属 / 4→8 卡线性度),或排查多卡 跑不动 / 通信暴露大 / 换卡组 / 端口 bind / HCCL 带宽验证问题时使用;**并收编原并行作用域诊断**: 改了 SP/CP/Ulysses/AllGather-KV 后**不报错但结果没变/性能没变**、或小规模能跑大规模崩 (如 Ascend EE1003 coreDim 超限)时,用本技能证明"改动到底有没有生效"(判别量逐层收窄 + 两侧对照 + 日志≠生效,见 `references/scope-effectiveness-check.md`); 即使用户只说 "多卡跑不动""通信暴露大""为什么没达到 6/7 的掩盖率""CP 和 USP 该选哪个""CP 叠稀疏 怎么不生效"而未说并行,也应触发。特性档位/接口事实见 `docs/zh/features/parallelism.md` /`usp.md`(仓内真源),框架侧开启见 framework-integration; 本技能承载选型决策、monkey-patch 掩盖与多卡诊断实测。 由 dev-workflow 多卡场景触发,亦由 model-auto-optimization 的 S3 阶段触发。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

Ascend のスキルをすべて見る

このスキルの問題を報告する