| name | neat-freak |
| description | 业务全景图项目专用的"项目文档同步 / 阶段发版"洁癖 skill，仅处理项目仓库内的文件 （docs/、CLAUDE.md、package.json）和 auto memory 一致性，不做单次会话沉淀（那是 /remember 的职责）。两种触发模式： (A) 文档同步——用户说 "/neat"、"/sync"、"同步文档"、"整理项目文档"、"对齐 docs" 时，对齐代码、CLAUDE.md、docs/规划/、auto memory 四层。 (B) 阶段发版——用户说 "PXX 收尾"、"PXX 完工"、"PXX 发版"、"bump 版本号"、 "/release"、"阶段收尾三件套" 时（必须带 PXX 编号或 bump/release 字样），额外强制 执行三件套：bump 版本号 + 更新 docs/规划/技术债务登记.md + 写 docs/规划/codex审查 记录/阶段X/PXX/99-收尾.md。阶段发版以版本号 bump 为锚——不 bump 不写 99；bump 必写 99。**与 /remember 的边界**：本 skill 不处理"沉淀本次会话"、"梳理记忆"、 "收尾会话"等单次会话级请求——那些一律走 /remember。fork 自 KKKKhazix/khazix-skills 并按本项目结构本地化。
|
洁癖（业务全景图本地版）
项目级 skill，跟仓库走（.claude/skills/neat-freak/）。所有路径以 e:\业务全景图\ 为根。
项目语境前提（不可绕过，所有判断都建立在此之上）
- 内网部署 / 172.16.0.138 / 单实例
- 最多 5 人并发 / < 100 用户总量
- 协作模式：codex 三件套（先审取舍 → 翻译报告 → 独立推荐）+ Claude 落地 + Playwright e2e
- 不要按通用 SaaS / 高并发场景做建议；遇到 codex / 自检产出"加 rate limit"、"加 CDN"、"加监控告警"这类建议，先用语境过滤一遍
归档命名约定速查
阶段 3 风格 3 是默认（详见下文「归档命名约定」段）：
NN-审查类型-[阶段标识]-[子阶段编号]-主题.md
新归档强制走此风格；阶段 2-5 Day 1/2/3/4 已存在归档不回溯。
关键概念：四层知识，四种受众
| 位置 | 受众 | 职责 |
|---|
auto memory（C:\Users\FY\.claude\projects\e-------\memory\） | 跨会话的 Claude 自己 | 协作偏好、踩坑、项目语境前提（不写代码能查到的事实） |
项目根 CLAUDE.md | 当前项目的 Claude（本会话 / 下次会话） | 项目约定、红线、目录速查、命令速查 |
docs/规划/（技术债务登记、多人协作-方案、codex审查记录/） | 未来的你 + 未来的 codex/Claude | 阶段决策快照、债务台账、流程模板 |
README.md | 第一次接触项目的人（团队新成员、外部接入） | 5 分钟速览：是什么 / 怎么跑 / 怎么部署 |
受众不混：CLAUDE.md 不抄 docs/ 全文，docs/ 不写"我记得上次……"那是记忆的事，README 不写阶段细节。
模式 A：文档同步（默认）
用户触发词：/neat、/sync、同步文档、整理项目文档、对齐 docs、审查文档一致性、新人能直接上手项目
不在触发范围：梳理记忆、沉淀会话、收尾一下（含糊版）→ 这些走 /remember，不走本 skill。本 skill 只处理项目仓库内的文档和 auto memory 一致性。
第一步：盘点现状（机械式枚举，不能跳过）
按顺序执行，先 ls 再判断：
- auto memory：
- 用 Glob：
C:\Users\FY\.claude\projects\e-------\memory\*.md
- 读
MEMORY.md，再逐个读它索引的所有 .md
- 项目根 markdown：
- 读
CLAUDE.md（若存在）、README.md、AGENTS.md（若存在）
- docs/规划/：
- Glob
docs/规划/*.md → 至少有 技术债务登记.md、多人协作-方案.md
- Glob
docs/规划/codex审查记录/**/*.md → 阶段产物全集
- 本次对话回顾：本会话产生了哪些事实？涉及哪些 PXX？
输出文件清单（内部用）：每个文件标 「评估过 / 要改 / 不用改」。漏一个就回去补。
第二步：识别变更——查 sync-matrix
完整映射见 references/sync-matrix.md。本项目高频场景速览：
- 新增 React Flow 节点 / hook 联动 →
CLAUDE.md + auto memory 是否需要新增"踩坑"条目（如又一次 useNodesState 锁外部 props）
- 新增 / 改 API 路由 →
CLAUDE.md 路由清单（若有）+ 当阶段 codex 审查文档
- 改 Playwright 流程 / 新增 e2e → auto memory
feedback_e2e_before_release.md 检查是否还准
- 改部署 / hook / 内网相关 → auto memory
feedback_windows_git_hooks.md 检查是否冲突，必要时更新
- codex 审查里发现新债务 →
docs/规划/技术债务登记.md 追加到"主动归档"
- 过期记忆 / 相对时间 → 改 auto memory，相对日期改成
2026-05-06 这种绝对日期
第三步：实际修改（用 Edit / Write，不只是描述）
顺序：先改 docs/（外部影响最大）→ 再改项目根 markdown → 最后整 auto memory。
编辑原则：
- 合并优于追加：旧条目过期就改它，不要再加一条
- 删除优于保留：完成的待办、推翻的决策、过期的上下文，删
- 绝对时间：永远
2026-05-06，不写"今天"、"最近"、"上周"
- 技术债务登记特殊规则：处理完的债务移到底部"已偿还"段，不要直接删（保留追溯性）
- auto memory 索引：
MEMORY.md 里只放一行链接，详情进单独文件；行数控制在 200 内
第四步：自检清单（必须逐项过）
第五步：变更摘要
## 同步完成
### auto memory
- 更新：xxx（原因）
- 新增：xxx
- 删除：xxx（原因）
### 项目文档
- CLAUDE.md — xxx
- docs/规划/技术债务登记.md — xxx
- docs/规划/codex审查记录/阶段X/PXX/0Y-xxx.md — xxx
### 未处理
- xxx（为什么没处理，需要用户确认的事）
只列有实际变更的条目。
模式 B：阶段发版（bump 版本号触发）
用户触发词：必须同时满足"阶段编号或 bump/release 字样"——PXX 收尾、PXX 完工、PXX 发版、bump 版本号 → X.Y.Z、/release、阶段收尾三件套、PXX 阶段做完了准备发版
不在触发范围：单纯的"收尾一下"、"做完了"、"沉淀这次会话"——那些含糊请求走 /remember，不走本 skill。如果用户没明说阶段编号或版本号，不要假设是 B 模式，先反问一句"是要 /remember 沉淀本次会话，还是要 /neat 同步项目文档？"
铁律：以版本号 bump 为锚——不 bump 不写 99；bump 必写 99。
前置确认（执行前问用户）
如果用户没明说，先确认这三件：
- 当前要收尾哪个阶段？（如 P3G、P3H）
- 版本号怎么 bump？（patch/minor/major + 具体目标版本）
- 这次发版的"主题一句话"是什么？（用于 commit message 和 99-收尾.md 标题）
任何一项不清楚，停下来问，不要自己猜版本号。
标准动作四件（从 A 升级）
- 执行模式 A 的第一/二/三步（盘点 / 识别变更 / 修改文档）
- bump 版本号：
- 改
package.json 的 version 字段
- 检查是否有
package-lock.json / pnpm-lock.yaml 需要同步（一般 npm i 一次即可，但不要自己跑——确认环境后由用户跑）
- 更新
docs/规划/技术债务登记.md：
- 本阶段新发现的债务追加到"主动归档"对应阶段段
- 本阶段已偿还的债务从"主动归档"移到"已偿还"
- 每条必须含：来源（哪份审查文档）、问题简述、建议阶段、严重度（🔴/🟡/⚪）
- 写
docs/规划/codex审查记录/阶段X/PXX/[可选 DayN-主题/]99-收尾.md：
- 用 references/99-收尾模板.md 的轻量骨架（500–1000 字）
- 不要重复 01/02/03 已经写过的 codex 审查内容，只做"指针 + 抽象"
- 文件名固定
99-收尾.md（避开 01/02/03/04… 审查编号撞车）
- 多 Day 切片阶段（如阶段 5 4 天 MVP）：99-收尾 写到对应
DayN-主题/ 子目录（如 阶段5/P5-合并算法/Day1-基建/99-收尾.md），避免每天 bump 都撞同一个文件名
- 单一主题阶段（如阶段 4）：99-收尾 直接写阶段目录根（如
阶段4/P4-设计取舍/99-收尾.md）
- 阶段整体收尾时（最后一天 Day N）：在
阶段X/PXX/README.md 写整阶段时间线表格 + 整阶段总收尾指针
阶段收尾自检清单（在 A 的清单基础上加这几项）
阶段收尾摘要（在 A 的摘要基础上加这段）
### 阶段收尾三件套
- package.json: 1.9.0 → 1.10.0
- 技术债务登记.md: 新增 N 条 / 移到已偿还 M 条
- docs/规划/codex审查记录/阶段X/PXX/[DayN-主题/]99-收尾.md: 已落盘 (xxx 字)
### 待用户确认
- 是否执行 git commit + push？（默认不自动）
- 是否需要更新 README 版本号或部署文档？
归档命名约定（阶段 3 风格 3 默认）
适用范围：docs/规划/codex审查记录/阶段X/PXX/[DayN-主题/] 下的所有审查归档文件名（不含 99-收尾.md 由模式 B 强制）。
命名格式
NN-审查类型-[阶段标识]-[子阶段编号]-主题.md
- NN：两位数字编号（01/02/03/.../09 ≥ 10 都接受），按归档时间序
- 审查类型（统一词，不简化）：
取舍审查 — 设计前的取舍点 codex 审（不是「取舍审」）代码审查 — 实施后的 codex 审（首轮）二审 / 三审 / 四审 — 后续轮次（保留"代码审查"前缀也可，如 04-二审-代码审查-XX.md）自审 — Claude 跳过 codex 跑的自审（满足 4 条免审条件时）范围审查 — 阶段开始前的范围/方向审门禁审查 — 进下个子阶段前的卡点审末尾审查 — 阶段收尾前的最后一轮 codex 门禁审拍板记录 — 用户对 codex 意见拍板后的决策汇总（不带「审查」后缀）切片设计审查 — 实施切片清单本身的设计审（Day 4 引入新词）
- 阶段标识：
PXX（阶段 3）/ DayN（阶段 5 多 Day 切片）/ 阶段4（单一主题）—— 始终带，便于跨阶段搜索
- 子阶段编号：
- 子阶段并行（同时实施多块，如 P3D-1/2/3、Day 2 阶段 A/B-1/B-2/B-3/B-4/C）→ 文件名带
子阶段编号，如 P3D-2-step1 / 阶段A / B-1
- 切片严格串行依赖（如 Day 3 D-1
4 / Day 4 F-1F-20）→ 整体审，不带切片编号（粒度太细），主题段写"切片 N 主题"或"X 切片整体审"
- 主题：1-5 个汉字短语，可带数字（如
5取舍 / 19判断点 / helper提取）
示例（阶段 3 风格）
✅ 01-取舍审查-P3E-批注-5取舍.md
✅ 02-代码审查-P3E-1-服务端API.md
✅ 03-代码审查-P3E-2-前端hook.md
✅ 04-二审-P3E-2-前端hook.md
✅ 05-三审-P3E-2-前端hook.md
✅ 09-自审-P3E-Playwright端到端验证.md
✅ 02-拍板记录-Day1.md
✅ 04-阶段A-代码审查-Day2-helper提取.md
✅ 03-切片设计审查-Day4-22切片.md
反例（不合规）
❌ 01-取舍审-客户端接合并响应.md —「取舍审」简化破坏统一
❌ 02-末尾审-首轮.md — 缺阶段标识 / 缺主题段
❌ 02-拍板记录.md — 缺阶段标识（Day 1 / Day 4 同名会撞）
❌ 03-审-框架与类型.md —「审」太短
❌ 02-公共画布产生路径决策-推荐方案Y.md — 审查类型不在标准词表里
历史归档不强制回溯
- 本规则适用于本次启动后的新归档
- 已存在的归档（阶段 2-5 Day 1/2/3 + Day 4 已写的 3 份）不要求 git mv 回溯——回溯成本高 + 改外部引用风险大
- 阶段 6+ 起统一走本风格
特殊情况
对话没有产生新事实：审查现有文档和记忆有没有过期 / 冲突 / 相对时间——审查本身就有价值，照样输出摘要。
记忆之间出现无法自动判断的矛盾：列在「未处理」让用户决定。这是唯一需要用户介入的情况，其他都自己拍板。
用户说"阶段做完了"但还没 bump：走模式 A，并在摘要末尾问一句"是否要顺便 bump 版本走收尾三件套？"。不要擅自 bump。
发现之前的同步漏了东西：修掉。不要说"那不是这次对话的事"——你就是这个项目的持续编辑，过去的漏洞也归你管。
docs 里出现了 README 里也有的内容：以 docs/ 为准，README 只保留"5 分钟速览"。
技术债务登记里有项目语境不适用的建议（比如 codex 之前没带语境时建议的"加监控告警"）：标注 (语境不适用，已搁置) 或直接删，附理由。
与其他 skills 的边界
- 这个 skill 不写代码，只整理文档 / 版本号 / 记忆
- 改代码归 Claude 主进程或专门的实现 skill
- codex 审查归 codex（你不模拟 codex 的审查产出，只引用它的结论）
参考
