Files

Zhongwei Li befff05008 Initial commit

2025-11-30 09:01:45 +08:00

13 KiB

Raw Permalink Blame History

description, allowed-tools, model, argument-hint

description	allowed-tools	model	argument-hint
Rapidly fix small bugs and minor improvements in development environment with dynamic problem detection and parallel quality verification. Use for well-understood (≥80%) small-scale fixes in development only. NOT for production emergencies (use /hotfix instead). Applies Occam's Razor (simplest solution), Progressive Enhancement (CSS-first), and TIDYINGS (clean as you go). 開発環境で小さなバグの修正や軽微な改善を素早く実行。よく理解された小規模な修正に使用。本番緊急時は/hotfixを使用。	Bash(git diff:), Bash(git ls-files:), Bash(npm test:), Bash(npm run), Bash(npm run:), Bash(yarn run), Bash(yarn run:), Bash(pnpm run), Bash(pnpm run:), Bash(bun run), Bash(bun run:), Bash(ls:), Edit, MultiEdit, Read, Grep, Task	inherit	[bug or issue description]

/fix - Advanced Quick Fix with Dynamic Analysis

Purpose

Rapidly fix small bugs with dynamic problem detection, confidence scoring, and parallel quality verification.

Usage

For simple fixes that don't require extensive planning or research.

Dynamic Problem Context

Recent Changes Analysis

!`git diff HEAD~1 --stat`

Test Status Check

!`find . -name "*test*" -o -name "*spec*"`

Quality Commands Discovery

!`npm run || yarn run || pnpm run || bun run`

!`git ls-files --modified`

Phase 0.5: Deep Root Cause Analysis

Purpose: Identify the true root cause, not just surface symptoms, before attempting fixes.

Step 1: Explore Bug Context

Use Explore agent for rapid context gathering (30 seconds):

Task({
  subagent_type: "Explore",
  thoroughness: "quick",
  description: "Explore bug-related code",
  prompt: `
Bug: "${bugDescription}"

Find (30s):
1. Related files: mentioned, recent changes, similar patterns [✓]
2. Dependencies: interacting components, shared utilities [✓]
3. Recent commits (last 10), PRs [✓]
4. Similar past issues [→]

Return: Findings with file:line evidence. Mark: [✓/→/?].
  `
})

Step 2: Root Cause Analysis

Use root-cause-reviewer for deep analysis:

Task({
  subagent_type: "root-cause-reviewer",
  description: "Identify root cause",
  prompt: `
Bug: "${bugDescription}"
Context: ${exploreFindings}

5 Whys analysis:
1. Symptom vs root cause (dig 5x deep) [✓]
2. Similar bugs: pattern or isolated? [→]
3. Fix strategy: symptom or root cause? [→]
4. Impact: affected areas, side effects, tests [→]

Return: Root cause [✓] with evidence, fix approach [→], prevention [→], risks [?].
  `
})

Benefits of Phase 0.5

Before (without Phase 0.5):
  - Quick surface-level fix
  - May miss root cause
  - Bug might recur elsewhere
  - Confidence: 0.75-0.85

After (with Phase 0.5):
  - Root cause identified
  - Comprehensive fix
  - Prevention measures included
  - Confidence: 0.95+

Cost-Benefit Analysis

Aspect	Cost	Benefit
Time	+30-60s	Fewer iterations, no recurrence
Expense	+$0.05-0.15	Permanent fix vs temporary patch
Quality	None	Root cause resolution
Prevention	None	Similar bugs prevented

ROI: High - One-time investment prevents multiple future fixes.

Hierarchical Fix Process

Phase 1: Problem Analysis (Enhanced with Phase 0.5 - Confidence Target: 0.95+)

Integration: Uses findings from Phase 0.5 for higher confidence decisions.

Dynamic root cause identification:

Issue Detection: Analyze symptoms and error patterns
- Enhanced: Leverage Explore findings for context
Impact Scope: Determine affected files and components
- Enhanced: Use dependency analysis from Phase 0.5
Root Cause: Identify why not just what
- Enhanced: Apply root-cause-reviewer insights
Fix Strategy: Choose simplest effective approach
- Enhanced: Based on root cause, not symptoms
- Enhanced: Include prevention measures from Phase 0.5

Phase 2: Targeted Implementation (Confidence Target: 0.90)

Apply fix with confidence scoring:

High Confidence (>0.9): Direct fix implementation
Medium (0.7-0.9): Add defensive checks
Low (<0.7): Research before fixing

Phase 3: Parallel Verification (Confidence Target: 0.95)

Simultaneous quality checks:

// Execute in parallel, not sequentially
const checks = [
  Bash({ command: "npm test -- --findRelatedTests" }),
  Bash({ command: "npm run lint -- --fix" }),
  Bash({ command: "npm run type-check" })
];

Enhanced Execution with Confidence Metrics

1. Dynamic Problem Analysis

Issue Classification

[TEMPLATE: Problem Analysis Section]
Category: [UI/Logic/Performance/Type/Test]
- **Symptoms**: [Observable behavior]
- **Evidence**: [Error messages, test failures]
- **Root Cause**: [Why it's happening]
- **Confidence**: [0.0-1.0 score]

Recent Context

git log --oneline -5 --grep="fix"

2. Smart Implementation

Fix Approach Selection

[TEMPLATE: Fix Strategy Section]
Selected Approach: [Name]
- **Implementation**: [How to fix]
- **Rationale**: [Why this approach]
- **Risk Level**: [Low/Medium/High]
- **Alternative**: [If confidence < 0.8]

Progressive Enhancement Check

[TEMPLATE: CSS-First Analysis]
- Can CSS solve this? [Yes/No]
- If Yes: [CSS solution]
- If No: [Why JS is needed]

3. Real-time Verification

Parallel Quality Execution

Run quality checks in parallel:

npm test -- --findRelatedTests | grep -E "PASS|FAIL" | head -5
npm run lint | tail -3
npm run type-check | tail -3

Regression Check

npm test -- --onlyChanged | grep -E "Test Suites:"

Advanced TodoWrite Integration

Real-time tracking with confidence scoring:

[TODO LIST TEMPLATE]
Fix: [Issue Description]
Analysis Phase (Confidence: X.XX)
1. ✅ Problem identified [C: 0.95] ✓ 2 min
2. ❌ Root cause analysis [C: 0.85] ⏱️ Active
3. ⏳ Fix strategy selection [C: pending]

## Implementation Phase
4. ⏳ Apply targeted fix [C: pending]
5. ⏳ Update related tests [C: pending]

## Verification Phase
6. ⏳ Run quality checks (parallel) [C: pending]
7. ⏳ Confirm fix resolves issue [C: pending]

## Metrics
- 🎯 Problem Clarity: 85%
- 🔧 Fix Confidence: 90%
- ✅ Tests Passing: 12/12
- 📊 Coverage Impact: +2%

Definition of Done with Confidence Scoring

[COMPLETION CHECKLIST TEMPLATE]
Problem Resolution
- ✅ Root cause identified [C: 0.92]
- ✅ Fix addresses cause not symptom [C: 0.88]
- ✅ Minimal complexity solution [C: 0.95]

### Quality Metrics
- ✅ All related tests pass [C: 1.0]
- ✅ No new lint errors [C: 0.98]
- ✅ Type safety maintained [C: 1.0]
- ✅ No regressions detected [C: 0.93]

### Code Standards
- ✅ Follows existing patterns [C: 0.90]
- ✅ Progressive Enhancement applied [C: 0.87]
- ✅ Documentation updated if needed [C: 0.85]

### Overall Confidence: 0.91 (HIGH)
Status: ✅ FIX COMPLETE

If any metric has confidence < 0.8, continue improving.

Progress Display

Quick Fix Progress Visualization

Display fix progress with confidence tracking:

📋 Fix Task: Button Alignment Issue
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Analysis:      [████████████] Complete (Confidence: 92%)
Implementation: [████████░░░░] 70% In progress...
Verification:   [░░░░░░░░░░░░] Waiting
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Current: Editing CSS file...
Changes: 2 files | 15 lines | Elapsed: 3 min

Parallel Quality Checks

Show concurrent quality verification:

🔍 Quality Verification (Parallel Execution):
├─ 🧪 Tests     [████████████] ✅ 12/12 passing
├─ 🔍 Lint      [████████████] ✅ No new issues
├─ 🔷 Types     [████████████] ✅ All valid
└─ 📊 Regress   [████████░░░░] ⏳ Checking...

Fix Confidence: 90% | Status: Safe

Fix Mode Indicators

⚡ Quick fix mode
Focus: Minimal change for maximum impact
Scope: 2 files | Risk: Low | Time: < 5 min

Enhanced Output Format

[FIX SUMMARY TEMPLATE]
🔧 Fix Summary
Problem
- **Issue**: [Description]
- **Category**: [UI/Logic/Performance/Type]
- **Root Cause**: [Why it happened]
- **Confidence**: 0.XX

### Solution Applied
- **Approach**: [Fix strategy used]
- **Files Modified**:
  - `path/to/file.ts` - [What changed]
  - `path/to/test.ts` - [Test updates]
- **Progressive Enhancement**: [CSS-first approach used?]

### Verification Results
- **Tests**: ✅ 15/15 passing
- **Lint**: ✅ No issues
- **Types**: ✅ All valid
- **Coverage**: 82% (+2%)
- **Regression**: None detected

### Confidence Metrics
| Stage | Confidence | Result |
|-------|------------|--------|
| Analysis | 0.88 | Root cause found |
| Implementation | 0.92 | Clean fix applied |
| Verification | 0.95 | All checks pass |
| **Overall** | **0.91** | **HIGH CONFIDENCE** |

### Performance Impact

    ```bash
    git diff HEAD --stat | tail -3
    ```

- Lines changed: XX
- Files affected: X
- Complexity: Low

Decision Framework

When to Use `/fix` (Confidence Check)

✅ High Confidence Scenarios (>0.85)
- Single-file fixes with clear scope
- Test failures with obvious causes
- Typo and naming corrections
- CSS-solvable UI issues
- Simple logic errors
- Configuration updates

⚠️ Medium Confidence (0.6-0.85)
- Two-file coordinated changes
- Missing error handling
- Performance optimizations
- State management fixes

❌ Low Confidence (<0.6) - Use different command
- Multi-file refactoring → /code
- Unknown root cause → /research
- New features → /think → /code
- Production issues → /hotfix

Automatic Command Switching

If confidence drops below 0.6 during analysis:

[LOW CONFIDENCE ALERT TEMPLATE]
Issue: Fix scope exceeds /fix capabilities

Recommended action:
- For investigation: /research
- For planning: /think
- For implementation: /code

Switch command? (Y/n)

Example Usage with Confidence

High Confidence Fix

/fix "Fix button alignment issue in header"
# Confidence: 0.92 - CSS-first solution available

Medium Confidence Fix

/fix "Resolve state update not triggering re-render"
# Confidence: 0.75 - May need investigation

Auto-escalation Example

/fix "Optimize database query performance"
# Confidence: 0.45 - Suggests /research → /think instead

Next Steps Based on Outcome

Success Path (Confidence >0.9)

Document learnings
Add regression test
Update related documentation

Partial Success (Confidence 0.7-0.9)

Review with /research for completeness
Consider follow-up /fix for remaining issues

Escalation Path (Confidence <0.7)

[WORKFLOW RECOMMENDATION TEMPLATE]
Based on analysis, suggesting:
1. /research - Investigate deeper
2. /think - Plan comprehensive solution
3. /code - Implement with full TDD

Advanced Features

Pattern Learning

Track successful fixes for similar issues:

git log --grep="fix" --oneline | grep -i "[similar keyword]" | head -3

Auto-discovery

Find related issues that might need fixing:

grep -r "TODO\|FIXME\|HACK" --include="*.ts" --include="*.tsx" | head -5

Quality Trend

Monitor fix impact on codebase health:

npm run lint | grep -E "problems\|warnings"

Applied Principles

This command applies Progressive Enhancement from @~/.claude/rules/development/PROGRESSIVE_ENHANCEMENT.md:

CSS-first approach for UI issues
Root cause analysis
Minimal complexity solutions

Command Differentiation Guide

Use `/fix` when

🔧 Working in development environment
Issue is small and well-understood
Fix can be tested normally
No production emergency
Standard deployment timeline is acceptable

Use `/hotfix` instead when

🚨 Production is down or impaired
Security vulnerability in production
Users are actively affected
Immediate deployment required
Emergency response needed

Key Difference

fix: Rapid development fixes with normal testing/deployment
hotfix: Emergency production fixes requiring immediate action

Applied Development Principles

Occam's Razor

@~/.claude/rules/reference/OCCAMS_RAZOR.md - "Entities should not be multiplied without necessity"

Application in fixes:

Minimal Change: Simplest change that fixes the issue
Avoid Restructuring: Don't change surrounding code
Minimize Side Effects: Fix stays focused on the problem
Avoid Over-generalization: Solve just the current issue

TIDYINGS

@~/.claude/rules/development/TIDYINGS.md - Clean as you go