Verify Changes

Read the project's agent instructions (e.g. AGENTS.md), plus any nested AGENTS.md in directories you changed, before applying this skill, so the correct verification commands and documentation requirements are known.

Procedure

1. Check prerequisites. If the project has a setup or health-check command, or its checks need services (a database, containers, a local server), get those working first. A missing tool or service is an environment problem to fix, not a reason to skip a check.
2. Identify the verification commands. Check the project's agent instructions (AGENTS.md), Makefile, or CI config for the canonical build/test/lint commands. Common patterns: make build test lint, npm test, cargo clippy && cargo test. Prefer the command CI runs.
3. Run them. Execute the full suite. Do not skip steps or run partial checks.
4. Fix failures. If any step fails, diagnose and fix the issue, then re-run from the top. Repeat until clean. While fixing:
   • Never weaken a test, assertion, constraint, or lint rule to make it pass. Fix the code or the data.
   • Never remove, stub, or disable existing behavior to clear an error. If behavior truly has to go, stop and say so.
   • Never resolve a dependency conflict by downgrading until the warnings stop. Resolve to a coherent set of versions, or report the conflict.
   • If a fix makes an error disappear and you cannot explain why, say so instead of moving on.
   • If a check reports stale generated files, regenerate them and include them in the change.
5. Check behavior. A passing build is not evidence of correct behavior. Where practical, exercise what you changed (the relevant test, a CLI command, a request against a running service) and note what you observed. In this project, /xmind-mcp-smoke-test exercises the tool surface end to end through a running server. Run it for changes to a tool's arguments, responses, or behavior when the MCP client is connected to the build under test; otherwise say it was not run.

6. Check documentation. If the project's agent instructions include a map of which changes require which doc updates, follow it. Otherwise, use these defaults:

   • New/removed files -- project structure docs
   • New utilities or helpers -- reference tables or API docs
   • New conventions established -- convention docs
   • New config or skill files -- reflect in agent instructions if they affect agent behavior
   • New package or module -- a README, from the project's template if it has one

   Generated doc sections (content between generator markers) are updated by running the project's generator, never by hand. Run its drift check if it has one, then confirm the hand-written text around the generated sections still holds.

   docs/example.xmind is generated by make gen-example, which assigns fresh UUIDs on every run. Regenerate it only when cmd/gen-example changes; regenerating it otherwise only adds churn.

7. Make doc updates if needed. Edit AGENTS.md directly, never a CLAUDE.md symlink that points to it. Only update docs when something actually changed; no cosmetic edits to show compliance.
8. Re-run verification if doc changes touched source files (e.g. doc comments in code, embedded docs, generated sections).

Report

• State what changed and what behavior that change could affect. Call out changes to public contracts, configuration, or dependency wiring explicitly.
• Report the verification commands you ran and their results, including anything skipped and why.
• List any commented-out code or TODO markers left in the changed code. The compiler cannot see unfinished work; the report should.

Anti-patterns

• Do not skip verification because "it's a small change." Small changes break builds too.
• Do not mark verification complete if there are known failures the user has not acknowledged.
• Do not report work as done just because it compiles.
• Do not run only tests without also running lint, or vice versa. Run the full suite.
• Do not silently suppress warnings or skip flaky tests without flagging them.
• Do not replace working code with a comment describing what the code would do. "In a real implementation ..." is a defect, not a placeholder.

Related skills

• This is a natural prerequisite for /commit-message.