用途：在编写后端逻辑前先确认输入校验、权限边界与数据写入规则，覆盖 API、服务层、数据库读写、鉴权权限、输入校验、事务与错误处理。触发场景包括 API、route、handler、server、auth、permission、drizzle、database、zod、Hono、Nuxt server routes 及后端 bug 修复。
工作流：第一步建立后端上下文，阅读目标路由、服务层、schema 与相关数据模型，确认项目使用 Hono、Nuxt server routes 还是自定义服务层。第二步明确接口契约，先定义输入、输出、错误语义与边界条件，并确认是否需要分页、排序、过滤、幂等或事务。第三步处理安全与数据一致性，先鉴权和权限检查再进入业务逻辑，输入校验优先于数据库操作，数据写入避免拼接查询、隐式权限绕过和部分写入。第四步实现与验证，给出语义清晰的错误处理，可测改动补齐测试或指出缺失测试点，高风险改动建议联动 security-guardian 与 test-engineer。
关注点：输入校验是否覆盖空值、非法值和边界值；鉴权是否在敏感操作前完成；数据访问是否参数化、可回滚、可追踪；错误是否对用户和日志分别提供恰当信息。
项目特化：Nuxt server routes 优先遵循 defineEventHandler 和 createError 惯用模式；已有 Zod、Drizzle ORM、TypeORM、Better-Auth 或权限中间件时优先复用；列表接口考虑 ApiResponse 风格、分页与可扩展过滤条件；权限检查优先放在 handler 或服务入口。
反模式：先写 SQL 或 ORM 调用再补校验与权限；控制器、业务逻辑、数据访问塞进一个文件；宽泛 catch 吞掉错误上下文；列表接口忽略分页与性能成本。
交付前检查：输入、输出和错误语义已明确；鉴权、权限和数据写入顺序正确；未引入字符串拼接查询或隐式越权；已说明需要的测试或后续验证。具体安装与调用方式暂未提供。