用途：帮助 Rails 开发者判断何时需要抽取代码、应选用哪种模式，以及何时保持简单内联。
主要能力：给出「Skinny Everything」原则下的职责划分——控制器负责编排（每个 action 约 10 行以内）、模型负责持久化（约 100 行以内）、服务承载业务逻辑、视图零逻辑。提供抽取阈值表，例如控制器 action 超出约 10 行业务逻辑抽为 service object，模型超过约 100 行抽取业务逻辑到服务、复杂查询到 query object，多表连接或条件查询抽为 query object，表单涉及多模型或自定义校验抽为 form object，展示格式化抽为 presenter，跨两个以上视图复用的 UI 抽为 ViewComponent，两个以上模型共享的窄而简单的行为抽为 concern，五个以上结构相同的实现可抽基类；一次性操作不必抽取。
使用方式：提供决策树，按「数据库查询、业务逻辑、共享行为、展示逻辑、校验」分类定位代码归属。区分 concern 与 service object 的适用边界、STI 与多态关联的选择、回调与显式调用的取舍（回调仅用于数据规范化，发邮件、入队后台任务、调用外部 API 等必须显式）。并附反模式清单，避免只包裹一次 update! 的服务、只有两个服务就建基类等过早抽象。
限制：内容为开发规范与判断指南，未提供安装命令或价格信息；文档引用的 @docs/rails-development-principles.md 未在本资料中给出。