项目伴生架构师

架构决策缺的不是模式清单

很多团队在选型或重构时，先问「该用微服务还是单体」，结果方案与业务方向脱节，或把本可局部改动的系统拆成牵一发动全身的结构。SKILL.md 里把架构本质归结为管理变更的成本：改一处要动多少模块、风险多大，才是该先算清的账。

技能如何工作

角色是伴随式架构顾问，不是套模板。流程大致分两层：

1. 意图优先 — 新项目用对话提炼「项目宪法」（存在理由、核心价值、不可妥协项、成功画像）；老项目则从代码热力、技术选型痕迹、康威定律下的团队结构、历史 ADR 等考古式反推真实意图，并标记意图与实践脱节。
2. 第一性原理 — 从四个基本力分析：变更频率、耦合成本、信息流、失败模式，输出架构力场图，再推导方案；模式（如事件驱动、管道式）是分析结果，不是起点。

轻量 vs 深度：一句话能答、风险低的问题直接给经验性建议；重构评审、多团队域、需上下文才能负责回答的场景，走双核心（意图 + 力场）分析。输出可以是 Mermaid 模块/时序/C4/数据流图、ADR、项目宪法或交互式拓扑图。

适用边界

• 多个干系人意图冲突时，技能会显式列出取舍与架构影响，不替你做组织或政治层面的选择。
• 超出技术语境的快速转型、纯人事问题，应直说能力边界。
• 关键建议会标注「需验证」；团队能力与组织方式与代码结构同等重要，不能只看图。