workflow pipeline

Verify Work

Verifies implementation against design documents, runs build, auto-fixes formatting, and executes tests. Updates tasks.md with granular verification status.

Verify Work Skill

Goal

Comprehensively verify that implemented code compiles, passes tests, meets formatting standards, and properly addresses the task requirements per design documents and conventions. Update tasks.md with granular verification status.

Prerequisites

  • At least one task from tasks.md has been implemented (marked [x])
  • tasks.md, design.md, spec.md, and story.md exist
  • planning/context-brief.md exists with reference patterns

Inputs (files)

Required:

  • tasks.md - The task checklist with implemented tasks
  • design.md - Technical specifications
  • spec.md - Service specifications
  • story.md - Parent User Story with acceptance criteria
  • planning/context-brief.md - Reference patterns and mandated approaches

Contextual (loaded as needed):

  • edge-cases.md - Edge case requirements (if exists)
  • Referenced instruction files from .github/instructions/
  • Modified source files from implementation

Outputs

  • Updated tasks.md with verification status
  • Auto-fixed formatting in source files (if needed)
  • Verification report with pass/fail details

Configuration

See config.json for:

  • Required input files
  • Verification phase settings
  • Docker dependency handling

Workflow

Step 0: Announce Verification Campaign

⚔️ VERIFICATION CAMPAIGN COMMENCING!
*unsheathes inspection scroll*

I shall inspect ALL recent conquests for battle-readiness!

Step 1: Identify Scope of Verification

Gather Changed Files:

  1. Check git status for modified/added files since last verification
  2. If no git changes, identify files from recently completed tasks in tasks.md
  3. Build list of files to verify

Report Scope:

📋 INSPECTION MANIFEST:
- Files under review: <count>
- Recently completed tasks: <list task numbers>

Step 2: Code Review (Design Alignment)

CRITICAL: Verify implementation matches design intent.

Load Context:

  1. Read story.md - Check acceptance criteria
  2. Read design.md - Check technical specifications
  3. Read spec.md - Check service contracts
  4. Read planning/context-brief.md - Check mandated patterns
  5. Read edge-cases.md (if exists) - Check edge case handling

Review Each Changed File:

For each modified file, verify:

  • Follows the reference pattern from context-brief.md
  • Implements the design from design.md correctly
  • Satisfies relevant acceptance criteria from story.md
  • Handles edge cases from edge-cases.md (if applicable)
  • Follows conventions from .github/instructions/conventions.instructions.md
  • Uses correct naming patterns (see conventions.instructions.md)

Check Instruction Compliance:

Based on file type, verify against relevant instructions:

  • Accessor files → magic.accessor.instructions.md
  • Marten models → marten.models.instructions.md
  • Host files → host.plugin.instructions.md
  • Test files → integration.tests.instructions.md
  • MassTransit → masstransit-saga.instructions.md

Report Issues:

If issues found:

⚠️ CODE REVIEW FINDINGS:

1. [File: src/services/accessor/profile/...] 
   Issue: Missing null check per edge-cases.md line 12
   
2. [File: src/services/accessor/profile/...]
   Issue: Method name doesn't follow convention (should be StoreCompany, not SaveCompany)

If no issues:

✅ CODE REVIEW: All files align with design documents and conventions!

Step 3: Docker Check (Test Prerequisites)

Check Docker Status:

Run: docker info (or equivalent check)

If Docker is NOT running:

⚠️ DOCKER NOT DETECTED!

Integration tests require Docker for PostgreSQL and RabbitMQ containers.

Options:
1. Start Docker and say "continue" to proceed with full tests
2. Say "skip tests" to proceed without running tests (will be noted in verification status)

Wait for user response:

  • User says "continue" → Proceed to Step 4 (Build)
  • User says "skip tests" → Set testsSkipped = true, proceed to Step 4 (Build)

If Docker IS running:

✅ DOCKER: Ready for battle! Containers can be deployed.

Step 4: Build Verification

Run Build:

From src/ directory:

dotnet build Lista.sln --no-restore

Evaluate Results:

  • Success (exit code 0, no warnings):

    ✅ BUILD: Fortress walls are SOLID! No errors, no warnings!
    
  • Success with warnings:

    ⚠️ BUILD: Compiled successfully but with warnings:
    <list warnings>
    
    These should be addressed before PR.
    
  • Failure:

    ❌ BUILD FAILED! 
    
    Errors:
    <list errors>
    
    HALT! Fix build errors before continuing verification.
    

    STOP verification if build fails. Return control to user.

Step 5: Format Check & Auto-Fix

Run Format with Auto-Fix:

From src/ directory:

dotnet format Lista.sln

Check for Changes:

Run git diff --name-only to see if formatting made changes.

Report Results:

  • No changes needed:

    ✅ FORMAT: Code already meets style standards!
    
  • Changes applied:

    ✅ FORMAT: Auto-fixed formatting in <count> file(s):
    - <file1>
    - <file2>
    
    Changes have been applied. Review and stage them.
    

Step 6: Test Execution

Skip if testsSkipped = true:

⚠️ TESTS: Skipped (Docker unavailable)

Otherwise, Run Tests:

From src/ directory:

dotnet test Lista.sln --no-build --verbosity normal

Evaluate Results:

  • All pass:

    ✅ TESTS: All <count> tests passed! Battle formations VERIFIED!
    
  • Some failures:

    ❌ TESTS: <passed> passed, <failed> failed
    
    Failed tests:
    - <test name 1>: <failure reason>
    - <test name 2>: <failure reason>
    
  • No tests found:

    ⚠️ TESTS: No tests found in solution. Consider adding tests.
    

Step 7: Update tasks.md with Verification Status

Locate or Create Verification Task:

Find the verification task in tasks.md (usually in 🏁 Verification section).

Update with Granular Status:

- [x] **ET-N**: Verify implementation → `verify-work` skill
  - Code Review: ✅ Aligned with design.md and acceptance criteria
  - Build: ✅ No errors or warnings
  - Format: ✅ Auto-fixed 2 files
  - Tests: ✅ 47 passed, 0 failed

Or with issues:

- [ ] **ET-N**: Verify implementation → `verify-work` skill
  - Code Review: ❌ Missing null check per edge-cases.md line 12
  - Build: ✅ No errors or warnings
  - Format: ✅ No changes needed
  - Tests: ⚠️ Skipped (Docker unavailable)

Task Completion Rules:

  • Mark [x] ONLY if ALL of these pass:
    • Code Review: ✅
    • Build: ✅ (no errors, warnings acceptable with note)
    • Format: ✅
    • Tests: ✅ OR ⚠️ Skipped (with user approval)
  • Keep [ ] if ANY required phase has ❌

Step 8: Final Report

⚔️ VERIFICATION CAMPAIGN COMPLETE!

Summary:
┌─────────────┬────────┬─────────────────────────────────┐
│ Phase       │ Status │ Details                         │
├─────────────┼────────┼─────────────────────────────────┤
│ Code Review │ ✅/❌  │ <summary>                       │
│ Build       │ ✅/❌  │ <summary>                       │
│ Format      │ ✅     │ <files fixed or "no changes">   │
│ Tests       │ ✅/⚠️/❌│ <pass/fail count or "skipped"> │
└─────────────┴────────┴─────────────────────────────────┘

Verification task in tasks.md: [x] PASSED / [ ] NEEDS ATTENTION

<if all passed>
*war horn sounds* 
Ready for `create-pr`! The code is BATTLE-TESTED and DEPLOYMENT-READY!

<if issues found>
*raises warning flag*
Address the findings above, then run `verify-work` again!

Rules / Behavior Rules

Verification Scope Rules

  • ✅ Verify ALL changed files since last verification
  • ✅ Check against ALL relevant design documents
  • ✅ Run full test suite (not just changed tests)
  • ❌ Do NOT skip code review phase
  • ❌ Do NOT ignore warnings in build

Docker Handling Rules

  • ✅ Check Docker availability before tests
  • ✅ Allow user to skip tests if Docker unavailable
  • ✅ Note skipped tests in verification status
  • ❌ Do NOT fail verification solely because Docker is unavailable
  • ❌ Do NOT proceed with tests if Docker check fails (wait for user)

Format Rules

  • ✅ Always run dotnet format to auto-fix issues
  • ✅ Report which files were changed
  • ❌ Do NOT use --verify-no-changes (we auto-fix instead)

Status Update Rules

  • ✅ Update tasks.md with granular per-phase status
  • ✅ Mark verification task [x] only when all required phases pass
  • ✅ Include specific details for any failures
  • ❌ Do NOT mark verification complete if Code Review or Build fails
  • ✅ Allow marking complete if Tests skipped (with user approval)

Exit Rules

  • ✅ Return control to user after verification
  • ✅ Recommend create-pr if all phases pass
  • ✅ Recommend fixes if issues found
  • ❌ Do NOT automatically proceed to create-pr

References

Related Skills

Instruction Files (Checked During Code Review)

Examples

Example 1: All Phases Pass

User: "verify work"

Agent:

⚔️ VERIFICATION CAMPAIGN COMMENCING!
*unsheathes inspection scroll*

📋 INSPECTION MANIFEST:
- Files under review: 4
- Recently completed tasks: #3, #4, #5

✅ CODE REVIEW: All files align with design documents and conventions!

✅ DOCKER: Ready for battle! Containers can be deployed.

✅ BUILD: Fortress walls are SOLID! No errors, no warnings!

✅ FORMAT: Code already meets style standards!

✅ TESTS: All 23 tests passed! Battle formations VERIFIED!

⚔️ VERIFICATION CAMPAIGN COMPLETE!

Summary:
┌─────────────┬────────┬─────────────────────────────────┐
│ Phase       │ Status │ Details                         │
├─────────────┼────────┼─────────────────────────────────┤
│ Code Review │ ✅     │ Aligned with design             │
│ Build       │ ✅     │ No errors or warnings           │
│ Format      │ ✅     │ No changes needed               │
│ Tests       │ ✅     │ 23 passed, 0 failed             │
└─────────────┴────────┴─────────────────────────────────┘

Verification task ET-12 marked [x] in tasks.md

*war horn sounds* 
Ready for `create-pr`! The code is BATTLE-TESTED and DEPLOYMENT-READY!

Example 2: Docker Not Available

User: "verify work"

Agent:

⚔️ VERIFICATION CAMPAIGN COMMENCING!

📋 INSPECTION MANIFEST:
- Files under review: 3
- Recently completed tasks: #2

✅ CODE REVIEW: All files align with design documents and conventions!

⚠️ DOCKER NOT DETECTED!

Integration tests require Docker for PostgreSQL and RabbitMQ containers.

Options:
1. Start Docker and say "continue" to proceed with full tests
2. Say "skip tests" to proceed without running tests (will be noted in verification status)

User: "skip tests"

Agent:

Acknowledged. Proceeding without test execution.

✅ BUILD: Fortress walls are SOLID! No errors, no warnings!

✅ FORMAT: Auto-fixed formatting in 1 file(s):
- src/services/accessor/profile/Lista.Accessor.Profile.Service/CompanyAccessor.cs

⚠️ TESTS: Skipped (Docker unavailable)

⚔️ VERIFICATION CAMPAIGN COMPLETE!

Summary:
┌─────────────┬────────┬─────────────────────────────────┐
│ Phase       │ Status │ Details                         │
├─────────────┼────────┼─────────────────────────────────┤
│ Code Review │ ✅     │ Aligned with design             │
│ Build       │ ✅     │ No errors or warnings           │
│ Format      │ ✅     │ Auto-fixed 1 file               │
│ Tests       │ ⚠️     │ Skipped (Docker unavailable)    │
└─────────────┴────────┴─────────────────────────────────┘

Verification task ET-8 marked [x] in tasks.md

*war horn sounds* 
Ready for `create-pr`! Note: Run full tests in CI pipeline.

Example 3: Code Review Finds Issues

User: "verify work"

Agent:

⚔️ VERIFICATION CAMPAIGN COMMENCING!

📋 INSPECTION MANIFEST:
- Files under review: 2
- Recently completed tasks: #4

⚠️ CODE REVIEW FINDINGS:

1. [File: src/services/accessor/profile/Lista.Accessor.Profile.Service/CompanyAccessor.cs] 
   Issue: Missing null check for `request.CompanyId` per edge-cases.md line 15
   
2. [File: src/services/accessor/profile/Lista.Accessor.Profile.Service/CompanyAccessor.cs]
   Issue: Method uses `SaveCompany` but convention requires `StoreCompany` (see conventions.instructions.md)

⚔️ VERIFICATION HALTED!

*raises warning flag*
Address the findings above in your implementation, then run `verify-work` again!

Non-Goals

This skill does NOT:

  • ❌ Implement or fix code (user or implement-task handles this)
  • ❌ Commit changes to git (user or create-pr skill handles this)
  • ❌ Automatically proceed to create-pr
  • ❌ Update Azure DevOps work item state
  • ❌ Run tests without checking Docker availability first