用途：静态分析工程脚手架，判断软件如何从源码变成可执行物，识别构建边界与版本漂移风险。核心定律是：分开构建的两个东西之间的接口都是定时炸弹。
主要能力：定位构建配置（Cargo.toml、package.json、go.mod、pom.xml、build.gradle、requirements.txt、CMakeLists.txt）；判断是否统一指挥，如 Rust 根 Cargo.toml 是否有 [workspace]、Node 是否有 workspaces 或 Lerna/Nx/Turborepo、Go 是否用 go.work；追踪最终产物，如 [[bin]]、package.json 的 bin、Go 的 cmd/ 目录、tauri.conf.json 的 externalBin；输出构建根、拓扑（Monolith/Workspace/Polyrepo/Distributed-Local）、产物清单、Sidecar 发布策略与风险标签。
使用方式：执行前需调用 sequential thinking 工具进行 2—3 步推理，判断项目构建系统、是否存在多个独立配置、产物是否一起发布。随后用 find_by_name(pattern="Cargo.toml|package.json|go.mod|pom.xml|build.gradle|requirements.txt|CMakeLists.txt") 定位构建配置，再按生态检查统一管理情况。
适用场景：多仓库或伪 Monorepo 项目、含 Sidecar/外挂二进制的桌面应用、需要评估版本漂移与依赖冲突风险的工程。
限制：资料未提供具体安装命令、收费方式、平台支持与效果数据；分析依赖构建配置文件的存在与可读性，无法覆盖运行时行为。