530 lines
13 KiB
Markdown
530 lines
13 KiB
Markdown
---
|
|
description: >
|
|
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を使用。
|
|
allowed-tools: 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
|
|
model: inherit
|
|
argument-hint: "[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
|
|
|
|
```bash
|
|
!`git diff HEAD~1 --stat`
|
|
```
|
|
|
|
### Test Status Check
|
|
|
|
```bash
|
|
!`find . -name "*test*" -o -name "*spec*"`
|
|
```
|
|
|
|
### Quality Commands Discovery
|
|
|
|
```bash
|
|
!`npm run || yarn run || pnpm run || bun run`
|
|
```
|
|
|
|
### Related Files Detection
|
|
|
|
```bash
|
|
!`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):
|
|
|
|
```typescript
|
|
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:
|
|
|
|
```typescript
|
|
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
|
|
|
|
```yaml
|
|
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:
|
|
|
|
1. **Issue Detection**: Analyze symptoms and error patterns
|
|
- **Enhanced**: Leverage Explore findings for context
|
|
2. **Impact Scope**: Determine affected files and components
|
|
- **Enhanced**: Use dependency analysis from Phase 0.5
|
|
3. **Root Cause**: Identify why not just what
|
|
- **Enhanced**: Apply root-cause-reviewer insights
|
|
4. **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:
|
|
|
|
```typescript
|
|
// 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
|
|
|
|
```markdown
|
|
[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
|
|
|
|
```bash
|
|
git log --oneline -5 --grep="fix"
|
|
```
|
|
|
|
### 2. Smart Implementation
|
|
|
|
#### Fix Approach Selection
|
|
|
|
```markdown
|
|
[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
|
|
|
|
```markdown
|
|
[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:
|
|
|
|
```bash
|
|
npm test -- --findRelatedTests | grep -E "PASS|FAIL" | head -5
|
|
npm run lint | tail -3
|
|
npm run type-check | tail -3
|
|
```
|
|
|
|
#### Regression Check
|
|
|
|
```bash
|
|
npm test -- --onlyChanged | grep -E "Test Suites:"
|
|
```
|
|
|
|
## Advanced TodoWrite Integration
|
|
|
|
Real-time tracking with confidence scoring:
|
|
|
|
```markdown
|
|
[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
|
|
|
|
```markdown
|
|
[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:
|
|
|
|
```markdown
|
|
📋 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:
|
|
|
|
```markdown
|
|
🔍 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
|
|
|
|
```markdown
|
|
⚡ Quick fix mode
|
|
Focus: Minimal change for maximum impact
|
|
Scope: 2 files | Risk: Low | Time: < 5 min
|
|
```
|
|
|
|
## Enhanced Output Format
|
|
|
|
```markdown
|
|
[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)
|
|
|
|
```markdown
|
|
✅ 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:
|
|
|
|
```markdown
|
|
[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
|
|
|
|
```markdown
|
|
/fix "Fix button alignment issue in header"
|
|
# Confidence: 0.92 - CSS-first solution available
|
|
```
|
|
|
|
### Medium Confidence Fix
|
|
|
|
```markdown
|
|
/fix "Resolve state update not triggering re-render"
|
|
# Confidence: 0.75 - May need investigation
|
|
```
|
|
|
|
### Auto-escalation Example
|
|
|
|
```markdown
|
|
/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)
|
|
|
|
```markdown
|
|
[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:
|
|
|
|
```bash
|
|
git log --grep="fix" --oneline | grep -i "[similar keyword]" | head -3
|
|
```
|
|
|
|
### Auto-discovery
|
|
|
|
Find related issues that might need fixing:
|
|
|
|
```bash
|
|
grep -r "TODO\|FIXME\|HACK" --include="*.ts" --include="*.tsx" | head -5
|
|
```
|
|
|
|
### Quality Trend
|
|
|
|
Monitor fix impact on codebase health:
|
|
|
|
```bash
|
|
npm run lint | grep -E "problems\|warnings"
|
|
```
|
|
|
|
## Applied Principles
|
|
|
|
This command applies Progressive Enhancement from [@~/.claude/rules/development/PROGRESSIVE_ENHANCEMENT.md](~/.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](~/.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](~/.claude/rules/development/TIDYINGS.md) - Clean as you go
|
|
|
|
Application in fixes:
|
|
|
|
- **Clean Only What You Touch**: Improve only fix-related code
|
|
- **Leave It Better**: Better than before, not perfect
|
|
- **Incremental Improvement**: Don't try to fix everything at once
|
|
- **Boy Scout Rule**: Leave it cleaner than you found it
|