[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:

• Check — Look for existing plan; if found, route to /code <plan>

• Classify — Match issue type (type errors, UI, CI, logs, tests, general)

• 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

Variant Decision Guide

If the issue is... Use Why

Type errors (TS/C#) /fix-types

Specialized for type system errors

UI/visual bug /fix-ui

Includes visual comparison

CI/CD pipeline failure /fix-ci

Reads pipeline logs, understands CI context

Test failures /fix-test

Focuses on test assertions and mocking

Log-based investigation /fix-logs

Parses log files for root cause

GitHub issue with context /fix-issue

Reads issue details, links to code

Simple/obvious fix /fix-fast

Skip deep investigation

Complex/multi-file bug /fix-hard

Uses subagents for parallel investigation

Multiple independent bugs /fix-parallel

Parallel fix execution

General/unknown /fix (this skill) Routes automatically based on keywords

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

Decision Tree

1. Check for existing plan:

• If markdown plan exists → /code <path-to-plan>

2. Route by issue type:

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:

• Activate bugfix workflow (Recommended) — scout → investigate → debug → plan → fix → prove-fix → review → test

• Execute /fix directly — run this skill standalone

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.