gh-thkt-claude-config/commands/hotfix.md

description, allowed-tools, model, argument-hint

description	allowed-tools	model	argument-hint
Emergency fixes for critical production issues ONLY. For production-impacting problems, security vulnerabilities, or immediate deployment needs. 5-min triage, 15-min fix, 10-min test. Minimal process overhead with required rollback plan. NOT for development fixes (use /fix instead). High severity (critical/security) only. 本番環境の緊急対応が必要な重大な問題を修正。本番影響、セキュリティ脆弱性、即座のデプロイが必要な場合のみ。	Bash(git diff:*), Bash(git status:*), Bash(git log:*), Bash(git show:*), Edit, MultiEdit, Read, Write, Glob, Grep, Task	inherit	[critical issue description]

/hotfix - Emergency Hot Fix

Purpose

Apply critical fixes to production issues with minimal process overhead while maintaining quality.

Usage

For urgent production bugs requiring immediate attention.

Workflow

Streamlined critical path: Quick analysis → Fix → Test → Deploy readiness

Safety Checks

MANDATORY: Before proceeding with hotfix:

1. Impact Assessment: Is production truly affected?
2. Rollback Ready: Note current version/commit
3. Minimum Fix: Scope the smallest possible change
4. Team Alert: Notify stakeholders
5. Test Plan: Define critical path testing

⚠️ WARNING: Production changes carry high risk. Double-check everything.

Execution Steps

1. Triage (5 min)

• Confirm production impact
• Identify root cause
• Define minimum fix

2. Fix (15 min)

• Apply focused change
• Stability > Elegance
• Document technical debt

3. Test (10 min)

• Verify issue resolved
• Check critical paths only
• No comprehensive testing

4. Deploy Ready

• Clear commit message
• Rollback documented
• Team notified

TodoWrite Integration

Emergency tracking (keep it simple):

# HOTFIX: [Critical issue]
1. ⏳ Triage & Assess
2. ⏳ Emergency Fix
3. ⏳ Critical Testing

Output Format

## 🚨 HOTFIX Summary
- Critical Issue: [Description]
- Severity: [Critical/High]
- Root Cause: [Brief explanation]

## Changes Made
- Files Modified: [List with specific changes]
- Risk Assessment: [Low/Medium/High]
- Rollback Plan: [How to revert if needed]

## Verification
- Issue Resolved: [Yes/No]
- Tests Passed: [List of tests]
- Side Effects: [None/Listed]

## Follow-up Required
- Technical Debt: [What needs cleanup]
- Full Testing: [What needs comprehensive testing]
- Documentation: [What needs updating]

When to Use

• Production is down
• Security vulnerabilities
• Data corruption risks
• Critical user-facing bugs
• Regulatory compliance issues

When NOT to Use

• Feature requests
• Performance improvements
• Refactoring
• Non-critical bugs

Core Principles

• Fix first, perfect later
• Document everything
• Test the critical path
• Plan for rollback
• Schedule follow-up

Example Usage

/hotfix "Payment processing returning 500 errors"
/hotfix "User data exposed in API response"
/hotfix "Login completely broken after deployment"

Post-Hotfix Actions

1. Immediate: Deploy and monitor
2. Within 24h: Run /reflect to document lessons
3. Within 1 week: Use full workflow to properly fix
4. Update: Add test cases to prevent recurrence

Command Differentiation Guide

Use /hotfix when

• 🚨 Production environment is affected
• System is down or severely impaired
• Security vulnerability discovered
• Data integrity at risk
• Regulatory compliance issue
• Users cannot complete critical actions

Use /fix instead when

• 🔧 Working in development environment
• Issue is minor or cosmetic
• No immediate user impact
• Can wait for normal deployment cycle
• Testing can follow standard process

Key Difference

• hotfix: Emergency production fixes with immediate deployment need
• fix: Rapid development fixes following normal deployment flow