Chain of Verification (CoVe) Skill

Description

This skill applies the Chain-of-Verification (CoVe) methodology to systematically validate outputs before presenting them. It decomposes claims into verifiable components, checks each independently, and flags anything unverified.

Instructions

When generating any output that requires accuracy (code, technical claims, data analysis), apply the CoVe process:

Step 1: Generate Initial Response

Produce the initial answer as normal.

Step 2: Extract Verifiable Claims

Break the response into individual, testable claims:

Copy
## Claims to Verify

1. "React.memo prevents re-renders when props haven't changed"
2. "useCallback is needed for functions passed to memoized children"
3. "The dependency array in useEffect runs on mount and when deps change"
4. "This regex pattern matches all valid email addresses"
5. "The time complexity of this algorithm is O(n log n)"

Step 3: Generate Verification Questions

For each claim, create a specific verification question:

Copy
## Verification Questions

1. Does React.memo do a shallow comparison by default? What about deep objects?
2. What happens if you pass an inline function to a React.memo component without useCallback?
3. Does useEffect with an empty dependency array ONLY run on mount, or also on unmount?
4. Does the regex handle edge cases: plus signs, dots in local part, new TLDs?
5. What is the best, worst, and average case? Is the analysis considering the sort step?

Step 4: Answer Verification Questions Independently

Answer each question using ONLY verified knowledge:

Copy
## Verification Results

1. VERIFIED — React.memo does shallow comparison. For deep objects, need custom comparator.
   Correction needed: Add note about shallow comparison limitation.

2. VERIFIED — Without useCallback, the function reference changes every render,
   defeating React.memo. Original claim is accurate.

3. CORRECTION NEEDED — useEffect cleanup runs on unmount AND before re-running.
   Original statement was incomplete.

4. CORRECTION NEEDED — Regex fails on "[email protected]" and "[email protected]".
   Need to update pattern.

5. VERIFIED — The sort is O(n log n) and dominates. Overall complexity claim is correct.

Step 5: Revise Output

Update the original response based on verification findings:

Copy
## Revised Output

### Changes Made:
- [Claim 3] Added clarification about cleanup behavior
- [Claim 4] Updated regex to handle plus addressing and multi-level TLDs

### Confidence Level: HIGH (4/5 claims verified, 1 corrected)

Applying CoVe to Code

For generated code, verify:

Copy
## Code Verification Checklist

- [ ] Function signatures match their usage sites
- [ ] All imports reference real modules/packages
- [ ] Error handling covers the actual error types thrown
- [ ] Types are consistent across function boundaries
- [ ] Edge cases: null, undefined, empty array, empty string
- [ ] Async/await is used correctly (no floating promises)
- [ ] The code actually compiles (check for syntax errors)

Rules

• Apply CoVe to ALL technical claims, not just code
• Each claim must be verified INDEPENDENTLY — do not use other unverified claims as evidence
• If a claim cannot be verified from known knowledge, mark it as UNVERIFIED with a note
• Always show the verification process, not just the final result
• Corrections should update the original content, not just add footnotes
• Minimum 3 verification questions per response (for non-trivial outputs)
• For code: always check that imports exist, types match, and edge cases are handled
• Flag confidence level: HIGH (all verified), MEDIUM (some unverified), LOW (corrections needed)

Examples

User: Explain how JavaScript closures work Action: Generate explanation, extract 4-5 technical claims, verify each with code examples, correct any inaccuracies

User: Write a binary search implementation Action: Write code, verify: correct boundary handling, handles empty array, handles single element, returns correct index vs -1

User: Is it safe to use parseInt without a radix? Action: Generate answer, verify the claim about default radix behavior, check edge cases ("0x" prefix, leading zeros), cite spec behavior