القائمة
实现和测试完成后，提交或合并前执行质量门禁。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | code-review-and-quality |
| description | 实现和测试完成后，提交或合并前执行质量门禁。 |
| when_to_use | 代码写完了 review、提交前检查、准备合并、质量审查。 |
AGENTS.md.specs/<需求名>/brief.md.specs/<需求名>/acceptance.feature.specs/<需求名>/technical_design.md.specs/<需求名>/implementation_report.md（若存在）git diffacceptance.feature 中的 Scenario，确认每条都有对应测试且通过。| 维度 | 检查要点 |
|---|---|
| Correctness | 是否满足所有 Scenario，异常路径是否可用 |
| Tests | 是否覆盖主流程、异常、边界、幂等，回归是否通过 |
| Architecture | 是否遵循 Maven 模块边界和组件复用约定 |
| Security | 认证、权限、敏感信息、内部接口防护 |
| Performance | 无界查询、N+1、同步阻塞、缓存误用 |
| Contracts | API、MySQL、MQ、Redis、OSS 文档是否已同步 |
Critical：阻塞合并（安全漏洞、数据风险、核心功能错误）Required：必须修复后再合并（需求偏差、关键测试缺失、明显架构违规）Suggestion：可优化项，不阻塞当前交付结论输出 APPROVE 或 REQUEST_CHANGES。
审查结束必须输出状态块：
PHASE: 最终审核与提交/合并
AI_REVIEW: PASS | FAIL
HUMAN_REVIEW: APPROVED | PENDING
NEXT_PHASE: 提交/合并 | BLOCKED
BLOCK_REASON: <阻塞原因；无则写 NONE>
判定规则：
Critical 或 Required 未关闭 → AI_REVIEW=FAILAPPROVE → AI_REVIEW=PASSAI_REVIEW=PASS 且 HUMAN_REVIEW=APPROVED 才允许进入提交/合并当用户要求基于某个需求、功能、改造、技术方案或项目实践生成博客文章时使用；必须结合用户给出的完整需求、当前项目真实实现逻辑、业务场景和代码/文档上下文做深入分析，输出通俗易懂且专业的 Markdown 博客到 `.specs/blog/《博客名称》.md`。
当修改 AGENTS.md/CLAUDE.md、docs/api、docs/internals、docs/ops，或代码变更影响这些文档记录的 API、MySQL schema、MQ 契约、Redis 缓存、OSS、错误码、模块架构、配置时，检查并同步更新对应文档，保证项目文档自动维护。
MySQL 建表与字段规范（面向 Java 管理端业务：用户、LLM 配置、数据集、知识文件、解析任务）。统一命名、索引、字段类型、时间戳、引擎字符集与注释要求，便于研发与 DBA 评审落地。
SpringDoc OpenAPI 3 中文注解生成工作流。为 Spring Boot Controller 和 DTO 生成符合企业级规范的中文 Swagger 注解（@Tag、@Operation、@Parameter、@Schema）。
brief.md 和 acceptance.feature 已冻结后，生成 .specs/<需求名>/technical_design.md；必须基于真实 Java 代码、组件文档和契约。
为 toLink-Service 的 HTTP 接口构建并执行全面的 curl 黑盒测试。分析待测接口与边界条件，必要时直连数据库或经接口造数，对本地已启动服务发起 curl 请求，断言响应，最终在对话中返回测试结果汇总。