mcpField
C
code-necromancer

code-necromancer

github.com/curiositech开发257176 次安装2 天前更新
代码仓库

关于 code-necromancer

为接手长期停滞或缺少文档的旧代码库的团队提供系统化流程。它分阶段开展仓库考察、恢复系统运行和现代化改造，并保持现有功能。

主要功能

  1. 01多仓库盘点
  2. 02依赖与架构梳理
  3. 03开发环境恢复
  4. 04集成测试规划
  5. 05安全与现代化路线图

适用场景

  1. 01接手缺少文档的代码仓库
  2. 02重启长期停滞的产品
  3. 03评估收购的代码库
  4. 04在保持功能一致的前提下改造旧系统

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/curiositech/some_claude_skills --skill code-necromancer

安装后在 Claude Code 中输入/code-necromancer确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

CHANGELOG.md
.claude-plugin/
plugin.json
references/
archaeology-guide.md
dependency-patterns.md
framework-detection.md
infrastructure-mapping.md
integration-test-patterns.md
scripts/
analyze-repo.sh
scan-repos.sh
templates/
archaeology-report.md
repo-inventory.json
resurrection-plan.md

详细介绍

代码复生师

标语：让沉睡的代码库重获新生

用于理解、复活和现代化遗留代码库的系统化框架。

何时启用

✅ 适用场景：

  • 接手一个包含 5 个以上仓库且没有文档的代码库
  • 让一个停滞 2 年以上的产品重获新生
  • 加入一家技术债务严重且部落知识流失的公司
  • 对收购的代码库进行尽职调查
  • 在不破坏现有功能的前提下对遗留系统进行现代化改造

❌ 不适用于：

  • 全新项目（建议从头开始）
  • 文档完善且仍在积极维护的代码库
  • 对维护中的系统进行简单的 Bug 修复

三个阶段

阶段 1：考古

目标：在触碰任何内容之前，绘制完整地图。

输出描述
repo-inventory.json所有仓库及其元数据、语言和活跃情况
dependency-graph.mmd仓库之间及外部依赖关系
architecture-diagram.mmd系统拓扑图
tech-stack-matrix.md各仓库使用的语言和框架版本
maturity-assessment.md代码质量、测试覆盖率和文档质量
missing-pieces.md缺失项、孤立仓库和损坏的集成

流程：盘点 → 深度扫描 → 交叉核对 → 可视化 → 评估

→ 详细技术请参阅 references/archaeology-guide.md。

阶段 2：复活

目标：让系统在开发环境中运行起来。

输出描述
dependency-audit.md过时的软件包、漏洞和破坏性变更
environment-variables.md所有必需的环境变量及默认值
secrets-needed.mdAPI 密钥、证书和 OAuth 凭据
infrastructure-status.md云资源，以及现存和已删除的资源
resurrection-blockers.md阻止系统启动的关键问题
integration-tests/验证组件能否正常工作和通信的测试

流程：审计依赖 → 梳理环境 → 检查基础设施 → 编写测试 → 记录阻碍项

→ 复活测试模式请参阅 references/integration-test-patterns.md。

阶段 3：焕新

目标：在保持功能对等的同时进行现代化改造。

输出描述
security-recommendations.md漏洞修复和合规建议
modernization-roadmap.md按优先级排列的升级计划及工作量估算
architecture-improvements.md可扩展性、性能和可维护性

流程：安全优先 → 基础设施（容器化、CI/CD）→ 代码质量 → 架构

关键命令

# List all repos in org
gh repo list ORG --limit 1000 --json name,primaryLanguage,pushedAt

# Dependency analysis
npm audit && npm outdated      # Node.js
pip list --outdated && safety check  # Python
go mod graph                    # Go

# Find env vars in code
grep -rn 'process\.env\|os\.environ' --include="*.js" --include="*.py"

→ 框架／技术栈识别请参阅 references/framework-detection.md。 → 云资源发现请参阅 references/infrastructure-mapping.md。 → 依赖检测请参阅 references/dependency-patterns.md。

应避免的反模式

1. 过早复活

表现：还没读任何代码就运行 npm install 问题：同一个 Bug 会修 5 次；依赖项已经发生变化 解决方法：先完成考古；先理解，再动手

2. 范围蔓延

表现：「既然都在这里了，不如顺便重构一下」 问题：范围无限扩大；系统始终无法真正复活 解决方法：严格划分阶段；重构属于阶段 3

3. 一次性大规模更新

表现：在一个提交中更新所有依赖项 问题：一旦出问题，就不知道原因是什么 解决方法：逐步更新；每次更新后都进行测试

4. 忽略测试

表现：「能运行就发布」 问题：回归问题层出不穷；没有变更基线 解决方法：边进行边编写复活测试，以此证明进展

5. 未记录变更

表现：「我修好了，但忘了改了什么」 问题：部落知识再次流失；6 个月后，下一个接手的人还是你 解决方法：记录你学到和改动的一切

6. 轻信过时文档

表现：遵循 2019 年的 README 问题所在：API 会变化，服务会被弃用 解决方法：核实每条说明；文档也会骗人

成功指标

满足以下条件时，考古阶段完成：
  • 所有仓库均已编目并附带元数据
  • 已绘制依赖关系图
  • 已创建架构图
  • 已识别核心仓库与外围仓库
  • 已记录缺失部分
满足以下条件时，复活阶段完成：
  • 所有服务均可在本地启动
  • 服务之间可以相互通信
  • 集成测试通过
  • 至少有一个完整的用户流程可正常运行
满足以下条件时，焕新阶段完成：
  • 没有严重的安全漏洞
  • 所有依赖都较为新
  • CI/CD 流水线正常运行
  • 文档保持最新
  • 团队能够开发新功能

参考资料

→ references/archaeology-guide.md - 深入代码考古技巧 → references/dependency-patterns.md - 跨生态系统的依赖检测 → references/framework-detection.md - 框架/技术栈识别 → references/infrastructure-mapping.md - 云资源发现 → references/integration-test-patterns.md - 复活阶段的测试模式

模板

→ templates/repo-inventory.json - 仓库目录 → templates/archaeology-report.md - 阶段 1 的产出 → templates/resurrection-plan.md - 阶段 2 的计划 → templates/rejuvenation-roadmap.md - 阶段 3 的路线图

评论

支持 Markdown