| name | offboarding-auditor |
| version | 0.2.0 |
| description | 当程序员离职、转岗或交接项目时，审计其负责的代码与文档的「可继承性」——即新人能否在不联系原作者的前提下，独立把项目跑起来、看懂、改动、部署运维并接手未完成的工作。识别随人流失的隐性知识与 Bus Factor 风险，产出分级审计报告、可继承度评分和「离职前待补清单」。触发词：离职审计、交接审计、handover audit、项目继承、知识交接、bus factor、人走前检查。 |
项目继承审计 (Inheritance / Handover Auditor)
当一名程序员要离开他负责的项目时，本 skill 审计其代码与文档，回答一个核心问题：
换一个完全不认识原作者的新人来接手，他能不能独立把这件事干完？
不是看代码「写得好不好」，而是看「能不能被别人继承」。最大的敌人是隐性知识（tribal knowledge）——只活在原作者脑子里、会随他一起离开的东西。
何时使用
- 程序员离职 / 转岗 / 外包合同到期前的交接检查
- 评估某个项目的 Bus Factor（关键人风险）
- 接手一个「前任跑路」的项目，盘点缺什么
- 主动体检：万一某人明天就走，我们扛得住吗？
审计前先确认范围（Phase 0）
开始前，先和用户确认这几件事，没说清就主动问：
- 审计对象：哪个/哪些项目？仓库路径、文档位置在哪？
- 离职人：负责人是谁？还能找他几天？（决定「待补清单」是否来得及让他补）
- 接手人画像：替岗的是资深还是新手？同团队还是全新的人？（决定文档要详细到什么程度）
- 截止时间：什么时候必须交接完？
- 报告语言：最终审计报告用中文还是English？（不主动说明时，跟随用户当前对话语言；记下选择，Phase 4 全程用这一种语言输出报告）
关键判断基准始终是「接手人」的视角，不是「原作者觉得够清楚了」。
审计流程
Phase 1 — 盘点 (Inventory)
先建立全貌，再深入。优先直接运行配套脚本一键采集客观信号：
bash scripts/inventory.sh <目标仓库路径> > inventory.md
脚本会自动盘出：规模结构、文档清单、Bus Factor（单一作者文件）、未完成工作（未合并分支/未推送提交）、隐性知识信号（TODO/HACK/「别动」等）、依赖与 CI 清单、密钥与个人账号风险（邮箱/绑定）、测试覆盖原料。它只采集事实、不下结论——结论留到 Phase 2。
脚本不可用或需补充时，手动用 fd / rg / git 摸清同样的几类信息：
- 仓库结构、主要模块、代码量级；现有文档清单（README、docs/、ADR）
- Git 状态：未合并分支、未推送提交、
git shortlog -sn 看作者集中度、谁是某模块唯一改动者
- 外部依赖（package.json / requirements / go.mod / Dockerfile / CI / .env.example）
- 隐性知识信号：
rg -i "TODO|FIXME|HACK|XXX|临时|先这样|别动|magic|workaround"
Phase 2 — 逐维度审计 (Audit)
按下面 10 个维度逐项核查，每条结论都要有证据（引用文件/行号/缺失的事实）。不要凭空打分。
| # | 维度 | 核心问题 | 重点检查 |
|---|
| 1 | 可运行性 | 新人能从零跑起来吗？ | README 启动步骤是否完整可复现；依赖版本是否锁定；环境变量/密钥从哪获取有没有写；本地一键启动 |
| 2 | 可理解性 | 新人能看懂吗？ | 架构图/模块职责；数据流；关键设计决策的「为什么」（最易丢失）；命名是否自解释 |
| 3 | 可维护性 | 新人敢改吗？ | 复杂逻辑有无注释；技术债是否标注；有没有「不敢动」的黑盒；死代码 |
| 4 | 可测试性 | 改完怎么验证？ | 测试覆盖关键路径；怎么跑测试有没有写；CI 是否能复现 |
| 5 | 隐性知识 ⚠️ | 哪些只在脑子里？ | magic number 来源；手工运维步骤；第三方/外部系统的坑；未文档化的约定 |
| 6 | 依赖与权限归属 ⚠️ | 离职会断哪些东西？ | API key / 域名 / 证书 / 云账号 / 第三方服务是否绑在个人邮箱或个人账号上；谁有权限；续费归属 |
| 7 | 运维与部署 | 新人能发版吗？ | 部署流程；回滚步骤；监控/告警在哪看；on-call 知识；线上配置 |
| 8 | 未完成工作 | 手头活到哪了？ | 进行中分支/未合并 PR；已知 bug；计划中的重构；半成品功能的状态 |
| 9 | 业务上下文 | 这东西为谁做的？ | 项目目标；相关方/对接人；需求来源；历史沟通在哪 |
| 10 | Bus Factor / 联系人 | 还有谁懂？ | 除离职人外是否还有人了解；外部供应商联系方式；唯一知情人的知识点 |
⚠️ = 离职场景下最高危、最易被忽略的维度，重点查。
Phase 3 — 分级与评分 (Triage & Score)
严重度分级（按「对新人接手的阻断程度」）：
- 🔴 阻断 (Blocker)：缺了它新人根本无法接手（如：唯一的部署密钥绑在个人账号、没人能跑起来）
- 🟠 高 (High)：能接手但会踩大坑、显著拖慢（如：核心模块零文档、关键决策无记录）
- 🟡 中 (Medium)：能查能问出来，但浪费时间（如：环境配置文档过时）
- ⚪ 低 (Low)：体验问题，不影响接手（如：注释少但代码自解释）
可继承度评分（0–100）：基于 10 维度加权，⚠️ 维度（5、6）权重更高。给出一个总分和「能否安全交接」的明确结论：
- 85+ ✅ 可安全交接
- 60–84 ⚠️ 可交接但需先补齐高危项
- <60 ❌ 不可交接，存在阻断项
Phase 4 — 产出报告与待补清单 (Report)
输出两样东西：
1) 审计报告（见下方模板）
2) 离职前待补清单——这是本 skill 最有价值的产物。趁原作者还在，列出具体、可执行、可分配的补救项，每项标注：做什么 / 为什么(对应哪个风险) / 严重度 / 预计工作量。优先级：先补 🔴 阻断项和 ⚠️ 高危维度。
区分「现在必须让离职人补」和「以后新人慢慢完善」——离职人独有的知识优先，公开可查的留给新人。
报告模板
语言跟随 Phase 0 第 5 项的选择：用户选中文 → 用下方【中文模板】并参照 references/example-report.zh.md；选 English → 用下方【English template】并参照 references/example-report.en.md。整份报告（含小标题、表头、判定词）统一用所选语言，不要中英混排。
中文模板
# 项目继承审计报告：<项目名>
- 审计对象：<仓库/路径>
- 离职负责人：<姓名> ｜ 接手人画像：<资深/新手>
- 审计日期：<日期>
## 结论
- **可继承度评分：<0-100> / 100**
- **交接判定：✅ 可安全交接 / ⚠️ 补齐后可交接 / ❌ 不可交接**
- 一句话总结：<最大的风险是什么>
## 阻断项 🔴（不解决无法交接）
- [ ] <问题> — 证据：<file:line / 缺失事实> — 待补：<动作>
## 高危项 🟠
- [ ] ...
## 维度评分
| 维度 | 评分 | 关键发现 |
|------|------|---------|
| 可运行性 | x/10 | ... |
| ...（10 个维度）| | |
## 离职前待补清单（按优先级）
| 优先级 | 待补项 | 对应风险 | 负责人 | 预计工作量 |
|--------|--------|---------|--------|-----------|
| 🔴 | ... | ... | 离职人 | 2h |
## 留给新人的「上手 30 分钟」入口
<如果文档够好，列出新人该先读哪几个文件；如果不够，这一节本身就是缺口>
English template
# Inheritance Audit Report: <project>
- Scope: <repo / path>
- Departing owner: <name> ｜ Successor profile: <senior / junior>
- Audit date: <date>
## Verdict
- **Inheritability score: <0-100> / 100**
- **Handover verdict: ✅ Safe to hand over / ⚠️ Hand over after fixes / ❌ Not ready**
- One-liner: <the single biggest risk>
## Blockers 🔴 (handover impossible until resolved)
- [ ] <issue> — Evidence: <file:line / missing fact> — Fix: <action>
## High 🟠
- [ ] ...
## Dimension scores
| Dimension | Score | Key finding |
|-----------|-------|-------------|
| Runnability | x/10 | ... |
| ...(10 dimensions)| | |
## Pre-departure fix-list (by priority)
| Priority | Item | Risk addressed | Owner | Est. effort |
|----------|------|----------------|-------|-------------|
| 🔴 | ... | ... | departing eng | 2h |
## "First 30 minutes" entry point for the successor
<If docs are good enough, list which files to read first; if not, this section is itself the gap>
核心原则
- 以接手人视角判断，不是以原作者「我觉得够清楚」判断。
- 证据驱动：每个结论引用具体文件/行号或指出「缺失的事实」，不空谈。
- 隐性知识优先：会随人离开的东西 > 公开能查到的东西。
- 可执行 > 完美：待补清单要具体可分配，不要笼统说「文档需要改进」。
- 离职是硬截止：优先抢救只有离职人知道的、且人走后再也问不到的知识。
- 不评判人，只评估风险：报告对事不对人，目标是平滑交接而非追责。
配套资源
scripts/inventory.sh — Phase 1 自动盘点脚本（bash + git，rg/fd 可选）。一键采集 Bus Factor、隐性知识信号、密钥与个人账号风险等客观事实。references/example-report.zh.md — 中文样板审计报告，供生成中文报告时参照风格与证据颗粒度。references/example-report.en.md — English sample audit report, used as reference when the chosen report language is English.
