用途：该技能用于在组织代码分层与模块时应用“分离关注点”原则，适用于用户提出“这个函数做的事太多”“胖控制器”“关注点混杂”等场景。
主要能力：给出原则与规则，包括将策略与机制分离、数据访问与业务逻辑分离、输入解析与处理分离、编排与计算分离，以及用中间件、装饰器或拦截器统一处理认证、日志、限流和错误处理等横切关注点；同时列出反模式，如胖处理器、把业务逻辑写进数据库、领域代码引入基础设施、数据模型包含展示逻辑、业务逻辑中散落日志。
使用方式：应用前若存在 .agents/stack-context.md 应先读取，并按所检测技术栈的惯用模式应用；框架细节可借助 context7 MCP 或网络搜索，不要猜测。资料给出关注点纠缠与分离后的示例对比，以及代码审查清单，例如每个函数/模块是否只处理单一关注点、业务逻辑能否脱离基础设施测试、横切关注点是否统一由中间件处理、数据库或 API 格式变化时业务逻辑是否无需改动。
适用场景：需要降低修改风险、隔离故障、独立测试、并行开发和定位问题的代码库。
限制：分离不等于层数越多越好，简单 CRUD 或 5 行脚本过度分层会增加间接性；编排层天然需要了解领域层与数据层，目标是领域与数据互不知晓；微服务是极端的 SoC，会带来网络开销、分布式复杂性和运维成本，仅在组织或扩展收益足够时才拆分；与 KISS 存在张力。相关技能包括 solid、kiss、law-of-demeter。