ai-factory.verify

用途

ai-factory.verify 用于在实现完成后进行质量校验：确认已完成的实现与计划一致、没有遗漏内容，并且代码达到生产就绪状态。该技能是可选技能，通常在实现类技能完成所有任务后调用，也可以在任何时间手动调用。

主要能力

步骤 0：加载上下文

先定位计划文件：若 .ai-factory/PLAN.md 存在则使用它；若不存在，则通过 git branch --show-current 检查当前 git 分支，并查找 .ai-factory/features/<branch-name>.md。若找不到计划文件，会询问用户要校验什么，选项包括：校验最后一次提交、校验分支差异（与 main 比较）、取消。

随后读取计划与任务（通过 TaskList 获取所有任务及其状态，并读取 .ai-factory/DESCRIPTION.md 获取项目上下文，如技术栈与约定），并收集变更文件，例如 git diff --name-only main...HEAD，或在 main 分支上使用 git diff --name-only HEAD~$(number_of_tasks)..HEAD，结果记为 CHANGED_FILES。

步骤 1：任务完成度审计

逐条检查计划中的每个任务是否真正实现。对每个任务读取其完整描述、需求与验收标准，然后用 Glob 与 Grep 查找实现代码并读取相关文件，确认实现与描述相符，而不仅仅是“写了点东西”。最终为每个任务给出状态：

✅ COMPLETE — 所有需求均已在代码中验证
⚠️ PARTIAL — 部分需求已实现，部分缺失
❌ NOT FOUND — 未检测到实现
⏭️ SKIPPED — 用户在实现阶段有意跳过

步骤 2：代码质量校验

构建与编译检查：按项目类型选择命令，例如 go.mod 用 go build ./...，tsconfig.json 用 npx tsc --noEmit，带 build 脚本的 package.json 用 npm run build（或 pnpm/yarn/bun），pyproject.toml 对变更文件执行 python -m py_compile，Cargo.toml 用 cargo check，composer.json 用 composer validate。构建失败时报告带 file:line 引用的错误。

测试检查：若项目有测试且测试属于计划的一部分，则按类型执行，例如 jest/vitest 用 npm test，pytest 用 pytest，Go 用 go test ./...，phpunit 用 ./vendor/bin/phpunit，Cargo 用 cargo test。测试失败时报告失败的测试及其是否与已实现任务相关；若无测试或计划中明确跳过测试，则记录但不视为失败。

Lint 检查：若配置了 linter，则仅对变更文件执行，例如 npx eslint [changed files]、golangci-lint run ./...、ruff check [changed files]、./vendor/bin/php-cs-fixer fix --dry-run --diff。

导入与依赖检查：确认没有遗留未使用的 import；核对任务中提到的新依赖是否已实际加入（package.json、go.mod、requirements.txt、composer.json）；检查是否存在引用了依赖文件中不存在的包的缺失依赖。

步骤 3：一致性检查

计划与代码漂移：检查命名（变量/函数/接口名是否与计划一致）、文件位置、API 契约（接口路径、请求/响应结构是否与计划一致）。

DESCRIPTION.md 同步：检查 .ai-factory/DESCRIPTION.md 是否反映当前状态，包括实现期间新增的依赖/库、架构变更、新集成。

步骤 4：验证报告

显示结果，包括任务完成度表格（编号、任务、状态、备注）、代码质量（构建、测试、Lint 结果）、发现的问题与无问题项。随后判定整体状态：全绿（全部通过、无问题）、次要问题（可快速修复的小缺口）、重大缺口（任务缺失或部分完成，需要重新实现）。

若发现问题，会询问用户如何处理：立即修复全部问题、只修复关键问题（不完整任务，跳过警告）、按现状接受。若选择修复，则按实现阶段的规则直接补齐缺失部分、清理 TODO/调试残留、更新 .env.example 与文档，并在修复后重新运行相关校验；若选择接受，则在计划文件中以注释记录被接受的问题并继续。

步骤 5：建议后续技能

验证完成（全绿或问题被接受）后，建议可选的后续步骤：对更改文件运行安全审计、对实现进行代码评审、提交更改，或跳过。之后提示清理上下文，选项为 /clear（完全重置，推荐）、/compact（压缩历史）、继续。

使用方式

实现之后（会自动建议）：

/ai-factory.verify

合并前严格模式：

/ai-factory.verify --strict

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

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

严格模式

以 --strict 调用时：所有任务必须为 COMPLETE，不允许部分完成或跳过；构建必须通过，否则验证失败；测试必须通过，任一测试失败即失败（严格模式下测试为必需）；Lint 必须通过，零警告零错误；变更文件中不得有 TODO/FIXME；不得有未记录的环境变量。严格模式推荐在合并到 main 或创建拉取请求前使用。

适用场景与限制

适用于实现完成后的质量核对、合并前的严格把关，以及无计划时对分支差异的独立校验。该技能为可选技能，不替代实现本身；校验范围依赖计划文件与任务列表的存在，且无计划时只能退化为校验最后一次提交或分支差异。资料未提供关于收费、价格、平台支持范围的其他信息。