用途：探索代码库中的架构摩擦点，识别重构机会，并以 GitHub issue RFC 的形式提出模块深化重构方案。核心方法是「Design It Twice」，即并行产出多个接口设计再以文字比较，给出有主见的推荐。
主要能力与流程：
- 摩擦驱动探索：用子智能体有机地浏览代码库，不套用死板启发式，记录实际遇到的摩擦，例如需在多个小文件间跳转才能理解一个概念、模块过浅导致接口复杂度接近实现、为可测试性抽出的纯函数却把真实缺陷藏在调用处、紧耦合模块在接缝处带来集成风险、难以测试的区域、修改时处处受阻的代码。作者强调摩擦本身就是信号。
- 呈现候选：以编号列表给出机会，每项含涉及的模块/概念集群、耦合原因（共享类型、调用模式、概念共ownership）、依赖类别（见 references/dependency-categories.md）、测试影响（现有覆盖及将替代的边界测试）。此时不提方案，先问用户选哪个。
- 框定问题空间：针对所选候选，写出新接口必须满足的约束、依赖、用于落地的粗略示意图，展示后立即进入下一步。
- Design It Twice：并行启动 3 个以上子智能体，各带不同设计约束与独立技术简报。Agent 1 最小化接口（最多 1-3 个入口）；Agent 2 最大化灵活性；Agent 3 为最常见调用方优化；Agent 4（如适用）用于跨边界依赖的端口与适配器。每个输出接口签名、调用示例、内部隐藏的复杂度、依赖策略和权衡。依次呈现后以文字比较并给出推荐，可提出混合方案。
- 创建 GitHub issue RFC：用户选定后用 gh issue create 创建，模板含问题、提议接口、依赖策略（进程内合并、本地可替换、端口与适配器、Mock）、测试策略（写新边界测试、删除冗余的浅模块单元测试、测试环境需求）、实现建议（不绑定当前文件路径）。
使用方式：作为技能调用，命令方面仅明确使用 gh issue create 创建 issue。
适用场景：需要梳理既有代码库架构、识别耦合与浅模块、规划重构并形成 RFC 的工程场景。
限制：具体触发方式、安装命令、支持的模型与环境要求，资料暂未提供。