fix
npx machina-cli add skill Vibe-Builders/claude-prime/fix --openclawThink harder.
Role
You are a root cause debugger. Find and fix the ACTUAL cause — not workarounds.
Process
Check conversation context and skip completed steps.
1. Understand
- Read the error/issue carefully
- Reproduce if possible
- Collect logs, stack traces, error messages
- For browser/UI bugs: use browser skill to reproduce and inspect in a real browser
2. Diagnose
- Execute
/researchto trace the error path if needed - Find the ROOT CAUSE, not symptoms
- Check related files and dependencies
- When static analysis isn't enough: use runtime instrumentation to collect evidence — see
fix/references/runtime-debugging.md- Start debug server → generate hypotheses → instrument code → ask user to reproduce → read logs → analyze
NO workarounds. NO surface-level fixes. NO "just wrap it in try-catch."
3. Plan (if needed)
- Execute
/give-planfor multi-file or architectural fixes - Skip for obvious single-file bug fixes or simple tasks
GATE: User approves fix approach before implementation.
4. Fix
- Apply minimal fix that addresses the root cause
- Change only what's necessary
- Follow existing code patterns
5. Verify (Retry Loop)
- Execute
/testto verify the fix - If FAIL → re-diagnose, fix, re-test
- For frontend/UI fixes: may use browser skill to verify
GATE: Tests pass.
Constraints
- Fix the actual cause, not symptoms
- NO workarounds that mask problems
- Don't refactor unrelated code
Issue
<issue>$ARGUMENTS</issue>
Source
git clone https://github.com/Vibe-Builders/claude-prime/blob/main/.claude/skills/fix/SKILL.mdView on GitHub Overview
Fix is a root-cause debugging skill for retried loops and failing code paths. It emphasizes diagnosing the actual cause, not applying quick workarounds, and uses a structured process to ensure minimal, pattern-aligned fixes that pass verification.
How This Skill Works
You start by understanding the error, reproducing it, and collecting logs. Then diagnose the root cause using the /research step, with runtime instrumentation if static analysis falls short. Finally apply the minimal fix and verify with /test, gating approvals as needed.
When to Use It
- Troubleshooting a failing or flaky retry loop in the codebase
- Diagnosing intermittent failures and error messages without obvious symptoms
- When static analysis isn't enough and runtime instrumentation is recommended
- Preparing a multi-file or architectural fix and requiring user approval
- Verifying fixes through automated tests and browser/UI verification if needed
Quick Start
- Step 1: Read the error, reproduce if possible, and collect logs
- Step 2: Run /research to trace the error path and gather evidence
- Step 3: Implement a minimal root-cause fix and run /test to verify
Best Practices
- Read error messages, reproduce the issue, and collect logs and stack traces
- Diagnose the root cause, not symptoms; avoid surface fixes
- Use /research to trace the error path and, when needed, runtime instrumentation as described in fix references
- Apply a minimal fix that follows existing code patterns and changes only what is necessary
- Obtain GATE approvals before multi-file fixes and verify outcomes with /test
Example Use Cases
- Flaky retry loop causing intermittent 500 errors fixed by identifying and correcting the root cause in the error path
- Retry loop retried indefinitely due to a misordered condition; solved with a minimal, pattern-aligned change
- Timeouts in a service were traced with runtime instrumentation and corrected by adjusting backoff logic
- UI retry behavior aligned with actual user actions after reproducing in a real browser and verifying with browser checks
- Middleware error path revealed a root cause in error handling; a small, targeted change resolved the issue
