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.

Step 0: Load Context

0.0 Load config.yaml

FIRST: Read .ai-factory/config.yaml if it exists to resolve:

Paths: paths.description, paths.architecture, paths.rules_file, paths.roadmap, paths.plan, paths.plans, paths.fix_plan, paths.specs, paths.rules, and paths.archive
verify_mode: default verification strictness (strict | normal | lenient)
Git: git.enabled, git.base_branch, git.create_branches
Rules hierarchy: the resolved RULES.md path + rules.base + named rules.<area> entries
Language: language.ui for prompts, user-visible explanations, verification reports, context-gate summaries, issue remediation prompts, and next-step guidance
Workflow: workflow.plan_id_format (default: slug) — used by branch-based plan discovery in Step 0.2. Active values: slug and sequential. When sequential, the resolver globs <paths.plans>/[0-9]{4}_<branch_stem>.md first and falls back to <paths.plans>/<branch_stem>.md only if no numbered match is found. timestamp and uuid are reserved values and currently behave like slug. Treat any unknown value as slug.

verify_mode priority:

--strict CLI flag → always use strict
config.yaml workflow.verify_mode → use configured value
Default → normal

If config.yaml doesn't exist, use defaults:

Paths: .ai-factory/ for all artifacts
verify_mode: normal
Rules: RULES.md only
ui_language: en
workflow.plan_id_format: slug

Resolved language value:

ui_language = language.ui || "en"

All AskUserQuestion prompts, user-visible explanations, verification reports, context-gate summaries, issue remediation prompts, and next-step guidance MUST be written in ui_language.

Preserve machine-readable aif-gate-result JSON schema fields and enum values (pass, warn, fail) unchanged. Preserve WARN/ERROR gate labels, commands, paths, config keys, code identifiers, package names, API names, and raw command output unchanged.

0.1 Load Ownership and Gate Contract

Read references/CONTEXT-GATES-AND-OWNERSHIP.md first.
Read references/GATE-RESULT-CONTRACT.md for the machine-readable quality gate summary.
Treat it as the canonical source for:
- command-to-artifact ownership,
- read-only behavior for aif-commit/aif-review/aif-verify,
- normal vs strict context-gate thresholds.
If this contract conflicts with older examples in this file, follow the contract.

0.2 Find Plan File

Same logic as /aif-implement — produce the canonical branch stem before any plans-dir glob so producer and consumers agree by construction.

1. Check current git branch:
   git branch --show-current
2. Convert branch to filename stem (git mode only):
   branch_stem = current branch with every "/" replaced by "-"
   Example: feature/user-auth → feature-user-auth
3. Resolve the plan file using <branch_stem>:
   → When `workflow.plan_id_format = sequential`, glob first
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>.md
       - 0 matches → fall through to the un-prefixed lookup below
       - 1 match  → use it
       - >1 matches → use the **highest-numbered** match and emit
           WARN [aif-verify] multiple sequential plans for <branch>: <list>; using <chosen>
   → Otherwise (default `plan_id_format`, or sequential with no numbered match):
       <configured plans dir>/<branch_stem>.md
4. If the branch-based plan is missing or git mode is off:
   → Check whether the configured plans dir contains exactly one `*.md` full-mode
     plan (a leading 4-digit prefix counts as a match)
   → If exactly one exists, use it
   → If multiple exist, ask the user to choose or use `@<path>` via `/aif-implement`
5. No full-mode plan → Check the resolved fast plan path
6. No full-mode plan and no resolved fast plan → fall back to standalone verification choices

Note: Plan discovery scans paths.plans/ only. Plans archived to paths.archive/plans/ by /aif-archive are excluded from discovery. If a plan is found only in the archive, emit WARN [aif-verify] plan <name> is archived; verifying archived plan.

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 the configured base branch
3. Cancel

0.2 Read Plan & Tasks

Read the plan file to understand what was supposed to be implemented
TaskList → get all tasks and their statuses
Read .ai-factory/DESCRIPTION.md (use path from config) for project context (tech stack, conventions)
Read .ai-factory/ARCHITECTURE.md (use path from config) for dependency and boundary rules (if present)
Read rules hierarchy (use paths from config):
1. RULES.md — axioms (universal project rules)
2. rules/base.md — project-specific base conventions
3. rules.<area> — area-specific rule entries resolved from config (for example rules.api, rules.frontend)
Read .ai-factory/ROADMAP.md (use path from config) for milestone alignment checks (if present)

Read .ai-factory/skill-context/aif-verify/SKILL.md — MANDATORY if the file exists.

This file contains project-specific rules accumulated by /aif-evolve from patches, codebase conventions, and tech-stack analysis. These rules are tailored to the current project.

How to apply skill-context rules:

Treat them as project-level overrides for this skill's general instructions
When a skill-context rule conflicts with a general rule written in this SKILL.md, the skill-context rule wins (more specific context takes priority — same principle as nested CLAUDE.md files)
When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults — they exist because the project's experience proved the default insufficient
CRITICAL: skill-context rules apply to ALL outputs of this skill — including the Verification Report template. If a skill-context rule says "verification MUST check X" or "report MUST include section Y" — you MUST augment the report accordingly. Generating a verification that ignores skill-context rules is a bug.

Enforcement: After generating any output artifact, verify it against all skill-context rules. If any rule is violated — fix the output before presenting it to the user.

0.3 Gather Changed Files

# All files changed during this feature/plan
git diff --name-only <configured-base-branch>...HEAD
# Or if on the base branch / in no-git mode, check recent commits
git diff --name-only HEAD~$(number_of_tasks)..HEAD

If git.enabled = false, skip branch diffing entirely and gather changed files from:

the working tree (if uncommitted changes exist), or
the recent commit window that corresponds to the implemented tasks.

Store as CHANGED_FILES.

Step 1: Task Completion Audit

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

For each task:

1.1 Read Task Description

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

1.2 Verify Implementation Exists

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"

1.3 Build Checklist

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

Step 2: Code Quality Verification

2.1 Build & Compile Check

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.

2.2 Test Check

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.

2.3 Lint Check

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.

2.4 Import & Dependency Check

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)

Step 3: Consistency Checks

3.1 Plan vs Code Drift

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?

3.2 Leftover Artifacts

Search for things that should have been cleaned up:

Grep in CHANGED_FILES: [T][O][D][O]|[F][I][X][M][E]|HACK|[X][X][X]|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

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

3.3 Configuration & Environment

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.

3.4 DESCRIPTION.md Sync

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

3.5 Context Gates (Architecture / Roadmap / Rules)

Apply the canonical contract from references/CONTEXT-GATES-AND-OWNERSHIP.md.

Evaluate and report each gate explicitly:

Architecture gate
- Pass: implementation follows documented boundaries and dependency rules
- Warn: architecture mapping is ambiguous or stale
- Fail: clear violation of explicit architecture constraints
Rules gate
- Pass: implementation follows explicit project rules
- Warn: relevance/verification is ambiguous
- Fail: clear violation of explicit rule text
Roadmap gate
- Pass: work aligns with existing milestone direction (prefer ## Roadmap Linkage from the plan when present)
- Warn: .ai-factory/ROADMAP.md missing, ambiguous mapping, or no milestone linkage for feat/fix/perf scope
- Fail (strict mode): clear roadmap contradiction after all available roadmap context is considered

Normal mode behavior:

Architecture/rules clear violations fail verification.
Roadmap mismatch and missing milestone linkage are warnings unless contradiction is explicit and severe.

Strict mode behavior:

Architecture and rules clear violations fail verification.
Clear roadmap mismatch fails verification.
Missing milestone linkage for feat/fix/perf remains a warning (even when .ai-factory/ROADMAP.md exists).

Human logging/reporting format:

Non-blocking findings: WARN [gate-name] ...
Blocking findings: ERROR [gate-name] ...

If the user wants a standalone rules-only pass, suggest /aif-rules-check. Keep human context-gate labels at WARN / ERROR, then derive the final machine-readable gate result from the full verification report.

Machine-readable gate result:

Append one final fenced aif-gate-result JSON block after the human-readable verification report.
Use "gate": "verify".
Use "status": "pass|warn|fail" where:
- fail = incomplete required tasks, failed blocking quality checks, strict-mode context gate failures, or other blockers requiring remediation.
- warn = only non-blocking warnings remain, optional checks were skipped, docs/test gaps were accepted as warnings, or context drift is ambiguous.
- pass = no blocking or warning findings remain.
Use "blocking": true|false; set it to true only when the result should stop commit or merge flow.
Include only blocking findings in "blockers": [; keep non-blocking notes in the human summary.
Include changed or implicated paths in "affected_files": [.
Set "suggested_next": { to /aif-fix, /aif-rules, /aif-architecture, /aif-roadmap, /aif-commit, or null according to references/GATE-RESULT-CONTRACT.md.

3.6 Context Drift (Optional Remediation)

/aif-verify is read-only for context artifacts. Do not edit or regenerate .ai-factory/* files here.

If you detect that a context artifact is stale, missing, or ambiguous, report it as a drift finding and provide the owner-command remediation:

DESCRIPTION.md drift → suggest /aif (or note that /aif-implement should have updated it during implementation)
ARCHITECTURE.md drift → suggest /aif-architecture
ROADMAP.md drift → suggest /aif-roadmap check (or /aif-roadmap <update request>)
RULES.md drift → suggest /aif-rules <rule text>

Ask the user a single optional question only if drift was detected and fixing it now would materially improve correctness:

AskUserQuestion: Context drift detected. Capture updates now?

Options:
1. Yes — show the exact commands to run (recommended)
2. No — proceed without updating context

Step 4: Verification Report

4.1 Display Results

Write the human-readable verification report in ui_language. The template below defines structure only; keep stable technical tokens and the final aif-gate-result JSON schema unchanged.

## 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/ |

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

### Issues Found
1. **Task #3 incomplete** — Password reset endpoint created but email sending not implemented (SendGrid integration missing)
2. **Task #8 not done** — API documentation not updated despite plan requirement
3. **2 unfinished markers found** — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
4. **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

4.2 Determine Overall Status

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.2.1 Append Machine-Readable Gate Result

After the human-readable report and overall status, append exactly one final aif-gate-result fenced JSON block.

{
  "schema_version": 1,
  "gate": "verify",
  "status": "pass",
  "blocking": false,
  "blockers": [],
  "affected_files": [],
  "suggested_next": {
    "command": "/aif-commit",
    "reason": "Verification passed without blockers."
  }
}

Schema reminder: "status": "pass|warn|fail", "blocking": true|false, "blockers": [, "affected_files": [, "suggested_next": {.

4.3 Action on Issues

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 unfinished markers 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 unfinished markers/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

Step 5: Suggest Follow-Up Skills

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

## Verification Complete

Suggested next steps:

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

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

AskUserQuestion: Run additional checks?

Options:
1. Fix issues — Run /aif-fix with verification findings
2. Security check — Run /aif-security-checklist on changed files
3. Code review — Run /aif-review on the implementation
4. Both — Run security check, then code review
5. 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

Context Cleanup

Suggest the user to free up context space if needed: /clear (full reset) or /compact (compress history).

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 unfinished task markers in changed files
No undocumented environment variables
Architecture gate must pass — fail on clear boundary/dependency violations
Rules gate must pass — fail on clear rule violations
Roadmap gate must pass — fail on clear roadmap mismatch
Missing milestone linkage for feat/fix/perf is a warning even in strict mode
Do not fail strict verification solely because milestone linkage is missing

Strict mode is recommended before merging to the configured base branch or creating a pull request.

Usage

After implement (suggested automatically)

/aif-verify

Strict mode before merge

/aif-verify --strict

Standalone (no plan, verify branch diff)

/aif-verify
→ No plan found → verify branch diff against the configured base branch