fix

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ask user whether to skip.

Prerequisites: MUST READ .claude/skills/shared/understand-code-first-protocol.md AND .claude/skills/shared/evidence-based-reasoning-protocol.md before executing.

• docs/project-reference/domain-entities-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)

Evidence Gate: MANDATORY IMPORTANT MUST — every claim, finding, and recommendation requires file:line proof or traced evidence with confidence percentage (>80% to act, <80% must verify first).

Process Discipline: MUST READ .claude/skills/shared/red-flag-stop-conditions-protocol.md — STOP after 3+ failed fix attempts, when fixes reveal new problems in different places.

External Memory: For complex or lengthy work (research, analysis, scan, review), write intermediate findings and final results to a report file in plans/reports/ — prevents context loss and serves as deliverable.

Quick Summary

Goal: Analyze issues and intelligently route to the best-matching specialized fix command (fix-ci, fix-fast, fix-hard, fix-ui, etc.).

Workflow:

1. Check — Look for existing plan; if found, route to /code <plan>
2. Classify — Match issue type (type errors, UI, CI, logs, tests, general)
3. Route — Delegate to specialized fix variant based on classification

Key Rules:

• Debug Mindset is non-negotiable: every claim needs traced proof with file:line evidence
• Never assume first hypothesis is correct — verify with actual code traces
• Parent skill for all fix-* variants; routes based on issue keywords

Frontend/UI Context (if applicable)

When this task involves frontend or UI changes, MUST READ .claude/skills/shared/ui-system-context.md and the following docs:

• Component patterns: docs/project-reference/frontend-patterns-reference.md
• Styling/BEM guide: docs/project-reference/scss-styling-guide.md
• Design system tokens: docs/project-reference/design-system/README.md

Variant Decision Guide

Debug Mindset (NON-NEGOTIABLE)

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

• Do NOT assume the first hypothesis is correct — verify with actual code traces
• Every root cause claim must include file:line evidence
• If you cannot prove a root cause with a code trace, state "hypothesis, not confirmed"
• Question assumptions: "Is this really the cause?" → trace the actual execution path
• Challenge completeness: "Are there other contributing factors?" → check related code paths
• No "should fix it" without proof — verify the fix addresses the traced root cause

⚠️ MANDATORY: Confidence & Evidence Gate

MANDATORY IMPORTANT MUST declare Confidence: X% with evidence list + file:line proof for EVERY claim. 95%+ recommend freely | 80-94% with caveats | 60-79% list unknowns | <60% STOP — gather more evidence.

Analyze issues and route to specialized fix command: $ARGUMENTS

⚠️ MANDATORY: Plan Before Fix (NON-NEGOTIABLE)

MANDATORY IMPORTANT MUST — Before routing to ANY fix variant, you MUST have a validated plan. This applies whether running standalone or within a workflow.

If no plan exists, you MUST create todo tasks for and execute these steps IN ORDER before proceeding to fix:

1. /plan — Create an implementation plan for the fix (root cause analysis + fix approach + affected files)
2. /plan-review — Auto-review the plan for validity, correctness, and best practices
3. /plan-validate — Validate plan with critical questions interview (get user confirmation)

Only after plan is validated → proceed to fix routing below.

If a plan already exists (markdown plan file in plans/) → skip to fix routing.

Why: Fixes without plans lead to incomplete root cause analysis, missed side effects, and regressions. Planning forces the AI to think before acting.

Decision Tree

1. Check for existing plan:

• If markdown plan exists → /code <path-to-plan>
• If NO plan exists → STOP. Run /plan → /plan-review → /plan-validate first (see section above)

2. Route by issue type (only after plan exists):

A) Type Errors (keywords: type, typescript, tsc, type error) → /fix-types

B) UI/UX Issues (keywords: ui, ux, design, layout, style, visual, button, component, css, responsive) → /fix-ui <detailed-description>

C) CI/CD Issues (keywords: github actions, pipeline, ci/cd, workflow, deployment, build failed) → /fix-ci <github-actions-url-or-description>

D) Test Failures (keywords: test, spec, jest, vitest, failing test, test suite) → /fix-test <detailed-description>

E) Log Analysis (keywords: logs, error logs, log file, stack trace) → /fix-logs <detailed-description>

F) Multiple Independent Issues (2+ unrelated issues in different areas) → /fix-parallel <detailed-description>

G) Complex Issues (keywords: complex, architecture, refactor, major, system-wide, multiple components) → /fix-hard <detailed-description>

H) Simple/Quick Fixes (default: small bug, single file, straightforward) → /fix-fast <detailed-description>

Notes

• detailed-description = enhanced prompt describing issue in detail
• If unclear, ask user for clarification before routing
• Can combine routes: e.g., multiple type errors + UI issue → /fix-parallel

⚠️ MANDATORY: Post-Fix Verification

After EVERY fix, you MUST run /prove-fix to verify correctness.

/prove-fix builds code proof traces (stack-trace-style) per change, assigns confidence percentages, and produces a ship/block verdict. This is non-negotiable — never skip it. If confidence < 80% on any change, return to investigation.

IMPORTANT Task Planning Notes (MUST FOLLOW)

• Always plan and break work into many small todo tasks
• Always add a final review todo task to verify work quality and identify fixes/enhancements

Workflow Recommendation

IMPORTANT MUST: If you are NOT already in a workflow, use AskUserQuestion to ask the user:

1. Activate bugfix workflow (Recommended) — scout → investigate → debug → plan → plan-review → plan-validate → fix → prove-fix → review → test
2. Execute /fix directly — still requires /plan → /plan-review → /plan-validate before fixing (enforced by Plan Before Fix gate above)

Next Steps

MANDATORY IMPORTANT MUST after completing this skill, use AskUserQuestion to recommend:

• "/prove-fix (Recommended)" — Prove fix correctness with code traces
• "/test" — Run tests to verify fix
• "Skip, continue manually" — user decides

Closing Reminders

MANDATORY IMPORTANT MUST break work into small todo tasks using TaskCreate BEFORE starting. MANDATORY IMPORTANT MUST validate decisions with user via AskUserQuestion — never auto-decide. MANDATORY IMPORTANT MUST add a final review todo task to verify work quality.