开发、测试与交付
把标准用在真实任务上，知道 Agent 应当产出什么证据。
新产品工程初始化
#在确认产品方向后建立可运行的工程起点。
能帮你完成什么
Core 指导 Agent 建立最小产品资料、技术决策、工程骨架、质量工具和版本记录，并验证最短用户流程。它是开发流程，不是安装插件时自动生成某种固定业务项目。
使用前
产品目标和第一版范围已有确认；关键架构、第三方服务和成本取舍已说明。
怎么使用
- 先确认产品资料和首个可验证用户流程。
- 讨论必要的技术选择，再建立与流程有关的工程结构。
- 运行基本启动、构建或测试，报告已完成部分与尚未接入的真实服务。
试着这样对 Agent 说
按已确认的报修 MVP 初始化工程。先列出必要技术选择，再实现能提交并查看一条报修记录的最小流程，给出运行与验证步骤。如何判断完成
- 可运行的工程骨架和最小演示流程。
- 必要的 README、质量入口、版本和变更记录。
适用边界
- 示例数据要标明；服务未接通时不能把占位界面当成真实完成。
技术选型与架构边界
#围绕当前需要做取舍，不为假设中的未来堆叠架构。
能帮你完成什么
Agent 从既有项目模式、当前规模和真实约束出发，解释候选技术的收益、代价与迁移成本。架构标准帮助明确模块职责、数据归属、API、错误处理和配置边界。
使用前
提供已有技术栈、部署约束、团队习惯和不能改变的接口。
怎么使用
- 让 Agent 先读现有结构，列出真正影响结果的选项。
- 确认高成本或难逆转的决定，再写入技术决策记录。
- 实现时检查新增抽象是否有当前需求、既有惯例或第二个真实用例。
试着这样对 Agent 说
这个项目已有 PostgreSQL 和后端服务。请评估报修通知如何接入，比较复用现有任务机制与新增队列的代价，推荐满足第一版需求的做法。如何判断完成
- 有依据的选择及明确模块、数据和失败边界。
- 需要保留的决定写进架构说明或技术决策记录。
适用边界
- 默认建议不能替代具体项目事实；外部服务费用和账户授权由用户决定。
界面、交互与前端实现
#从用户操作流程到完整状态和真实浏览器验证。
能帮你完成什么
前端标准覆盖信息层级、导航、组件、表单、文案、响应式、键盘可用性和数据状态。Agent 应解释用户看到什么、能做什么、操作结果在哪里，而不仅给出一张成功状态截图。
使用前
明确主要用户、设备和任务。已有网站应先复用它的组件和视觉规则。
怎么使用
- 确认关键页面和用户任务，必要时先展示可体验的方案。
- 实现加载、空数据、错误、权限拒绝和成功反馈。
- 在真实浏览器检查桌面/手机、键盘焦点、表单及长文本。
试着这样对 Agent 说
实现报修列表和详情页，沿用现有界面风格。覆盖空列表、加载失败、重复提交和无权限状态，并在桌面与手机上验证。如何判断完成
- 可操作的界面与明确的状态反馈。
- 浏览器验证结果及仍未覆盖的设备或场景。
适用边界
- Build 不自带通用视觉设计 SaaS；专用 Skill 需要按实际缺口另行选择。
API、数据、权限与服务集成
#把成功路径与失败、重试和权限一起设计。
能帮你完成什么
后端标准指导接口输入输出、数据库与迁移、认证授权、后台任务、第三方集成和日志。目标是让接口行为可验证、数据归属清楚，失败后能解释和恢复。
使用前
提供现有 API 和业务规则；测试需要的账号与权限通过项目既有安全渠道处理。
怎么使用
- 确认接口合同、角色权限、幂等与数据约束。
- 用最小可验证实现接通流程，覆盖依赖失败和重复请求。
- 验证成功、拒绝、超时与恢复，并说明迁移及上线边界。
试着这样对 Agent 说
为报修审批设计接口。员工只能查看自己的记录，管理员可以审批；请验证越权访问、重复审批和通知服务超时后的处理。如何判断完成
- 接口和权限行为有直接测试证据。
- 后台任务失败、重试和日志范围有说明。
适用边界
- 生产数据迁移、凭据变更和部署不是普通开发请求的隐含结果。
按风险选择测试与回归
#用测试证明功能目标，控制无关测试成本。
能帮你完成什么
Agent 根据影响范围选择开发保障等级和验证深度。低风险文案与样式改动不用自动升级为大型 QA 项目；权限、数据和并发问题需要更强证据。先做聚焦验证，相关实现冻结后再做必要的完整回归。
使用前
说明目标行为、改变的范围，以及无法运行的环境或依赖。
怎么使用
- 定义可观察完成条件，并选择真正证明它的验证。
- 执行相关单元、集成或浏览器测试，检查失败场景。
- 汇报通过项、未运行项和剩余风险；代码改变后只重跑受影响检查。
试着这样对 Agent 说
请验证报修审批功能。重点证明权限隔离、重复请求不会重复处理、失败后可恢复；列明实际执行和未执行的测试。如何判断完成
- 测试对应实际目标，而不是仅重复实现中的判断。
- 测试通过与尚未覆盖的风险分开说明。
适用边界
- 测试失败不能通过降低断言或删除场景来掩盖。
- 未运行的生产验证不能写成已经通过。
代码审查与独立 QA
#让已冻结的改动接受另一轮有范围的检查。
能帮你完成什么
审查关注可复现缺陷、用户影响、无关改动和未经证据支持的复杂度。复杂任务需要时安排独立 QA，主 Agent 验证发现、处理范围内问题，并复验修复，而不是原样转发审查意见。
使用前
给出审查目标、候选改动和验证记录。独立 Agent 是否可用取决于宿主工具。
怎么使用
- 明确“只审查”还是允许修复，以及这次不检查的范围。
- 候选实现和相关测试完成后提交给审查者。
- 按严重性处理可复现发现，保留未解决问题与限制。
试着这样对 Agent 说
请只审查本次报修权限改动，不修改代码。按严重程度列出可复现问题、受影响场景和定位；没有发现问题时说明检查范围及剩余风险。如何判断完成
- 有位置和复现场景的发现，或有边界的未发现问题结论。
- 修复任务有对应的直接验证结果。
适用边界
- 独立审查不是无限安全认证，理论上可想象的风险不能自动扩大已确认范围。
Git、版本与交付说明
#让改动可以追溯、审阅和回退。
能帮你完成什么
标准指导 Agent 先看已有改动，按职责提交，维护功能版本和 Change Log，写清 PR 的问题、结果、验证和风险。每段 diff 应能解释与任务目标的关系。
使用前
项目使用 Git；若仓库有自己的版本约定，先遵循项目约定。
怎么使用
- 修改前确认分支和未提交内容。
- 完成相关验证后审查 diff，仅提交本次已授权的文件。
- 为功能变化维护版本记录，发布前提供准确升级和回退说明。
试着这样对 Agent 说
请整理本次报修功能的提交和 PR 说明：先说明用户行为变化，再写验证与限制；不要混入我尚未提交的其他改动。如何判断完成
- 范围清楚的提交与可审阅的变更说明。
- 版本、发布产物和源代码之间可以追溯。
适用边界
- 本地提交不等于 GitHub 发布，GitHub 发布也不等于服务器部署。
- 远端推送、正式发布、标签和部署遵循当前任务的具体授权。