quick-fix

name	quick-fix
description	Fast workflow for small changes, bug fixes, and UI tweaks that don't require full feature development. Uses sub-agent orchestration with model selection (Sonnet 4.5 orchestrator, Haiku 4.5 workers) for efficient context management. Handles styling adjustments, minor functionality fixes, and quick improvements while maintaining project quality standards.

Quick Fix Skill

Execute small changes, bug fixes, and UI tweaks efficiently without the overhead of full feature development workflows.

When to Use This Skill

This skill should be used when:

• Making styling adjustments (colors, fonts, spacing, hover effects)
• Fixing minor bugs (broken links, non-working buttons, missing images)
• Updating text/copy across components
• Adding small UI elements (menu items, buttons)
• Making typography or layout improvements
• Applying consistent site styles to elements
• Any change that is well-scoped and doesn't require architectural planning

Do NOT use for:

• New features requiring architectural decisions
• Changes touching 5+ files with complex dependencies
• Unclear requirements needing extensive discovery
• Major refactoring or system-wide changes

Use /feature-dev for those scenarios instead.

Workflow Overview

Phase 1: Clarify (Orchestrator - Sonnet 4.5)

Parse the user's request and clarify any ambiguities before proceeding.

Actions:

1. Understand what the user wants to change/fix
2. If anything is unclear or ambiguous, ask 1-3 focused follow-up questions:
   • What specific element/component?
   • What should the behavior/appearance be?
   • Any constraints or preferences?
3. Determine change type:
   • Text-only: Content/copy changes (minimal verification)
   • Code/functional: Styling, logic, components (full verification)
4. Decide verification rigor based on change type

Critical: Do NOT guess or make assumptions. If unclear, ask. Keep questions focused since this is a quick fix.

---

Phase 2: Explore (1 Explorer Agent - Haiku 4.5)

Quickly locate relevant files and understand necessary context.

Actions:

1. Launch 1 explorer agent with focused scope:
   • Use Glob/Grep to find relevant files
   • Read 1-3 key files to understand current implementation
   • Identify any theme/config files needed
   • Check for multiple instances if consistency is required
2. Agent returns:
   • List of files to modify
   • Current implementation patterns
   • Any style/theme references
   • Potential gotchas or dependencies

Agent Configuration:

• Model: Haiku 4.5 (cost-efficient for simple exploration)
• Tools: Glob, Grep, Read
• Scope: Targeted search, not comprehensive analysis

---

Phase 3: Plan (2 Solution Agents - Haiku 4.5, in parallel)

Generate two independent solution approaches and choose the best one.

Actions:

1. Launch 2 solution agents in parallel, each creating an independent plan
2. Each agent should:
   • Propose specific changes to specific files
   • List exact edits (file:line references)
   • Identify if tests are needed (per project testing standards)
   • Note if documentation updates are required
   • Flag any risks or edge cases
3. Orchestrator reviews both plans and chooses the best based on:
   • Simplicity: Fewer changes, minimal complexity
   • MVP focus: Fastest path to working solution
   • Project principles: Follows CLAUDE.md standards
   • Risk: Lower risk of breaking changes
4. Present chosen plan to user for approval

Agent Configuration:

• Model: Haiku 4.5 (efficient for planning small changes)
• Each agent works independently (no shared context)
• Orchestrator makes final selection

---

Phase 4: Implement (1 Implementation Agent)

Execute the approved plan with appropriate quality measures.

Actions:

1. Wait for user approval of chosen plan
2. Launch 1 implementation agent to:
   • Make the approved changes
   • Write tests if warranted (follow project testing standards in .claude/modules/testing-standards.md)
   • Update documentation if needed (theme docs, style guides, etc.)
   • Follow all patterns from exploration phase
3. Agent returns summary of changes made

Agent Configuration:

• Model: Haiku 4.5 for simple changes, Sonnet 4.5 for complex logic
• Orchestrator decides which model based on change complexity
• Tools: Read, Edit, Write, Bash (for running tests)

Quality Requirements:

• Follow all coding standards in CLAUDE.md
• Use existing patterns discovered in exploration
• Write clean, readable code
• Add tests only if change warrants it per project principles

---

Phase 5: Verify (Orchestrator - Sonnet 4.5)

Run appropriate verification checks and summarize results.

Actions:

1. Determine verification level based on change type:
   • Text-only changes: Skip build (just confirm edits)
   • Code/functional changes: Run full verification
2. For code/functional changes, run:
   • npm run build (must pass - TypeScript, Next.js checks)
   • npm test (must pass - all tests)
   • Check for Tailwind class validity
   • Verify no console errors
3. If verification fails:
   • Identify the issue
   • Either fix automatically or ask user for guidance
4. Summarize what was done:
   • Files changed
   • Tests added (if any)
   • Documentation updated (if any)
   • Verification results
   • Any follow-up suggestions

Critical: All code changes MUST pass build and tests per project standards.

---

Agent Architecture

Orchestrator (Main Skill - Sonnet 4.5)

• Coordinates all phases
• Makes decisions about verification rigor
• Chooses best plan from solution agents
• Runs final verification
• Maintains conversation with user

Explorer Agent (Haiku 4.5)

• Quick targeted codebase search
• Lightweight file reading
• Pattern identification
• Returns focused findings

Solution Agents x2 (Haiku 4.5)

• Work in parallel independently
• Each proposes complete solution approach
• Orchestrator selects best based on simplicity/MVP principles

Implementation Agent (Haiku 4.5 or Sonnet 4.5)

• Executes approved plan
• Writes tests if needed
• Updates documentation if needed
• Model selection based on complexity

---

Example Usage

Example 1: Styling Adjustment

User: "Make the Save Recipe button match our site's primary button style"

Phase 1 (Clarify): Clear request, no questions needed
Phase 2 (Explore): Find SaveRecipe component, identify site button styles
Phase 3 (Plan): Two agents propose approaches, choose simpler one
Phase 4 (Implement): Apply site button classes, verify hover effects
Phase 5 (Verify): Run build, confirm styling correct

Example 2: Bug Fix

User: "The Modify Recipe button isn't working when clicked"

Phase 1 (Clarify): Ask: "What should happen when clicked?"
User: "Should open a dialog to modify the recipe"
Phase 2 (Explore): Find ModifyRecipe button, trace click handler
Phase 3 (Plan): Two solutions (fix handler vs rewire event), choose best
Phase 4 (Implement): Fix the click handler, add test
Phase 5 (Verify): Run tests, verify button works

Example 3: Typography Improvement

User: "Make the recipe description section more readable with better typography"

Phase 1 (Clarify): Ask: "Any specific font preferences or spacing guidelines?"
User: "Use our Playfair font for headings, increase line height"
Phase 2 (Explore): Find recipe description component, check theme
Phase 3 (Plan): Two approaches (inline styles vs utility classes), choose utility classes
Phase 4 (Implement): Apply typography classes, adjust spacing
Phase 5 (Verify): Build passes, visually inspect (suggest screenshot)

---

Quality Standards

Always Follow Project Standards

• Review CLAUDE.md and .claude/modules/ for standards
• Follow Next.js patterns from .claude/modules/nextjs-patterns.md
• Respect TypeScript standards (no any, explicit types)
• Use proper Supabase client patterns
• Follow testing standards when writing tests

Testing Decisions

Write tests when:

• Adding new functionality (even small)
• Fixing bugs (regression prevention)
• Changing component behavior

Skip tests for:

• Pure text/copy changes
• Simple styling adjustments
• One-off visual tweaks

Use project testing framework (Vitest) per .claude/modules/testing-standards.md.

Documentation Updates

Update documentation when:

• Modifying theme/style system
• Adding new reusable patterns
• Changing shared configuration
• Making changes that affect other developers

---

Success Criteria

✅ Change implemented as requested ✅ No TypeScript errors (build passes) ✅ All tests pass ✅ Tailwind classes valid ✅ Tests written if warranted ✅ Documentation updated if needed ✅ Follows all project standards ✅ User confirms it looks/works as expected

---

Tips for Users

Be specific when possible:

• ❌ "Make it prettier"
• ✅ "Increase padding to 16px and round corners to 8px"

Provide context for bugs:

• ❌ "This button is broken"
• ✅ "When I click Save Recipe, nothing happens - it should save to my library"

Reference existing patterns:

• ✅ "Make this match the style of our primary CTA buttons"
• ✅ "Use the same hover effect as the recipe cards"

Trust the orchestrator to ask questions:

• If something is unclear, the orchestrator will ask
• Answer clarifying questions to get better results