菜单
分析构建系统拓扑，识别独立构建单元、多产物风险和版本漂移隐患。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The final gatekeeper. Audits RFCs to reject over-engineering, unnecessary dependencies, and resume-driven development.
从模糊的用户需求中提取领域概念——实体、流程和"暗物质"（用户没说的）。基于 DDD（领域驱动设计）方法论。
使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档。产出按严重度分级的发现，关联到具体文档段落。
分析 Git 历史，发现"逻辑耦合"（总一起改的文件）和"热点"（高频修改的复杂模块）。基于 Adam Tornhill 的《Your Code as a Crime Scene》方法论。
综合 Scout 阶段所有分析（build-inspector, runtime-inspector, git-forensics, concept-modeler），生成决策就绪的系统风险报告。
分析运行时行为、进程边界和 IPC 机制，检测"协议漂移"风险和进程生命周期问题。
| name | build-inspector |
| description | 分析构建系统拓扑，识别独立构建单元、多产物风险和版本漂移隐患。 |
"地图不是领土。你看到的
Cargo.toml可能只是冰山一角。" —— 老测绘员箴言
静态分析看的是代码结构，而本技能看的是工程脚手架——那些决定了"软件如何从源代码变成可执行物"的规则。
[!IMPORTANT] 在执行任何分析之前，你必须调用
sequential thinking工具视情况进行 2—3 步推理。 思考内容例如：
- "这个项目使用什么构建系统？（Cargo? npm? Make?）"
- "我看到多个构建配置文件了吗？它们是独立的还是统一管理的？"
- "最终产物（exe, dll, bundle）是一起发布的吗？还是可以独立更新？"
识别构建边界 (Build Boundaries)。
老师傅核心定律: 如果两个东西是分开构建的，它们之间的任何"接口"都是一颗定时炸弹——因为可能发生版本漂移 (Version Skew)。
find_by_name(pattern="Cargo.toml|package.json|go.mod|pom.xml|build.gradle|requirements.txt|CMakeLists.txt")如果找到多个营地，你必须回答：
| 生态 | 检查项 | 老师傅判定 |
|---|---|---|
| Rust | 根 Cargo.toml 有 [workspace] 吗？成员都列在里面吗？ | 没有 -> 🔴 独立王国 |
| Node | 根 package.json 有 workspaces 字段吗？或使用 Lerna/Nx/Turborepo？ | 没有 -> 🔴 独立王国 |
| Go | 是否使用 go.work 统筹？ | 没有 -> 🟡 需进一步确认 |
[[bin]] in Cargo.toml -> 可执行文件。"bin" in package.json -> CLI 工具。cmd/ 目录在 Go 项目 -> 多个命令行工具。tauri.conf.json -> Tauri 桌面应用 (检查 externalBin 是否有 Sidecar)。| 模式 | 等级 | 老师傅建议 |
|---|---|---|
| 单一 Workspace | 🟢 | 版本一致性有保障。 |
| 多 Root + 共享 Workspace | 🟢 | 注意是否所有成员都在 workspace 内。 |
| 多 Root + 无 Workspace (Polyrepo) | 🔴 | Split-Brain。极易版本漂移。不同仓库的依赖版本可能冲突。 |
| Sidecar + 原子发布 | 🟢 | Sidecar 和主程序一起更新，风险可控。 |
| Sidecar + 非原子发布 | 🔴 | 高危！必须在 IPC 层实现版本握手。 |
[Monolith / Workspace / Polyrepo / Distributed-Local]