aif-verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verify — Post-Implementation Quality Check

验证——实现后质量检查

Verify that the completed implementation matches the plan, nothing was missed, and the code is production-ready.

This skill is optional — invoked after

/aif-implement

finishes all tasks, or manually at any time.

验证已完成的实现是否与计划一致，是否有遗漏，以及代码是否可用于生产环境。

本技能为可选技能 —— 在"/aif-implement"完成所有任务后调用，或随时手动调用。

Step 0: Load Context

步骤0：加载上下文

0.1 Find Plan File

0.1 查找计划文件

Same logic as

/aif-implement

1. .ai-factory/PLAN.md exists? → Use it
2. No PLAN.md → Check current git branch:
   git branch --show-current
   → Look for .ai-factory/plans/<branch-name>.md

If no plan file found:

AskUserQuestion: No plan file found. What should I verify?

Options:
1. Verify last commit — Check the most recent commit for completeness
2. Verify branch diff — Compare current branch against main
3. Cancel

与"/aif-implement"逻辑相同：

1. .ai-factory/PLAN.md exists? → Use it
2. No PLAN.md → Check current git branch:
   git branch --show-current
   → Look for .ai-factory/plans/<branch-name>.md

如果未找到计划文件：

AskUserQuestion: No plan file found. What should I verify?

Options:
1. Verify last commit — Check the most recent commit for completeness
2. Verify branch diff — Compare current branch against main
3. Cancel

0.2 Read Plan & Tasks

0.2 读取计划与任务

Read the plan file to understand what was supposed to be implemented
```
TaskList
```
→ get all tasks and their statuses
Read
```
.ai-factory/DESCRIPTION.md
```
for project context (tech stack, conventions)

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

0.3 Gather Changed Files

0.3 收集已变更文件

bash

undefined

bash

undefined

All files changed during this feature/plan

git diff --name-only main...HEAD

Or if on main, check recent commits

git diff --name-only HEAD~$(number_of_tasks)..HEAD


Store as `CHANGED_FILES`.

---

git diff --name-only HEAD~$(number_of_tasks)..HEAD


将结果存储为`CHANGED_FILES`。

---

Step 1: Task Completion Audit

步骤1：任务完成情况审计

Go through every task in the plan and verify it was actually implemented.

For each task:

逐一检查计划中的每一项任务，验证其是否已实际实现。

针对每个任务：

1.1 Read Task Description

1.1 读取任务描述

TaskGet(taskId) → Get full description, requirements, acceptance criteria

TaskGet(taskId) → Get full description, requirements, acceptance criteria

1.2 Verify Implementation Exists

1.2 验证实现是否存在

For each requirement in the task description:

Use
```
Glob
```
and
```
Grep
```
to find the code that implements it
Read the relevant files to confirm the implementation is complete
Check that the implementation matches what was described, not just that "something was written"

针对任务描述中的每一项需求：

使用
```
Glob
```
和
```
Grep
```
查找实现该需求的代码
读取相关文件，确认实现是否完整
检查实现内容是否与描述一致，而非仅确认“有代码编写”

1.3 Build Checklist

1.3 构建检查清单

For each task, produce a verification result:

✅ Task #1: Create user model — COMPLETE
   - User model created at src/models/user.ts
   - All fields present (id, email, name, createdAt, updatedAt)
   - Validation decorators added

⚠️ Task #3: Add password reset endpoint — PARTIAL
   - Endpoint created at src/api/auth/reset.ts
   - MISSING: Email sending logic (task mentioned SendGrid integration)
   - MISSING: Token expiration check

❌ Task #5: Add rate limiting — NOT FOUND
   - No rate limiting middleware detected
   - No rate-limit related packages in dependencies

Statuses:

```
✅ COMPLETE
```
— all requirements verified in code
```
⚠️ PARTIAL
```
— some requirements implemented, some missing
```
❌ NOT FOUND
```
— implementation not detected
```
⏭️ SKIPPED
```
— task was intentionally skipped by user during implement

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

✅ Task #1: Create user model — COMPLETE
   - User model created at src/models/user.ts
   - All fields present (id, email, name, createdAt, updatedAt)
   - Validation decorators added

⚠️ Task #3: Add password reset endpoint — PARTIAL
   - Endpoint created at src/api/auth/reset.ts
   - MISSING: Email sending logic (task mentioned SendGrid integration)
   - MISSING: Token expiration check

❌ Task #5: Add rate limiting — NOT FOUND
   - No rate limiting middleware detected
   - No rate-limit related packages in dependencies

状态说明：

```
✅ COMPLETE
```
— 所有需求均在代码中验证通过
```
⚠️ PARTIAL
```
— 部分需求已实现，部分缺失
```
❌ NOT FOUND
```
— 未检测到相关实现
```
⏭️ SKIPPED
```
— 用户在实现过程中有意跳过该任务

Step 2: Code Quality Verification

步骤2：代码质量验证

2.1 Build & Compile Check

2.1 构建与编译检查

Detect the build system and verify the project compiles:

Detection	Command
`go.mod`	`go build ./...`
`tsconfig.json`	`npx tsc --noEmit`
`package.json` with `build` script	`npm run build` (or pnpm/yarn/bun)
`pyproject.toml`	`python -m py_compile` on changed files
`Cargo.toml`	`cargo check`
`composer.json`	`composer validate`

If build fails → report errors with file:line references.

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

检测标识	命令
`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`

如果构建失败 → 报告错误并附带文件:行号引用。

2.2 Test Check

2.2 测试检查

If the project has tests and they were part of the plan:

Detection	Command
`jest.config.*` or `vitest`	`npm test`
`pytest`	`pytest`
`go test`	`go test ./...`
`phpunit.xml*`	`./vendor/bin/phpunit`
`Cargo.toml`	`cargo test`

If tests fail → report which tests failed and whether they relate to the implemented tasks.

If no tests exist or testing was explicitly skipped in the plan → note it but don't fail.

如果项目包含测试且测试已纳入计划：

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

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

如果项目无测试或计划中明确跳过测试 → 仅做记录，不判定失败。

2.3 Lint Check

2.3 代码规范检查

If linters are configured:

Detection	Command
`eslint.config.` / `.eslintrc`	`npx eslint [changed files]`
`.golangci.yml`	`golangci-lint run ./...`
`ruff` in pyproject.toml	`ruff check [changed files]`
`.php-cs-fixer*`	`./vendor/bin/php-cs-fixer fix --dry-run --diff`

Only lint the changed files to keep output focused.

如果已配置代码规范工具：

检测标识	命令
`eslint.config.` / `.eslintrc`	`npx eslint [changed files]`
`.golangci.yml`	`golangci-lint run ./...`
pyproject.toml中含 `ruff`	`ruff check [changed files]`
`.php-cs-fixer*`	`./vendor/bin/php-cs-fixer fix --dry-run --diff`

仅对已变更文件执行检查，以保持输出聚焦。

2.4 Import & Dependency Check

2.4 导入与依赖检查

Verify no unused imports were left behind
Check that new dependencies mentioned in tasks were actually added (
```
package.json
```
,
```
go.mod
```
,
```
requirements.txt
```
,
```
composer.json
```
)
Check for missing dependencies (imports that reference packages not in dependency files)

验证是否遗留未使用的导入
检查任务中提及的新依赖是否已实际添加（
```
package.json
```
、
```
go.mod
```
、
```
requirements.txt
```
、
```
composer.json
```
）
检查是否存在缺失的依赖（引用了依赖文件中未包含的包的导入语句）

Step 3: Consistency Checks

步骤3：一致性检查

3.1 Plan vs Code Drift

3.1 计划与代码偏差

Check for discrepancies between what the plan says and what was built:

Naming: Do variable/function/endpoint names match what the plan specified?
File locations: Are files where the plan said they should be?
API contracts: Do endpoint paths, request/response shapes match the plan?

检查计划描述与实际构建内容之间的差异：

命名规范：变量/函数/接口名称是否与计划指定的一致？
文件位置：文件是否存放在计划指定的位置？
API契约：接口路径、请求/响应结构是否与计划一致？

3.2 Leftover Artifacts

3.2 遗留产物

Search for things that should have been cleaned up:

Grep in CHANGED_FILES: TODO|FIXME|HACK|XXX|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

Report any found — they might be intentional, but flag them.

搜索应清理的内容：

Grep in CHANGED_FILES: TODO|FIXME|HACK|XXX|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

报告所有找到的内容——这些内容可能是有意遗留的，但需进行标记。

3.3 Configuration & Environment

3.3 配置与环境

Check if the implementation introduced any new config requirements:

New environment variables referenced but not documented
New config files mentioned in code but not created
Database migrations created but not documented in README/docs

Grep in CHANGED_FILES: process\.env\.|os\.Getenv\(|os\.environ|env\(|getenv\(|config\(

Cross-reference with

.env.example

.env.local

, README, or docs to ensure they're documented.

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

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

Grep in CHANGED_FILES: process\.env\.|os\.Getenv\(|os\.environ|env\(|getenv\(|config\(

与

.env.example

、

.env.local

、README或文档进行交叉比对，确保相关内容已记录。

3.4 DESCRIPTION.md Sync

3.4 DESCRIPTION.md同步检查

Check if

.ai-factory/DESCRIPTION.md

reflects the current state:

New dependencies/libraries added during implementation → should be listed
Architecture changes → should be reflected
New integrations → should be documented

检查

.ai-factory/DESCRIPTION.md

是否反映了当前项目状态：

实现过程中添加的新依赖/库 → 应被列出
架构变更 → 应被体现
新集成 → 应被记录

Step 4: Verification Report

步骤4：验证报告

4.1 Display Results

4.1 展示结果

undefined

undefined

Verification Report

Task Completion: 7/8 (87%)

#	Task	Status	Notes
1	Create user model	✅ Complete
2	Add registration endpoint	✅ Complete
3	Add password reset	⚠️ Partial	Missing: email sending
4	Add JWT auth middleware	✅ Complete
5	Add rate limiting	✅ Complete
6	Add input validation	✅ Complete
7	Add error handling	✅ Complete
8	Update API docs	❌ Not found	No changes in docs/

#	Task	Status	Notes
1	Create user model	✅ Complete
2	Add registration endpoint	✅ Complete
3	Add password reset	⚠️ Partial	Missing: email sending
4	Add JWT auth middleware	✅ Complete
5	Add rate limiting	✅ Complete
6	Add input validation	✅ Complete
7	Add error handling	✅ Complete
8	Update API docs	❌ Not found	No changes in docs/

Code Quality

Build: ✅ Passes
Tests: ✅ 42 passed, 0 failed
Lint: ⚠️ 2 warnings in src/api/auth/reset.ts

Build: ✅ Passes
Tests: ✅ 42 passed, 0 failed
Lint: ⚠️ 2 warnings in src/api/auth/reset.ts

Issues Found

Task #3 incomplete — Password reset endpoint created but email sending not implemented (SendGrid integration missing)
Task #8 not done — API documentation not updated despite plan requirement
2 TODOs found — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
New env var undocumented —
```
SENDGRID_API_KEY
```
referenced but not in .env.example

Task #3 incomplete — Password reset endpoint created but email sending not implemented (SendGrid integration missing)
Task #8 not done — API documentation not updated despite plan requirement
2 TODOs found — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
New env var undocumented —
```
SENDGRID_API_KEY
```
referenced but not in .env.example

No Issues

All imports resolved
No unused dependencies
DESCRIPTION.md up to date
No leftover debug logs

undefined

All imports resolved
No unused dependencies
DESCRIPTION.md up to date
No leftover debug logs

undefined

4.2 Determine Overall Status

4.2 判定整体状态

All Green — everything verified, no issues
Minor Issues — small gaps that can be fixed quickly
Significant Gaps — tasks missing or partially done, needs re-implementation

全部合格 — 所有内容验证通过，无问题
轻微问题 — 存在可快速修复的小漏洞
重大缺口 — 任务缺失或仅部分完成，需重新实现

4.3 Action on Issues

4.3 问题处理

If issues were found:

AskUserQuestion: Verification found issues. What should we do?

Options:
1. Fix now (recommended) — Use /aif-fix to address all issues
2. Fix critical only — Use /aif-fix for incomplete tasks, skip warnings
3. Fix directly here — Address issues in this session without /aif-fix
4. Accept as-is — Mark everything as done, move on

If "Fix now" or "Fix critical only":

First suggest using
```
/aif-fix
```
and pass a concise issue summary as argument

Example:

/aif-fix complete Task #3 password reset email flow, implement Task #8 docs update, remove TODOs in src/services/auth.ts and src/middleware/rate-limit.ts, document SENDGRID_API_KEY in .env.example

If user agrees, proceed via
```
/aif-fix
```
If user declines
```
/aif-fix
```
, continue with direct implementation in this session
For each incomplete/partial task — implement the missing pieces (follow the same implementation rules as
```
/aif-implement
```
)
For TODOs/debug artifacts — clean them up
For undocumented config — update
```
.env.example
```
and docs
After fixing, re-run the relevant verification checks to confirm

If "Accept as-is":

Note the accepted issues in the plan file as a comment
Continue to Step 5

如果发现问题：

AskUserQuestion: Verification found issues. What should we do?

Options:
1. Fix now (recommended) — Use /aif-fix to address all issues
2. Fix critical only — Use /aif-fix for incomplete tasks, skip warnings
3. Fix directly here — Address issues in this session without /aif-fix
4. Accept as-is — Mark everything as done, move on

如果选择"Fix now"或"Fix critical only"：

首先建议使用
```
/aif-fix
```
，并将简洁的问题摘要作为参数传入

示例：

/aif-fix complete Task #3 password reset email flow, implement Task #8 docs update, remove TODOs in src/services/auth.ts and src/middleware/rate-limit.ts, document SENDGRID_API_KEY in .env.example

如果用户同意，通过
```
/aif-fix
```
继续处理
如果用户拒绝使用
```
/aif-fix
```
，则在当前会话中直接进行修复
针对每个未完成/部分完成的任务 —— 实现缺失部分（遵循与
```
/aif-implement
```
相同的实现规则）
针对TODO/调试产物 —— 进行清理
针对未记录的配置 —— 更新
```
.env.example
```
和文档
修复完成后，重新运行相关验证检查以确认问题已解决

如果选择"Accept as-is"：

在计划文件中添加注释，记录已接受的问题
继续执行步骤5

Step 5: Suggest Follow-Up Skills

步骤5：推荐后续技能

After verification is complete, suggest next steps based on result:

If unresolved issues remain (accepted or deferred), suggest
```
/aif-fix
```
first
If all green, suggest security/review/commit flow

undefined

验证完成后，根据结果推荐下一步操作：

如果存在未解决的问题（已接受或延迟处理），首先推荐
```
/aif-fix
```
如果全部合格，推荐安全检查/代码评审/提交流程

undefined

Verification Complete

Suggested next steps:

🛠️ /aif-fix [issue summary] — Fix remaining verification issues
🔒 /aif-security-checklist — Run security audit on the new code
👀 /aif-review — Code review of the implementation
💾 /aif-commit — Commit the changes

Which would you like to run? (or skip all)

undefined

AskUserQuestion: Run additional checks?

Options:

Fix issues — Run /aif-fix with verification findings
Security check — Run /aif-security-checklist on changed files
Code review — Run /aif-review on the implementation
Both — Run security check, then code review
Skip — Proceed to commit


**If fix issues selected** → suggest invoking `/aif-fix <issue summary>`
**If security check selected** → suggest invoking `/aif-security-checklist`
**If code review selected** → suggest invoking `/aif-review`
**If both** → suggest security first, then review
**If skip** → suggest `/aif-commit`

Suggested next steps:

🛠️ /aif-fix [issue summary] — Fix remaining verification issues
🔒 /aif-security-checklist — Run security audit on the new code
👀 /aif-review — Code review of the implementation
💾 /aif-commit — Commit the changes

Which would you like to run? (or skip all)

undefined

AskUserQuestion: Run additional checks?

Options:

Fix issues — Run /aif-fix with verification findings
Security check — Run /aif-security-checklist on changed files
Code review — Run /aif-review on the implementation
Both — Run security check, then code review
Skip — Proceed to commit


**如果选择修复问题** → 建议调用`/aif-fix <issue summary>`
**如果选择安全检查** → 建议调用`/aif-security-checklist`
**如果选择代码评审** → 建议调用`/aif-review`
**如果选择两者都做** → 建议先执行安全检查，再进行代码评审
**如果选择跳过** → 建议调用`/aif-commit`

Context Cleanup

上下文清理

Context is heavy after verification. All results are saved — suggest freeing space:

AskUserQuestion: Free up context before continuing?

Options:
1. /clear — Full reset (recommended)
2. /compact — Compress history
3. Continue as is

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

AskUserQuestion: Free up context before continuing?

Options:
1. /clear — Full reset (recommended)
2. /compact — Compress history
3. Continue as is

Strict Mode

严格模式

When invoked with

--strict

/aif-verify --strict

All tasks must be COMPLETE — no partial or skipped allowed
Build must pass — fail verification if build fails
Tests must pass — fail verification if any test fails (tests are required in strict mode)
Lint must pass — zero warnings, zero errors
No TODOs/FIXMEs in changed files
No undocumented environment variables

Strict mode is recommended before merging to main or creating a pull request.

使用

--strict

参数调用时：

/aif-verify --strict

所有任务必须完全完成 — 不允许部分完成或跳过
构建必须通过 — 如果构建失败，验证判定为失败
测试必须通过 — 如果任何测试失败，验证判定为失败（严格模式下要求必须有测试）
代码规范检查必须通过 — 零警告、零错误
已变更文件中不得存在TODO/FIXME
不得存在未记录的环境变量

在合并到main分支或创建拉取请求前，推荐使用严格模式。

Usage

使用方式

After implement (suggested automatically)

实现完成后（自动推荐）

/aif-verify

/aif-verify

Strict mode before merge

合并前的严格模式

/aif-verify --strict

/aif-verify --strict

Standalone (no plan, verify branch diff)

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

/aif-verify
→ No plan found → verify branch diff against main

/aif-verify
→ No plan found → verify branch diff against main