AI工厂验证Skill ai-factory.verify

---

name: ai-factory.verify description: >- 根据计划验证完成的实现。检查所有任务是否完全实现， 没有遗漏，代码编译，测试通过，质量标准满足。 在 “/ai-factory.implement” 完成后使用，或当用户说 “verify”、“check work”、“did we miss anything” 时使用。 argument-hint: “[–strict]” allowed-tools: Read Edit Glob Grep Bash(git *) Bash(npm *) Bash(npx *) Bash(yarn *) Bash(pnpm *) Bash(bun *) Bash(go *) Bash(python *) Bash(php *) Bash(composer *) Bash(cargo *) Bash(make *) Bash(task *) Bash(just *) Bash(mage *) TaskList TaskGet AskUserQuestion Questions disable-model-invocation: true metadata: author: AI Factory version: “1.0” category: quality

验证 — 实施后质量检查

验证完成的实现是否与计划匹配，没有遗漏，代码生产就绪。

此技能是可选的 — 在 /ai-factory.implement 完成所有任务后调用，或随时手动调用。

---

步骤 0：加载上下文

0.1 查找计划文件

与 /ai-factory.implement 相同的逻辑：

1. .ai-factory/PLAN.md 存在？ → 使用它
2. 无 PLAN.md → 检查当前 git 分支：
   git branch --show-current
   → 查找 .ai-factory/features/<branch-name>.md

如果未找到计划文件：

AskUserQuestion: 未找到计划文件。我应该验证什么？

选项：
1. 验证最新提交 — 检查最新提交的完整性
2. 验证分支差异 — 比较当前分支与主分支
3. 取消

0.2 读取计划与任务

• 读取计划文件以了解预期实现的内容
• TaskList → 获取所有任务及其状态
• 读取 .ai-factory/DESCRIPTION.md 获取项目上下文（技术栈、约定）

0.3 收集更改的文件

# 在此功能/计划期间更改的所有文件
git diff --name-only main...HEAD
# 如果在主分支，检查最近提交
git diff --name-only HEAD~$(number_of_tasks)..HEAD

存储为 CHANGED_FILES。

---

步骤 1：任务完成审核

遍历计划中的每个任务，验证其是否实际实现。

对于每个任务：

1.1 读取任务描述

TaskGet(taskId) → 获取完整描述、要求、验收标准

1.2 验证实现存在

对于任务描述中的每个要求：

• 使用 Glob 和 Grep 查找实现它的代码
• 读取相关文件以确认实现完整
• 检查实现是否符合描述，而不仅仅是“写了些东西”

1.3 构建检查清单

对于每个任务，生成验证结果：

✅ 任务 #1：创建用户模型 — 完成
   - 用户模型创建于 src/models/user.ts
   - 所有字段存在（id、email、name、createdAt、updatedAt）
   - 添加了验证装饰器

⚠️ 任务 #3：添加密码重置端点 — 部分完成
   - 端点创建于 src/api/auth/reset.ts
   - 缺失：邮件发送逻辑（任务提到 SendGrid 集成）
   - 缺失：令牌过期检查

❌ 任务 #5：添加速率限制 — 未找到
   - 未检测到速率限制中间件
   - 依赖项中无速率限制相关包

状态：

• ✅ 完成 — 所有要求在代码中已验证
• ⚠️ 部分完成 — 部分要求实现，部分缺失
• ❌ 未找到 — 实现未检测到
• ⏭️ 跳过 — 任务在实施期间被用户有意跳过

---

步骤 2：代码质量验证

2.1 构建与编译检查

检测构建系统并验证项目编译：

检测	命令
go.mod	go build ./...
tsconfig.json	npx tsc --noEmit
package.json 带有 build 脚本	npm run build（或 pnpm/yarn/bun）
pyproject.toml	python -m py_compile 在更改的文件上
Cargo.toml	cargo check
composer.json	composer validate

如果构建失败 → 报告错误，包含文件:行引用。

2.2 测试检查

如果项目有测试且测试是计划的一部分：

检测	命令
jest.config.* 或 vitest	npm test
pytest	pytest
go test	go test ./...
phpunit.xml*	./vendor/bin/phpunit
Cargo.toml	cargo test

如果测试失败 → 报告哪些测试失败以及是否与实现的任务相关。

如果无测试存在或测试在计划中明确跳过 → 记录但不视为失败。

2.3 Lint 检查

如果配置了 linter：

检测	命令
eslint.config.* / .eslintrc*	npx eslint [更改的文件]
.golangci.yml	golangci-lint run ./...
ruff 在 pyproject.toml 中	ruff check [更改的文件]
.php-cs-fixer*	./vendor/bin/php-cs-fixer fix --dry-run --diff

仅 lint 更改的文件以保持输出聚焦。

2.4 导入与依赖检查

• 验证没有留下未使用的导入
• 检查任务中提到的新依赖是否实际添加（package.json、go.mod、requirements.txt、composer.json）
• 检查缺失的依赖（引用未在依赖文件中的包的导入）

---

步骤 3：一致性检查

3.1 计划与代码差异

检查计划与构建内容之间的不一致：

• 命名：变量/函数/端点名称是否符合计划指定？
• 文件位置：文件是否在计划指定的位置？
• API 合约：端点路径、请求/响应形状是否符合计划？

3.2 剩余工件

搜索应已清理的内容：

在 CHANGED_FILES 中 Grep：TODO|FIXME|HACK|XXX|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

报告任何找到的内容 — 可能是有意的，但标记它们。

3.3 配置与环境

检查实现是否引入了新的配置要求：

• 引用了新环境变量但未文档化
• 代码中提到新配置文件但未创建
• 创建了数据库迁移但未在 README/文档中记录

在 CHANGED_FILES 中 Grep：process\.env\.|os\.Getenv\(|os\.environ|env\(|getenv\(|config\(

与 .env.example、.env.local、README 或文档交叉参考，确保它们有文档。

3.4 DESCRIPTION.md 同步

检查 .ai-factory/DESCRIPTION.md 是否反映当前状态：

• 实现期间添加的新依赖/库 → 应列出
• 架构更改 → 应反映
• 新集成 → 应文档化

---

步骤 4：验证报告

4.1 显示结果

## 验证报告

### 任务完成：7/8 (87%)
| # | 任务 | 状态 | 备注 |
|---|------|--------|-------|
| 1 | 创建用户模型 | ✅ 完成 | |
| 2 | 添加注册端点 | ✅ 完成 | |
| 3 | 添加密码重置 | ⚠️ 部分完成 | 缺失：邮件发送 |
| 4 | 添加 JWT 认证中间件 | ✅ 完成 | |
| 5 | 添加速率限制 | ✅ 完成 | |
| 6 | 添加输入验证 | ✅ 完成 | |
| 7 | 添加错误处理 | ✅ 完成 | |
| 8 | 更新 API 文档 | ❌ 未找到 | 在 docs/ 中无更改 |

### 代码质量
- 构建：✅ 通过
- 测试：✅ 42 通过，0 失败
- Lint：⚠️ 2 个警告在 src/api/auth/reset.ts

### 发现的问题
1. **任务 #3 不完整** — 密码重置端点已创建但邮件发送未实现（缺失 SendGrid 集成）
2. **任务 #8 未完成** — 尽管计划要求，API 文档未更新
3. **找到 2 个 TODO** — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
4. **新环境变量未文档化** — `SENDGRID_API_KEY` 被引用但不在 .env.example 中

### 无问题
- 所有导入已解析
- 无未使用依赖
- DESCRIPTION.md 最新
- 无剩余调试日志

4.2 确定整体状态

• 全部通过 — 所有已验证，无问题
• 小问题 — 可快速修复的小缺口
• 显著缺口 — 任务缺失或部分完成，需要重新实现

4.3 对问题采取行动

如果发现问题：

AskUserQuestion: 验证发现问题。我们应该做什么？

选项：
1. 立即修复 — 立即解决所有问题
2. 仅修复关键 — 修复不完整任务，跳过警告
3. 接受现状 — 标记所有为完成，继续

如果“立即修复”或“仅修复关键”：

• 对于每个不完整/部分任务 — 直接实现缺失部分（遵循与 /ai-factory.implement 相同的实施规则）
• 对于 TODO/调试工件 — 清理它们
• 对于未文档化配置 — 更新 .env.example 和文档
• 修复后，重新运行相关验证检查以确认

如果“接受现状”：

• 在计划文件中以注释记录接受的问题
• 继续步骤 5

---

步骤 5：建议后续技能

验证完成后（全部通过或问题已接受），建议可选的后续步骤：

## 验证完成

所有任务已验证。建议下一步：

1. 🔒 /ai-factory.security-checklist — 对新代码运行安全审计
2. 👀 /ai-factory.review — 对实现进行代码审查
3. 💾 /ai-factory.commit — 提交更改

您想运行哪个？（或跳过所有）

AskUserQuestion: 运行额外检查？

选项：
1. 安全检查 — 在更改的文件上运行 /ai-factory.security-checklist
2. 代码审查 — 对实现运行 /ai-factory.review
3. 两者 — 先运行安全检查，然后代码审查
4. 跳过 — 继续提交

如果选择安全检查 → 建议调用 /ai-factory.security-checklist 如果选择代码审查 → 建议调用 /ai-factory.review 如果选择两者 → 建议先安全，后审查 如果跳过 → 建议 /ai-factory.commit

上下文清理

验证后上下文较重。所有结果已保存 — 建议释放空间：

AskUserQuestion: 在继续前释放上下文？

选项：
1. /clear — 完全重置（推荐）
2. /compact — 压缩历史
3. 继续现状

---

严格模式

当以 --strict 调用时：

/ai-factory.verify --strict

• 所有任务必须完成 — 不允许部分或跳过
• 构建必须通过 — 如果构建失败，验证失败
• 测试必须通过 — 如果任何测试失败，验证失败（严格模式下测试是必需的）
• Lint 必须通过 — 零警告，零错误
• 更改的文件中无 TODO/FIXME
• 无未文档化环境变量

严格模式建议在合并到主分支或创建拉取请求前使用。

---

使用方式

实施后（自动建议）

/ai-factory.verify

合并前的严格模式

/ai-factory.verify --strict

独立使用（无计划，验证分支差异）

/ai-factory.verify
→ 未找到计划 → 验证与主分支的差异