varunk130 Incremental Verification
What This Skill Enables
An agent that confirms correctness at every micro-step - after every function, every file change, every integration point - rather than building a large body of code and hoping it works. Without this skill, agents produce code that looks plausible but fails at runtime, and bugs compound silently until the system is too broken to debug efficiently.
Core Competencies
1. The Verify-As-You-Go Loop
After every meaningful change, run a verification:
Write code → Verify → Commit → Next change
↑ |
└────────────────────────────┘
Verification methods by change type:
| Change | Verification |
|---|---|
| New function | Run its unit test |
| Modified function | Run existing tests + new test for the change |
| New API endpoint | Send a test request, check response shape and status |
| UI component | Render it, check the DOM/accessibility tree |
| Configuration change | Restart the service, verify it loads without errors |
| Database migration | Run the migration, verify the schema matches expectations |
2. Build Verification
Before writing new code, confirm the current state is clean:
- Run the full test suite - all green? Proceed
- Run the build command - compiles without errors? Proceed
- Run the linter - no new violations? Proceed
If any of these fail before you've made changes, flag it immediately. Do not write code on top of a broken foundation.
3. Assertion Density
Write assertions liberally during development:
- After fetching data: assert it has the expected shape
- After transforming data: assert the output matches expectations
- After calling an external service: assert the response status is successful
- After state transitions: assert the new state is valid
These can be formal tests or temporary debug assertions that get removed later - the point is catching errors at the moment they occur, not ten steps later.
4. Regression Detection
After every change, verify nothing broke:
CHANGED: src/auth/validate.ts
VERIFICATION STEPS:
1. Run unit tests for auth module → ✅ 12/12 pass
2. Run integration tests touching auth → ✅ 5/5 pass
3. Run full test suite → ✅ 147/147 pass
4. No new linter warnings → ✅
RESULT: Change verified. Committing.
If a test fails that you didn't expect, stop. Don't fix it silently. Understand why the change affected that test.
5. End-of-Task Verification
When a task (not just a single change) is complete:
- Run the complete test suite
- Verify the acceptance criteria from the task definition
- Check for console errors, warnings, or deprecation notices
- Review your own diff - does anything look unintended?
- If the task has UI, visually verify the result
Behavioral Rules
- Never stack unverified changes - Verify change A before starting change B
- Test failures are stop signals - Don't proceed past a red test; fix it first
- The build must always be green - A broken build is the highest-priority fix
- Unexpected passes are suspicious - A test that passes when you expected it to fail needs investigation
- Commit verified work frequently - Every green state is a checkpoint worth saving
Failure Modes
| Failure | Symptom | Correction |
|---|---|---|
| Writing 500 lines then testing | Cascade of errors with unclear root cause | Verify after every function or small logical change |
| Ignoring test failures | Broken tests accumulate; suite becomes unreliable | Fix every failure immediately or investigate why |
| Only testing happy path | Code works for valid input, crashes on edge cases | Test error conditions and boundary values at each step |
| Skipping build verification | Runtime errors that the compiler would have caught | Run build after every file modification |
| Not checking your own diff | Accidental debug code, TODO comments, or unrelated changes ship | Review your diff before marking any task complete |