verify-changes
The verify-changes command runs comprehensive validation of recent code modifications by spawning five parallel verification subagents that perform syntax checking, testing, linting, security scanning, and build validation. It then deploys three additional adversarial subagents to filter false positives and identify overlooked issues. Use this command after committing code changes to ensure quality, security, and build integrity across the entire codebase before deployment.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/CloudAI-X/claude-workflow-v2/HEAD/commands/verify-changes.md -o ~/.claude/commands/verify-changes.mdverify-changes.md
# Verify Changes
Run comprehensive verification of recent code changes using multi-subagent adversarial approach.
## Phase 1: Gather Context
Run these commands to understand what changed:
```bash
git diff HEAD~1 --stat
git log -3 --oneline
git diff --name-only HEAD~1
```
Identify affected files and their corresponding test files.
## Phase 2: Spawn Verification Subagents (Parallel)
Use the Task tool with `run_in_background: true` to spawn subagents in parallel.
**CRITICAL**: Launch ALL subagents in a SINGLE message for true parallelism:
```
[All Task calls in ONE message]
Task 1: {
description: "Syntax & Type Check",
prompt: "Run language-specific type checker (tsc, mypy, go vet)...",
run_in_background: true
}
Task 2: {
description: "Test Runner",
prompt: "Run tests for affected files first, then integration tests...",
run_in_background: true
}
Task 3: {
description: "Lint & Style Check",
prompt: "Run project linter (eslint, ruff, golangci-lint)...",
run_in_background: true
}
Task 4: {
description: "Security Scan",
prompt: "Grep for hardcoded secrets, check for vulnerabilities...",
run_in_background: true
}
Task 5: {
description: "Build Validator",
prompt: "Run build command, verify artifacts exist...",
run_in_background: true
}
```
Each subagent returns its result automatically when it completes — there is no
separate retrieval call. Read each verifier's report as it returns.
### Subagent Details
### Subagent 1: Syntax & Type Check
- Run language-specific type checker (tsc, mypy, go vet)
- Report any type errors or warnings
- Exit with list of issues found
### Subagent 2: Test Runner
- Run tests for affected files first
- Run related integration tests
- Report failures with file:line context
### Subagent 3: Lint & Style Check
- Run project linter (eslint, ruff, golangci-lint)
- Check for formatting issues
- Report violations with severity
### Subagent 4: Security Scan
- Grep for hardcoded secrets (passwords, API keys, tokens)
- Check for common vulnerabilities in new code
- Review any new dependencies
### Subagent 5: Build Validator
- Run build command
- Verify build artifacts exist
- Check for build warnings
## Phase 3: Adversarial Review
Spawn 3 adversarial subagents to review Phase 2 findings:
### Adversarial A: False Positive Filter
- Review each finding from Phase 2
- Determine if it's a real issue or false alarm
- Provide reasoning for each determination
### Adversarial B: Missing Issues Finder
- Look for issues the first pass might have missed
- Check edge cases in changed code
- Verify error handling is adequate
### Adversarial C: Context Validator
- Verify findings make sense in project context
- Check if "issues" are actually intentional patterns
- Consider project conventions
## Phase 4: Synthesize Results
Combine all subagent outputs into final report:
```
## Verification Results: [PASS/FAIL]
### Confirmed Issues
1. [Issue] - [Location] - [Why it's confirmed real]
### Warnings (Review Recommended)
1. [Warning] - [Location] - [Context]
### All Checks
- [ ] Type checking: [PASS/FAIL]
- [ ] Tests: [PASS/FAIL]
- [ ] Linting: [PASS/FAIL]
- [ ] Security: [PASS/FAIL]
- [ ] Build: [PASS/FAIL]
### Subagent Summary
- Initial findings: X issues
- After adversarial review: Y confirmed issues
- False positives filtered: Z
```
## Usage
This command ships with the project-starter plugin. Invoke with: `/project-starter:verify-changes`Expert code review specialist. Use PROACTIVELY after writing or modifying code, before commits, when asked to review changes, PR review, code quality check, lint, or standards audit. Focuses on quality, security, performance, and maintainability.
Expert debugging specialist for errors, test failures, crashes, segmentation faults, memory leaks, timeouts, race conditions, deadlocks, and unexpected behavior. Use PROACTIVELY when encountering any error, exception, or failing test. Performs systematic root cause analysis.
Technical documentation specialist. Use for creating README files, API documentation, architecture docs, inline comments, user guides, changelogs, migration guides, release notes, FAQs, and troubleshooting docs. MUST BE USED when documentation is needed or when code changes require doc updates.
Master coordinator for complex multi-step tasks. Use PROACTIVELY when a task involves 2+ modules, requires delegation to specialists, needs architectural planning, or involves GitHub PR workflows. MUST BE USED for open-ended requests like "improve", "enhance", "build", "scale", "refactor", "add feature", "system design", "architecture", "complex task", or when implementing features from GitHub issues.
Code refactoring specialist for improving code quality, reducing technical debt, eliminating code smells, reducing complexity, and applying design patterns. Use PROACTIVELY when code needs restructuring, simplification, tech debt reduction, or when applying DRY/SOLID principles.
Security specialist for vulnerability detection, secure coding review, and security hardening. Use PROACTIVELY when handling authentication, authorization, encryption, secrets, credentials, OAuth, JWT, CORS, headers, user input, API keys, or sensitive data. Checks for OWASP Top 10 and common vulnerabilities.
Testing strategy specialist for designing test suites, writing tests, and ensuring comprehensive coverage. Use PROACTIVELY when adding new features, fixing bugs, improving test coverage, creating test plans, mocking strategies, handling flaky tests, or writing integration/E2E tests.
Add tests for recently changed files or specified code