review-validate

Files (1)

• SKILL.md

SKILL.md (first lines)

# Review Validate

Validate identified bugs or issues from the current conversation context. For each issue: confirm it's real via a sub-agent, write a surface test that demonstrates the problem, then present all findings for user review before applying any fixes.

## Inputs

This skill assumes the issues/bugs to validate are already present in the conversation context — from a prior bug-detector run, code review, discussion, or any other source. Parse the context for actionable issues: each needs at minimum a description and a location (file path or component).

If the context contains no identifiable issues, ask the user what they'd like validated.

## Phase 1: Validate Each Issue (Parallel Sub-Agents)

Spawn one sub-agent per issue (Agent tool, **foreground**, `model: "sonnet"`, run in parallel where independent) to determine whether the issue is real.

**Sub-agent prompt structure:**

```
You are validating whether a reported bug/issue is real. Your job is to confirm or reject it by reading the relevant code and tracing the logic.

REPORTED ISSUE:
<issue description, file path, line numbers if available>

INSTRUCTIONS:
1. Read the relevant source code
2. Trace the execution path that would trigger this issue
3. Determine if the issue is:
   - CONFIRMED: The bug is real and can be triggered under described conditions
   - REJECTED: The code is actually correct — explain why the report is wrong
   - PARTIAL: The issue exists but is less severe or narrower than reported
4. If CONFIRMED or PARTIAL, describe:
   - The exact trigger conditions
   - What currently happens (the bug)
   - What should happen (expected behavior)
   - Whether this is a behavioral change (existing consumers rely on current behavior) or a pure bug (current behavior violates documented/intended contract)

IMPORTANT:
- Do NOT fix the issue — only validate it
- Be skeptical — many reported issues turn out to be false positives
- Check for existing tests that cover this path — if tests pass and assert the current behavior, this might be intentional
- Note if the "fix" would change observable behavior for existing consumers
```

## Phase 2: Surface Test Writing

For each CONFIRMED or PARTIAL issue from Phase 1, attempt to write a surface test that demonstrates the bug. Follow the `surface-testing` skill philosophy — test through the public interface only.

**For each confirmed issue, evaluate testability:**

1. **Can it be tested through the surface?** Identify the public entry point (HTTP endpoint, exported function, CLI command) that exercises the buggy code path.
2. **Write the test.** The test should:
   - FAIL with the current buggy behavior (proving the bug exists)
   - PASS once the fix is applied (defining the correct behavior)
   - Follow all testing patterns from CLAUDE.md
3. **If untestable from the surface**, write a temporary internal unit test to validate the bug instead. This test:
   - Proves the bug is real by exercising the internal code path directly
   - Is clearly marked as temporary (prefix test name with `Temporary_`)
   - MUST be removed before any commits — the orchestration agent owns cleanup
   - Should be noted in the findings report so the user knows it was used

Run the test to confirm it fails as expected. If it passes (bug not reproducible via surface or internal test), downgrade the issue to UNCONFIRMED and note the discrepancy.

## Phase 3: Findings Report

Present all findings to the user before any fixes are applied.

```
## Bug Validation Report

### Confirmed & Test-Proven: N

<for each confirmed issue with a failing test>
#### <N>. <issue title>
- **Status**: Confirmed
- **File**: <path:line>
- **Trigger**: <how to trigger the bug>
- **Test**: <test file path> — currently FAILS as expected
- **Behavioral change?**: <yes/no — does the fix change what existing consumers observe?>
- **Proposed fix**: <1-2 sentence description of the fix approach>
<end for each>

### Confirmed via Temporary Internal Test: N

<for each confirmed issue proven with a temporary internal test>
#### <N>. <issue title>
- **Status**: Confirmed (via temporary internal test — will be removed before commit)
- **File**: <path:line>
- **Temp test**: <test file path> — currently FAILS as expected
- **Why no surface test**: <explanation — e.g., internal optimization, unreachable via public API>
- **Proposed fix**: <1-2 sentence description of the fix approach>
- **Recommendation**: <expose observability so a surface test can replace this / accept without permanent test>
<end for each>

### Rejected: N

<for each rejected issue>
#### <N>. <issue title>
- **Status**: Rejected
- **Reason**: <why the reported issue is not actually a bug>
<end for each>

### Behavioral Changes Requiring Review: N

<issues where the fix would change observable behavior>
#### <N>. <issue title>
- **Current behavior**: <what consumers see today>
- **Proposed behavior**: <what they'd see after fix>
- **Risk**: <who might be affected>
```

**After presenting the report, proceed to fix all confirmed issues automatically.** Only pause to ask the user when:
- The fix changes observable behavior for existing consumers (behavioral change)
- Multiple fix approaches exist and the choice affects a function/method signature or interface design

## Phase 4: Apply Fixes

For each confirmed fix:

1. Apply the fix
2. Run the proving test (surface or temporary internal) — confirm it now PASSES

From thrawn01/claude-dotfiles, MIT.

More from thrawn01/claude-dotfiles