Yeoman 工作流编排器

要解决的问题

当脚手架从「单个生成器跑到底」变成「一组子生成器分工协作」之后，编排层的复杂度会立刻浮现：谁先跑、谁依赖谁的输出、磁盘上的文件如何在多个生成器之间被安全改写、交互式提问又该如何串联而不让用户反复回答同一组问题。Yeoman 生态本身提供了 yo env、生成器依赖声明和 mem-fs-editor 等机制，但把它们组合成一个可复用的工作流，需要开发者自己处理大量胶水代码。这个技能的目标就是把这部分胶水逻辑收敛成一套可编排的流程。

它如何工作

核心能力集中在三件事上：

• 子生成器组合：把一个大的脚手架任务拆成多个职责清晰的 sub-generator，由编排器决定调用顺序，而不是把所有逻辑塞进一个庞大的生成器里。
• 文件转换：基于 mem-fs-editor 在内存文件系统上完成文件的读写与变换，生成器之间传递的是内存中的文件状态，而不是直接反复落盘后再读回来。
• 依赖管理：通过 yo env 维护生成器之间的依赖关系，让上游生成器的输出可以被下游正确识别。
• 交互链路：支持自定义 inquirer.js prompt 链，把多个问题按阶段组织，避免一次性抛出几十个字段让用户填写。

典型工作流大致是：先注册并解析各子生成器及其依赖，再依据依赖关系确定执行拓扑，随后按顺序驱动每个子生成器运行；子生成器在内存文件系统中产出或改写文件，并通过 yo env 暴露上下文给后续步骤；需要用户输入的环节通过 inquirer.js 提示链按阶段推进，最终把内存中的文件结果提交到磁盘。

适用边界与注意点

• 这套能力建立在 Yeoman 的运行模型之上，适合传统的生成器式脚手架场景。如果你的项目构建体系并不依赖 Yeoman，引入它反而可能增加不必要的运行时依赖。
• yo env 依赖全局或本地环境状态，在 CI 等无状态环境中使用时，需要确认环境变量与全局配置不会被意外污染。
• prompt 链本质上是同步交互流程，自动化场景下需要提前准备好非交互式的输入方式，否则流程会在等待输入时卡住。
• SKILL.md 中没有提供经过验证的安装与使用说明，上游实现和实际行为需要自行审阅后再用于敏感流程。
• mem-fs-editor 的提交行为决定了文件何时真正写入磁盘，理解 commit 时机对于避免半成品文件残留很关键。