菜单
对任意代码项目生成一套面向新人的循序渐进文档集，输出到 docs/ 目录。含架构、设计思想、语言特性、代码导读、运行时模型、构建、对接、调试、设计规范共 9 篇，支持全部生成 / 只写几篇 / 更新已有文档。当用户提到"生成项目文档"、"新人文档"、"上手文档"、"架构文档"、"代码导读"、"项目理解"、"深入理解项目"、"onboarding 文档"、"给新同事看的文档"时使用。要按用户给的格式写论文章节、项目梳理、重点问题、简历项目描述的，用 codegen-doc。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/xstongxue/best-skills --skill project-docs命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
根据论文或汇报内容生成多页 Draw.io 格式 PPT，支持论文答辩与通用汇报两种模式，自动导出为 .pptx。当用户提到论文答辩 PPT、答辩幻灯片、通用 PPT、汇报 PPT、根据模板生成 PPT、drawio2pptx 时使用。
基于当前项目/代码生成各类文档，支持论文章节、项目梳理、重点问题、简历项目描述四种类型。当用户提到生成论文章节、项目梳理、技术难点、简历项目描述时使用。要给新同事看的上手文档（新人文档、架构文档、代码导读、onboarding）用 project-docs。
生成高质量 Markdown 周报、工作汇报、总结、介绍等文档。无草稿时从 Web 搜索并总结；有草稿时结合草稿整理、润色、补充。当用户提到周报、工作汇报、总结、介绍、述职、复盘时使用。
正在显示 SKILL.md
| name | project-docs |
| description | 对任意代码项目生成一套面向新人的循序渐进文档集，输出到 docs/ 目录。含架构、设计思想、语言特性、代码导读、运行时模型、构建、对接、调试、设计规范共 9 篇，支持全部生成 / 只写几篇 / 更新已有文档。当用户提到"生成项目文档"、"新人文档"、"上手文档"、"架构文档"、"代码导读"、"项目理解"、"深入理解项目"、"onboarding 文档"、"给新同事看的文档"时使用。要按用户给的格式写论文章节、项目梳理、重点问题、简历项目描述的，用 codegen-doc。 |
输出到项目的 docs/ 目录。核心约束：文档里的代码、类名、路径都必须来自真实文件，见 Phase 3。
| 用户表述 | 做什么 |
|---|---|
| 生成项目文档 / 新人文档 / 深入理解项目（没指定篇目） | 全部生成，Phase 1 → 2 → 3 → 4 |
| 帮我写架构文档 / 只要代码导读 / 写构建和调试 | 只写指定的几篇，读项目的范围可相应缩小 |
| 代码改了，更新文档 / 文档过期了 | 读 docs/.project-map.md，比对现在的代码，只重写受影响的篇目 |
docs/ 已经有内容时：先列出已有文件，问用户是覆盖、跳过已存在的、还是备份到 docs.bak/。不要直接盖掉。
不该用这个 skill 的情况：用户要的是论文章节、项目梳理、重点问题清单、简历项目描述——也就是给导师、评委、HR、领导看，且格式由对方指定的东西，用 codegen-doc。这个 skill 只管给新同事看、要能照着上手的文档。
记到 docs/.project-map.md。后面每一篇要用的路径、类名、代码，都从这个文件取。
分三步读，不要试图把所有源文件都读完：
怎么读、记成什么格式、什么时候可以停，见 reference/explore.md。把那份模板填完再进 Phase 2，其中术语表至少 5 条。
01_architecture.md → 架构：项目长什么样
02_philosophy.md → 思想：为什么这样设计
03_lang_concepts.md → 语言特性：读代码前的准备
04_code_walkthrough.md → 代码导读：跟着真实流程走一遍
05_runtime_model.md → 运行时：并发和生命周期
06_build_guide.md → 构建：怎么编译运行
07_integration_guide.md → 对接：怎么写新功能
08_debug_guide.md → 调试：出问题怎么查
09_design_conventions.md → 规范：怎么设计得更好
默认模板偏向 C++ 那类"要编译、有多线程、有进程间通信"的项目。前端、数据脚本、库这类项目必须按对照表替换或跳过对应篇目，见 reference/project-types.md。
编号固定，跳过的留空号，不要往前挪。 跳过 05 就是 01,02,03,04,06,07,08,09，原因见 project-types.md。
.project-map.md 里只有路径，不是代码原文。要贴哪段代码，先 Read 那个文件确认现在的内容。引用统一带位置：src/core/channel.cpp:120-135。
不这样做，新人会照着一个不存在的类名去搜索——比没有文档更糟。
刚接触项目的新同学。不假设他们了解项目背景，但假设有基础编程能力。
> 一句话说明这篇解决什么问题| 要表达什么 | 用什么 |
|---|---|
| 调用关系、时序、状态变化、类之间的继承 | Mermaid |
| 目录树、分层框图、内存布局 | ASCII |
ASCII 图宽度控制在 80 字符内，超了在 Typora 和网页里会折行错位。
每篇 300–600 行。不到 300 说明挖得不够深；超过 600 该拆节。避免一篇两千行、另一篇三十行。
同一个东西前后用同一个词，都按 .project-map.md 里的术语表来。在一篇里叫"通道"、另一篇里叫"管道"，是新人最容易卡住的地方。
不要生造名词。能用大白话说清的地方不要起一个新词让读者去记。
⚠️ 未验证各篇模板：reference/chapters-01-04.md、reference/chapters-05-09.md。
docs/README.md，列出所有篇目，说明不同目的该读哪几篇，跳过的篇目写明原因。模板见 reference/quality.md⚠️ 未验证、.project-map.md 里还剩什么没弄清。后两条最容易漏，但正是用户判断能不能直接把文档给新人看的依据