تشغيل أي مهارة في Manus
بنقرة واحدة
بنقرة واحدة
تشغيل أي مهارة في Manus بنقرة واحدة
ابدأ الآن$pwd:
$ git log --oneline --stat
stars:٠
forks:٠
updated:١٠ مارس ٢٠٢٦ في ٠٦:٣٧
SKILL.md
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]