用途：在编码会话中出现架构决策（而非单纯实现任务）时使用。与代码级 connascence 分析不同，本技能工作在服务层面，覆盖服务分解、数据所有权与 saga 领域。
主要能力：以 connascence（强度×局部性×程度）、数据所有权、可部署性、运行时行为与验证为锚点，给出情境化权衡建议；区分“拆开”与“合回”的适用条件；提供决策目录与 ADR 模板参考；用适应度函数把架构属性变成可验证的检查。
使用方式：先用一句话命名决策，包含当前系统形态、拟议变更与架构驱动力；从代码与运行时证据复现现状，优先当前仓库证据；在提议变更前映射静态与动态 connascence；判断是拆分还是合并；按需阅读 references/catalog.md 或 references/adrtemplate.md；用简短矩阵比较互斥且完备的选项；给出底线清晰的结论；实施最小一致改动，并补充守护架构属性的测试或适应度函数；最后报告改动、接受的权衡、新增验证与遗留风险。
输出契约：架构决策产出简洁决策说明，含 Decision、Context Evidence、Options Considered、Tradeoffs、Implementation Move、Validation、Consequences。写 ADR 时优先用仓库约定，否则用 docs/adr/YYYYMMDD_slug.md；辅助脚本 scripts/newadr.py 可起草文件，例如 python <skill_dir>/scripts/newadr.py --title "Split billing schema" --out-dir docs/adr --dry-run，脚本路径相对本技能而非仓库，可用 --help 查看全部参数。
适用场景：服务粒度、数据分解、复用、数据所有权、最终一致性、工作流、saga、契约与数据网格等决策。
限制与注意：不要因“更小更干净”就拆服务，先证明拆分优于合并；不要因工作流嘈杂就合并服务，先检查编排、异步消息或契约变更能否解决耦合；不要把数据库所有权当作实现细节；不要依赖通用架构建议，具体领域案例决定权衡。资料未提供具体收费、平台与效果信息。