القائمة
当用户提到'原子化'、'拆分文件'、'atomize'、'拆分大文档'、'文件拆分'、'拆分成多个文件'、'单一职责'、'文档重构'、'拆分文档'时，必须使用此技能。提供文档与代码的原子化拆分能力：分析源文件→制定拆分方案→执行拆分→修复链接→收尾验证。不要手动拆分文件——本Skill封装了链接修复、索引更新、一致性检查等必要步骤。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当用户提到'CI检查'、'提交前检查'、'综合检查'、'ci-check'、'流水线检查'、'提交门禁'、'全量检查'、'跑一下CI'、'pre-commit'、'预检'、'检查所有'时，必须使用此技能。提供项目CI/CD综合检查能力，按标准流水线顺序执行10项核心检查：仓库合规→链接检查→Spec一致性→模式成熟度→文档生成→重复代码检测→阶段守卫日志→SG仪表盘→文件放置校验→.temp生命周期检查。提交前必跑，确保代码符合项目规范。不要手动逐个执行检查脚本——本Skill已按正确顺序编排，并处理了跨平台兼容（Windows用.ps1，Linux/Mac用.sh）。
当用户提到'链接检查'、'检查链接'、'断链'、'链接修复'、'fix links'、'check links'、'验证链接'、'死链'、'链接有效性'、'提交前检查'时，必须使用此技能。提供Markdown链接有效性检查与自动修复能力：本地文件引用验证、外部URL可达性检测、file:///绝对路径转相对路径、相对路径层级自动校正。不要手动查找断链——本Skill封装了缓存机制、并发检测、自动修复和dry-run预览，是提交前质量门禁的核心工具。
当用户提到'原子化收尾'、'finalize atomization'、'文档拆分完成'、'文件移动后处理'、'断链修复导航更新'、'一键收尾'、'重构完成后整理'时，必须使用此技能。原子化/文件移动/目录重构后的一键收尾工具：自动断链修复→导航表更新→Spec看板刷新→验证摘要。不要手动逐个执行后处理步骤——本Skill封装了正确的执行顺序和dry-run预览机制，是文档原子化工作流的标准最后一步。
当用户提到'萃取'、'extraction'、'模式沉淀'、'萃取模式'、'模式入库'、'沉淀为模式'、'可复用模式'、'更新模式库'、'生成模式文档'时，必须使用此技能。提供标准化的模式萃取流程：案例收集→本质抽象→结构化模板→反模式提炼→迁移验证→入库。不要手动组织萃取流程——本Skill封装了六步标准萃取法、反模式对等原则和可迁移性验证。替代旧的pattern-extraction-cmd（v1.0.0）。
当用户提到'知识图谱'、'knowledge graph'、'概念关系可视化'、'交互式知识图谱'、'节点关系网络'、'生成知识图谱'、'可视化知识库'、'概念网络'、'knowledge graph config'时，必须使用此技能。从结构化Markdown文档集（术语表/文档索引/时间线等）自动提取节点和关系，生成交互式vis-network HTML知识图谱。支持TOML声明式配置和Python API两种方式，内置节点去重、孤立节点检测、类型筛选、可信度分级显示。不要手动拼接vis-network代码——本Skill封装了表格解析、关系构建、HTML模板渲染和自包含输出，确保产出质量可预测。
当用户提到'mermaid'、'流程图'、'时序图'、'状态图'、'画个图'、'图表'、'架构图'、'思维导图'、'ER图'、'类图'、'甘特图'、'饼图'、'UML图'、'可视化流程'、'画流程图'、'mermaid图'、'可视化'、'流程可视化'时，必须使用此技能。提供标准化的Mermaid图表创建、检查、修复流程，引导完成从设计→编码→检查→修复→验证→交付的完整闭环。不要手写Mermaid代码绕过本Skill——本Skill封装了安全编码六规则、模板选择、自动检查修复流程，确保图表质量可预测。
| name | atomization-cmd |
| version | 1.3.0 |
| description | 当用户提到'原子化'、'拆分文件'、'atomize'、'拆分大文档'、'文件拆分'、'拆分成多个文件'、'单一职责'、'文档重构'、'拆分文档'时，必须使用此技能。提供文档与代码的原子化拆分能力：分析源文件→制定拆分方案→执行拆分→修复链接→收尾验证。不要手动拆分文件——本Skill封装了链接修复、索引更新、一致性检查等必要步骤。 |
| argument-hint | <目标类型：document/code/config> <源文件路径> |
| user-invocable | true |
| paths | [".agents/commands/atomization.md",".agents/scripts/finalize-atomization.py",".agents/scripts/check-atomization-coverage.py","rules/cmd-log-specification.md"] |
| title | Atomization 原子化命令 Skill |
| x-toml-ref | ../../../.meta/toml/.agents/skills/atomization-cmd/SKILL.toml |
⚠️ 本Skill是命令入口门面（L1索引层），遵循渐进式披露三层架构：
- L0：.agents/ONBOARDING.md（入口速查）
- L1：本文件（<500行，触发词+决策树+核心步骤+安全清单）
- L2：commands/atomization.md（完整流程）+ cmd-log-specification.md（日志规范）
atomization-cmd
提供文档与代码的原子化拆分能力，确保拆分后的文件遵循单一职责原则：
| 方案 | 推荐场景 | 优势 |
|---|---|---|
| 文档原子化 | ⭐ 大文档拆分（如复盘报告、长规范） | 单一主题、易维护、可独立引用 |
| 原子化+收尾 | ⭐ 拆分完成后的一键收尾 | 自动修复断链+更新导航+刷新看板 |
| 原子化预检 | 创建新模式前的覆盖度检查 | 避免重复创建已有模式 |
核心功能：分析源文件结构→制定拆分策略→创建原子文件→迁移内容→更新交叉引用→一键收尾。
为什么用本Skill而非手动拆分？ 手动拆分最大的陷阱是链接断裂——文件移动后相对路径错误导致大量断链，修复成本非线性增长（跳过5分钟的规范可能导致30分钟返工）。本Skill配合finalize-atomization.py自动处理链接修复、导航更新、看板刷新。
当用户提到以下任何内容时触发：
关于触发：原子化是高风险操作（涉及文件创建/移动/链接修改），必须使用本Skill确保流程规范。拆分前先用check-atomization-coverage.py预检，拆分后必须用finalize-atomization.py收尾。
需要进行原子化拆分？
├─ 拆分前预检（检查是否已有模式覆盖）？ → 先运行 check-atomization-coverage.py
├─ 拆分文档（Markdown报告/规范等）？ → 文档原子化流程
├─ 拆分完成需要收尾？ → finalize-atomization.py 一键执行
├─ 原子化后需要检查一致性？ → check-atomization-duplication.py 检查残留内容
└─ Git提交原子化结果？ → 拆分完成后使用 atomic-commit-cmd
决策前输出CMD_START日志（session前缀 atom-YYYYMMDD-<topic>）：
[CMD-LOG] | level=INFO | cmd=atomization | step=S0 | event=CMD_START | session=atom-... | msg=开始文档原子化：<简述> | ctx={"target_file":"...","criteria":"single-responsibility"}
为什么决策前必须记录日志？ 文档拆分涉及文件移动和断链修复，拆分范围判断错误可能破坏文档结构，CMD_START记录目标文件和拆分依据便于回溯。
步骤1：读取 [.agents/commands/atomization.md](../../commands/atomization.md) 了解完整流程
步骤2：预检阶段：
- 运行 check-atomization-coverage.py 确认新内容未被已有模式覆盖
- 分析源文件的核心主题和结构
- 确定拆分策略（按主题/功能/模块/组件）
步骤3：制定拆分方案：
- 规划新文件的命名和目录结构
- 设计文件间的引用关系
- 将源文件转为索引页
步骤4：执行拆分：
- 创建新的原子文件（每个文件单一主题）
- 添加正确的frontmatter（含source溯源字段）
- 迁移内容到对应文件
步骤5：收尾阶段（关键！）：
- 运行 finalize-atomization.py 自动修复断链+更新导航+刷新看板
- 运行 check-links.py 验证所有链接有效
- 运行 check-atomization-duplication.py 检查源文件无残留深度内容
完整RACI矩阵、拆分策略选择指南、frontmatter规范、断链修复规则见L2文档 commands/atomization.md。
为什么必须运行 finalize-atomization.py 收尾？ 文件拆分后最容易出问题的环节是链接修复——手动修改相对路径的遗漏率高达40%（项目历史数据），且断链具有传播性：一个错误的相对路径会导致整个文档导航链断裂。finalize脚本一次性完成断链自动修复、导航更新、看板刷新，把非线性返工成本（30分钟以上）降为线性自动化操作（<1分钟）。跳过收尾步骤等于把风险留给后续读者。
为什么新文件必须包含source溯源字段？ 原子化拆分后，文件从原始文档迁移到独立位置，如果没有source字段记录"这个文件从哪里来"，几个月后追溯内容来源时会完全断链——你无法知道某个模式最初是在哪次复盘/哪个文档中产生的。source字段是知识图谱的反向指针，确保内容的历史脉络可追溯。
执行原子化命令集时，必须按 CMD-LOG规范 输出结构化日志：
cmd=atomization，session前缀 atom-YYYYMMDD-<filename>PRECHECK_RESULT、DUPLICATE_FOUND、SPLIT_PLAN、OVER_SPLIT_WARN、FILE_CREATED、LINK_FIXED、FINALIZE_RUN、BROKEN_LINKS_FOUND、RESIDUAL_FOUND完整字段说明、21个事件表格、日志示例见L2文档 cmd-log-specification.md §7.4。
| 脚本 | 层级 | 用途 | 何时使用 |
|---|---|---|---|
| check-atomization-coverage.py | L1工具 | 预检：检查模式库是否已有覆盖 | 拆分前必运行 |
| finalize-atomization.py | L1工具 | 一键收尾：修链接+更新导航+刷看板 | 拆分完成后必运行 |
| check-atomization-duplication.py | L1工具 | 检查：源文件残留内容 | 收尾后验证 |
| check-links.py | L1工具 | 链接有效性验证 | 收尾后验证 |
为什么需要Gotchas？ 错误处理记录"已知错误码及修复方式"，Gotchas记录"容易踩的坑、反直觉行为、容易被忽略的约束条件"——不会产生明确错误码但会导致结果不符合预期的隐性陷阱。
"原文件名#锚点" 格式（如 source: "long-report.md#insights-section"），用于追溯内容来源，格式错误会导致溯源断链。00-、01-、02-...），确保文件管理器和Git按逻辑顺序排序——使用单位数（0-、1-）会导致排序错误（10-排在2-前面）。<!-- NAV_START --> 和 <!-- NAV_END --> 标记包裹，docgen每次运行会覆盖标记区域内的内容——手动编辑会在下次docgen时丢失，需要添加自定义导航项应放在标记区域外。../ 层数会随目录深度变化——这是断链高发区，finalize脚本会自动校正，但手动添加链接时务必注意层级计算。| 参考 | 层级 | 路径 | 何时查阅 |
|---|---|---|---|
| 完整命令文档（RACI/参数/模板） | L2 | commands/atomization.md | 每次使用必读 |
| CMD-LOG日志规范 | L2 | cmd-log-specification.md | 日志格式、事件定义、解析方法 |
| 原子化三标准测试 | L2 | atomization-three-criteria-test.md | 判断是否需要拆分 |
| 原子化三层分类 | L2 | atomization-three-tier-classification.md | 确定拆分粒度 |