القائمة
分析构建系统拓扑，识别独立构建单元、多产物风险和版本漂移隐患。
التثبيت باستخدام 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]