reality-verification
The reality-verification skill guides developers through structured before-and-after testing workflows for bug fixes and issue diagnosis. Use it when reproducing failures, verifying fixes, diagnosing issues, performing reality checks, or detecting test anti-patterns like mock-heavy tests that lack actual assertions. It maps common goal keywords to specific reproduction commands and provides documentation templates for tracking issue resolution across development stages.
git clone --depth 1 https://github.com/tzachbon/smart-ralph /tmp/reality-verification && cp -r /tmp/reality-verification/plugins/ralph-specum/skills/reality-verification ~/.claude/skills/reality-verificationSKILL.md
# Reality Verification
For fix goals: reproduce the failure BEFORE work, verify resolution AFTER.
## Goal Detection
Classify user goals to determine if diagnosis is needed. See `references/goal-detection-patterns.md` for detailed patterns.
**Quick reference:**
- Fix indicators: fix, repair, resolve, debug, patch, broken, failing, error, bug
- Add indicators: add, create, build, implement, new
- Conflict resolution: If both present, treat as Fix
## Command Mapping
| Goal Keywords | Reproduction Command |
|---------------|---------------------|
| CI, pipeline | `gh run view --log-failed` |
| test, tests | project test command |
| type, typescript | `pnpm check-types` or `tsc --noEmit` |
| lint | `pnpm lint` |
| build | `pnpm build` |
| E2E, UI | Playwright MCP browser tools |
| API, endpoint | WebFetch tool |
For E2E/deployment verification, use MCP tools (Playwright MCP browser tools for UI, WebFetch tool for APIs).
## BEFORE/AFTER Documentation
### BEFORE State (Diagnosis)
Document in `.progress.md` under `## Reality Check (BEFORE)`:
```markdown
## Reality Check (BEFORE)
**Goal type**: Fix
**Reproduction command**: `pnpm test`
**Failure observed**: Yes
**Output**:
```
FAIL src/auth.test.ts
Expected: 200
Received: 401
```
**Timestamp**: 2026-01-16T10:30:00Z
```
### AFTER State (Verification)
Document in `.progress.md` under `## Reality Check (AFTER)`:
```markdown
## Reality Check (AFTER)
**Command**: `pnpm test`
**Result**: PASS
**Output**:
```
PASS src/auth.test.ts
All tests passed
```
**Comparison**: BEFORE failed with 401, AFTER passes
**Verified**: Issue resolved
```
## VF Task Format
Add as task 4.3 (after PR creation) for fix-type specs:
```markdown
- [ ] 4.3 VF: Verify original issue resolved
- **Do**:
1. Read BEFORE state from .progress.md
2. Re-run reproduction command: `<command>`
3. Compare output with BEFORE state
4. Document AFTER state in .progress.md
- **Verify**: `grep -q "Verified: Issue resolved" ./specs/<name>/.progress.md`
- **Done when**: AFTER shows issue resolved, documented in .progress.md
- **Commit**: `chore(<name>): verify fix resolves original issue`
```
## Test Quality Checks
When verifying test-related fixes, check for mock-only test anti-patterns. See `references/mock-quality-checks.md` for detailed patterns.
**Quick reference red flags:**
- Mock declarations > 3x real assertions
- Missing import of actual module under test
- All assertions are mock interaction checks (toHaveBeenCalled)
- No integration tests
- Missing mock cleanup (afterEach)
## Why This Matters
| Without | With |
|---------|------|
| "Fix CI" spec completes but CI still red | CI verified green before merge |
| Tests "fixed" but original failure unknown | Before/after comparison proves fix |
| Silent regressions | Explicit failure reproduction |
| Manual verification required | Automated verification in workflow |
| Tests pass but only test mocks | Tests verify real behavior, not mock behavior |
| False sense of security from green tests | Confidence that tests catch real bugs |This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.
This skill should be used when the user asks to "add MCP server", "integrate MCP", "configure MCP in plugin", "use .mcp.json", "set up Model Context Protocol", "connect external service", mentions "${CLAUDE_PLUGIN_ROOT} with MCP", or discusses MCP server types (SSE, stdio, HTTP, WebSocket). Provides comprehensive guidance for integrating Model Context Protocol servers into Claude Code plugins for external tool and service integration.
This skill should be used when the user asks about "plugin settings", "store plugin configuration", "user-configurable plugin", ".local.md files", "plugin state files", "read YAML frontmatter", "per-project plugin settings", or wants to make plugin behavior configurable. Documents the .claude/plugin-name.local.md pattern for storing plugin-specific configuration with YAML frontmatter and markdown content.
This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDE_PLUGIN_ROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs guidance on plugin directory layout, manifest configuration, component organization, file naming conventions, or Claude Code plugin architecture best practices.
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
Generate a custom checklist for the current feature based on user requirements.