用途：当需要为 PostgreSQL + Hotwire + Tailwind 的 Rails 项目编写新代码时，应用该技能中的栈约定；做通用架构评审时不用它。
主要能力与默认约定：Rails MVC 保持控制器瘦身，将非平凡业务逻辑移入服务对象；PostgreSQL 用 includes 避免 N+1，用数据库约束保证完整性；Hotwire 优先用 Turbo Frames/Streams，仅当 Turbo 无法处理交互时才引入 Stimulus；Tailwind 在视图中使用工具类，重复 UI 抽成 partial/组件；涉及访问控制资源的每个动作都要加 Devise 认证与 Pundit 授权。若项目使用 linter，以 linter 为格式准绳。
必要用法（TDD 硬性门禁）：所有新代码须先写并验证测试再实现，按层循环：写 spec 文件（展示完整文件内容，不只给路径）→ 运行 bundle exec rspec spec/[path]_spec.rb 并确认失败（观察 RED 输出）→ 写实现代码 → 重跑同一命令并确认通过（观察 GREEN 输出）→ 必要时在保持测试通过的前提下重构。测试命令必须通过 shell/终端工具真实执行，不得伪造或模拟输出；需粘贴实际观察到的输出；若环境不支持运行测试，应停止并告知用户，不得在未验证 RED 的情况下继续实现。
功能开发顺序：模型（校验、关联、作用域，循环中使用关联时用 includes 预加载）→ 服务对象（从控制器抽出非平凡逻辑，控制器通过 .call 委派并接收结果哈希）→ 控制器（保持动作精简，以 turbo_stream 和 html 格式响应）→ 视图/Turbo 接线（用 <turbo-frame> 包裹动态区域，从控制器广播 turbo_stream 响应）→ Stimulus（Turbo 无法处理客户端交互时才加控制器）→ Tailwind（应用工具类，重复模式抽为 partial 或 Stimulus target）。最终产物需包含“层隔离”一节，为 model/query、service、controller/request、view/Turbo、Stimulus、Tailwind 指明聚焦的 spec 或检查；未改动的层标注“not applicable”，不得静默省略。
输出风格要求按序包含：栈决策、实现前的测试优先证明、层隔离、分层实现、性能与安全检查（防 N+1、授权策略使用、不安全参数/内容处理）。扩展资源如 assets/snippets/eager_loading.rb、n_plus_one_fix_example.rb、service_object.rb、turbo_frame.html.erb、stimulus_controller.js、tailwind_component.html.erb 仅在需要对应内容时加载。可与 apply-code-conventions、code-review、create-service-object、write-tests、review-architecture 等技能衔接。
限制：资料未提供具体版本号、安装命令之外的配置、价格或平台支持信息，暂未提供。