GeorgeQLe Investigate
Invoke as $investigate.
Use this skill when the user reports a bug, error, unexpected behavior, or provides observations/hypotheses about what they think is wrong. Validates claims against the codebase and git history before tracing to root cause.
Process
- Parse the error message, stack trace, bug description, or user observations/claims.
- Select investigation strategy from flags or auto-detection:
--ui: Visual/layout bugs — start from component tree, styles, animations, transitions, spacing, theming, skeleton/loading states, positioning. Signal words: skeleton, animation, spacing, popover, transition, theme, truncated, glitch, dead space, detached, pop-in, flickering, layout, z-index, overflow.--data: Data/state bugs — start from data pipeline, state management, timers, counters, sync logic. Signal words: countdown, percentage, usage, sync, stale, timer, refresh, reset, missing data, wrong number, out of sync, not updating, mismatch.- General (default): Errors, crashes, behavioral bugs, and anything ambiguous — start from symptom/stack trace.
- If input has signals from both UI and data, prefer data strategy — wrong data commonly manifests as a visual symptom.
- If the user provides claims or hypotheses, validate each one against the codebase and git history (
git log,git diff,git blame). Classify each as confirmed, partially correct, or not supported by evidence. Report findings before proceeding. - Trace using the selected strategy:
- UI: component tree → styles → layout → animation/transition → render lifecycle. Check CSS conflicts, missing keys, layout thrashing, transition timing.
- Data: data source → transform → store → subscription → render. Check stale closures, missing dependency arrays, incorrect comparisons, cache invalidation, timer drift.
- General: execution path from symptom to source — null/undefined, wrong types, missing env vars, stale imports, race conditions, schema mismatches.
- If the initial strategy hits a dead end, pivot to the other — a UI bug may have a data root cause, and vice versa.
- Check recent git history for changes that may have introduced the issue.
- Identify the root cause with file and line reference.
- Propose the minimal implementation plan, including files to change and tests to run.
- Permission Gate: Ask the user for explicit permission before editing files, applying patches, running write-capable generation commands, or otherwise implementing the fix. Do not implement from this skill until the user approves.
- After approval, apply the minimal fix and write or update tests.
- Run tests to verify the fix and check for regressions.
Output
- Strategy Used: UI / Data / General (auto-detected or flag-forced), whether a pivot occurred
- User Claims Validated: For each claim — verdict (confirmed/partially correct/not supported) and evidence. Skip if input was a plain error message.
- Root Cause: file:line, what's wrong, when introduced, relationship to user's theory
- Proposed Fix: files to modify, implementation outline, tests to run, and the explicit permission question
- Fix Applied: files modified, test results. Include only after the user has approved implementation.
- Prevention: what check would have caught this earlier
Constraints
- Do not refactor unrelated code.
- Validate user claims before assuming they're correct — observations are a starting point, not ground truth.
- If the root cause can't be determined, report what was ruled out.
- Do not implement fixes without explicit user permission after reporting the investigation findings and proposed fix.
- Always run tests after applying an approved fix.
Default Shipping Contract
Follow the shared shipping contract convention in CLAUDE.md.