Verification
Skill VoDaiLocz/kilo-kit-mcp/skills/kilo-kit/debugging/verification
An MCP server for safer coding agents: skill routing, C4 workflow gates, memory checks, and verification before completion.
npx -y skills add VoDaiLocz/kilo-kit-mcp --skill verificationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 24 stars24 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Comprehensive fix verification methodology to ensure bugs are truly fixed. Use after implementing any bug fix to verify it works and hasn't caused regressions. Keywords: verify, confirm, test, validate, check, ensure, regression, fixed
SKILL.md
9.3 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it
β Fix Verification Skill
Philosophy: A bug isn't fixed until it's verified. Twice.
When to Use
Use this skill when:
- You've implemented a bug fix
- Someone else's fix needs verification
- Deploying a fix to production
- Bug was high-impact and needs thorough verification
- Previous fixes for this bug have failed
Do NOT use this skill when:
- Just exploring code (no fix yet)
- Bug is trivial (e.g., typo fix)
- Running standard CI (automated verification)
Prerequisites
Before starting:
- Fix has been implemented
- You know the expected behavior
- You can reproduce the original bug (or have a failing test)
- You have access to test environment
Process
Phase 1: DIRECT VERIFICATION π―
Goal: Confirm the fix addresses the exact reported issue.
Steps:
-
Recreate the Original Bug Scenario
Exact steps that caused the bug: 1. [step 1] 2. [step 2] 3. [step 3] Expected result: [what should happen] Previous result: [what was happening - the bug] -
Execute Test with Fix Applied
- Follow exact same steps
- Document actual result
- Compare to expected
-
Verify the FIX, Not Just Absence of Error
β "It doesn't crash anymore" (incomplete) β "It returns the expected user object with correct fields" (complete) -
Test Multiple Times
- Run at least 3 times
- Note any inconsistency
Verification Checklist:
- Original bug scenario no longer produces error
- Expected behavior now occurs
- Result is consistent across multiple runs
- All variations of bug scenario work
Phase 2: EDGE CASE VERIFICATION π²
Goal: Ensure fix works for edge cases and variations.
Steps:
-
Identify Edge Cases
edge_cases: boundary_values: - Empty input - Maximum length input - Minimum valid input - Just over limit - Just under limit special_inputs: - Null/undefined - Special characters - Unicode/emoji - Numbers as strings - Whitespace only state_variations: - First time user - Returning user - Admin user - Concurrent users - High load -
Create Edge Case Matrix
Edge Case Input Expected Actual Pass? Empty "" Error msg Max length 1000 chars Success Special chars "<>&" Escaped -
Test Each Edge Case
- Document results
- Note any failures
Edge Case Checklist:
- All boundary values tested
- Special inputs handled correctly
- Different user states work
- Concurrent access works (if applicable)
Phase 3: REGRESSION TESTING π
Goal: Ensure fix hasn't broken anything else.
Steps:
-
Identify Affected Areas
affected_areas: directly_affected: - The fixed function/component - Its callers - Its dependencies indirectly_affected: - Related features - Shared utilities used - Configuration changes -
Run Targeted Tests
# Run tests for affected module npm test -- --grep "auth" # Run integration tests npm run test:integration -
Run Full Test Suite
# Ensure no regressions anywhere npm test -
Manual Smoke Test
- Test main user flows
- Pay attention to anything that feels different
Regression Checklist:
- All unit tests pass
- All integration tests pass
- Smoke test passes
- No new warnings in logs
- Performance not degraded
Phase 4: NEGATIVE TESTING π«
Goal: Verify error handling and failure modes.
Steps:
-
Test Invalid Inputs
- What happens with bad data?
- Are errors handled gracefully?
- Are error messages helpful?
-
Test Failure Scenarios
failure_scenarios: - Database connection lost - API timeout - Invalid credentials - Missing permissions - Disk full -
Test Recovery
- Does system recover after failure?
- Is data consistent after recovery?
Negative Testing Checklist:
- Invalid inputs produce clear errors
- System fails gracefully
- Recovery works correctly
- No security information leaked in errors
Phase 5: ENVIRONMENT VERIFICATION π
Goal: Ensure fix works across all environments.
Steps:
-
Test Across Environments
Environment Tested Result Notes Local dev CI/CD Staging Production -
Test Across Configurations
- Different browsers (if applicable)
- Different OS (if applicable)
- Different database sizes
- Different load levels
-
Test Across User Types
- Regular users
- Admin users
- New users
- Users with existing data
Environment Checklist:
- Works in development
- Works in staging
- Works in production (or production-like)
- Works across configurations
Phase 6: DOCUMENTATION & SIGN-OFF π
Goal: Document verification and get sign-off.
Steps:
-
Complete Verification Report
## Fix Verification Report **Bug ID:** [ID] **Fix Description:** [brief description] **Verified By:** [name] **Date:** [date] ### Direct Verification - [x] Original bug no longer occurs - [x] Expected behavior confirmed ### Edge Cases - [x] [edge case 1] - PASS - [x] [edge case 2] - PASS ### Regression Testing - [x] Unit tests: 100% pass - [x] Integration tests: 100% pass - [x] Smoke test: PASS ### Environment Testing - [x] Local: PASS - [x] Staging: PASS - [x] Production: [pending/pass] ### Sign-off - [ ] Developer - [ ] QA (if applicable) - [ ] Stakeholder (for critical bugs) -
Update Bug Tracking
- Change status to "Verified Fixed"
- Add verification notes
- Link to any new tests added
-
Add/Update Tests
- Ensure test exists for this bug
- Test should fail without fix, pass with fix
Quick Verification Checklist
For simpler bugs, use this shortened checklist:
## Quick Verification
- [ ] Original bug scenario fixed
- [ ] Edge cases work
- [ ] All tests pass
- [ ] No new warnings/errors
- [ ] Reviewed by another person (if critical)
Verification Decision Tree
Fix Implemented
β
βΌ
βββββββββββββββββββ
β Does original β
β scenario work? β
ββββββββββ¬βββββββββ
YES β NO β Back to debugging
βΌ
βββββββββββββββββββ
β Edge cases β
β work? β
ββββββββββ¬βββββββββ
YES β NO β Expand fix
βΌ
βββββββββββββββββββ
β All tests β
β pass? β
ββββββββββ¬βββββββββ
YES β NO β Fix regressions
βΌ
βββββββββββββββββββ
β Works in all β
β environments? β
ββββββββββ¬βββββββββ
YES β NO β Environment-specific fix
βΌ
VERIFIED β
Guidelines
DO β
- Verify the fix, not just absence of error
- Test edge cases thoroughly
- Document your verification
- Run the full test suite
- Have someone else verify critical fixes
DON'T β
- Assume fix works because code looks right
- Skip edge case testing
- Forget to check for regressions
- Test only in development environment
- Skip documentation
Common Pitfalls
"Works on My Machine"
Problem: Fix works locally but fails elsewhere.
Prevention:
- Always test in staging
- Use same data/config as production
- Test with production-like load
"Fixed the Symptom, Not the Bug"
Problem: Error is gone but behavior is still wrong.
Prevention:
- Verify POSITIVE behavior, not just absence of error
- Compare to expected behavior documentation
- Test the complete user flow
"Created a New Bug"
Problem: Fix introduced a regression.
Prevention:
- Always run full test suite
- Manual smoke test of related features
- Review changes with fresh eyes
Success Criteria
Before marking bug as fixed:
- Original issue verified fixed
- All edge cases pass
- No regression in tests
- Works in all environments
- Verification documented
- Test added to prevent recurrence
Related Skills
skills/kilo-kit/debugging/systematic/- For finding the bugskills/kilo-kit/debugging/root-cause/- For understanding why it happenedskills/kilo-kit/quality/testing/- For writing better tests
Fix Verification Skill v1.0.0 β Verified twice, deployed once