offboarding-auditor

name	offboarding-auditor
version	0.2.0
description	当程序员离职、转岗或交接项目时，审计其负责的代码与文档的「可继承性」——即新人能否在不联系原作者的前提下，独立把项目跑起来、看懂、改动、部署运维并接手未完成的工作。识别随人流失的隐性知识与 Bus Factor 风险，产出分级审计报告、可继承度评分和「离职前待补清单」。触发词：离职审计、交接审计、handover audit、项目继承、知识交接、bus factor、人走前检查。

项目继承审计 (Inheritance / Handover Auditor)

当一名程序员要离开他负责的项目时，本 skill 审计其代码与文档，回答一个核心问题：

换一个完全不认识原作者的新人来接手，他能不能独立把这件事干完？

不是看代码「写得好不好」，而是看「能不能被别人继承」。最大的敌人是隐性知识（tribal knowledge）——只活在原作者脑子里、会随他一起离开的东西。

何时使用

• 程序员离职 / 转岗 / 外包合同到期前的交接检查
• 评估某个项目的 Bus Factor（关键人风险）
• 接手一个「前任跑路」的项目，盘点缺什么
• 主动体检：万一某人明天就走，我们扛得住吗？

审计前先确认范围（Phase 0）

开始前，先和用户确认这几件事，没说清就主动问：

1. 审计对象：哪个/哪些项目？仓库路径、文档位置在哪？
2. 离职人：负责人是谁？还能找他几天？（决定「待补清单」是否来得及让他补）
3. 接手人画像：替岗的是资深还是新手？同团队还是全新的人？（决定文档要详细到什么程度）
4. 截止时间：什么时候必须交接完？
5. 报告语言：最终审计报告用中文还是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>

核心原则

1. 以接手人视角判断，不是以原作者「我觉得够清楚」判断。
2. 证据驱动：每个结论引用具体文件/行号或指出「缺失的事实」，不空谈。
3. 隐性知识优先：会随人离开的东西 > 公开能查到的东西。
4. 可执行 > 完美：待补清单要具体可分配，不要笼统说「文档需要改进」。
5. 离职是硬截止：优先抢救只有离职人知道的、且人走后再也问不到的知识。
6. 不评判人，只评估风险：报告对事不对人，目标是平滑交接而非追责。

配套资源

• 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.