hotfix

Coordinate emergency hotfix workflows with severity assessment and approval gates.

Updated Mar 28, 2026
One-click install
npx skills add https://github.com/scomofo/dragon-forge --skill hotfix-scomofo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: hotfix
Source: https://github.com/scomofo/dragon-forge/tree/main/.agents/skills/hotfix
Command: npx skills add https://github.com/scomofo/dragon-forge --skill hotfix-scomofo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The hotfix skill solves the problem of getting a production-safe, minimally invasive fix shipped quickly when normal sprint processes can’t keep up, while still preserving traceability from severity assessment through approvals and post-deploy verification.

Core Features & Use Cases

  • Emergency fix workflow with guardrails: Forces an explicit severity assessment (S1/S2 vs S3+) and redirects to the normal bug-fix workflow for lower severities.
  • Auditable hotfix record creation: Drafts a structured hotfix record (problem, root cause, fix, testing, approvals, rollback plan) and writes it under production/hotfixes.
  • Branching and controlled deployment: Optionally creates a dedicated hotfix branch, coordinates required sign-offs (lead-programmer, qa-tester, producer), and enforces a QA re-entry gate (smoke vs targeted team QA vs full QA).

Quick Start

Use /hotfix and provide the bug id or a short description so the workflow can assess severity, create the hotfix record, and proceed through branch creation, approvals, and QA gating.

Frequently Asked Questions about hotfix

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I ship a production hotfix without losing an audit trail?▼

A production hotfix with an audit trail requires a structured workflow that creates a hotfix record capturing the problem, root cause, fix, testing, approvals, and rollback plan before deployment. This ensures traceability while enabling rapid delivery.

When should I use an emergency hotfix workflow instead of a normal bug fix?▼

Use an emergency hotfix workflow for S1 or S2 production incidents requiring rapid deployment to restore functionality. Lower severity issues (S3 and below) should be redirected to the normal bug-fix workflow to avoid unnecessary production branches.

What approvals are required for deploying an emergency hotfix?▼

Deploying an emergency hotfix requires sign-offs from lead-programmer, qa-tester, and producer roles. The workflow also enforces a QA re-entry gate to determine if smoke, targeted team QA, or full QA testing is needed post-deploy.

Can I create a dedicated git branch for a production incident response?▼

Yes, you can optionally create a dedicated hotfix branch during an incident response. The workflow handles branch creation to ensure the minimally invasive change is isolated and tracked from severity assessment through post-deploy verification.

How do I verify a hotfix post-deploy after an emergency release?▼

Verify a hotfix post-deploy by using follow-up commands to check the fix after the release management workflow completes. The hotfix record is updated with root-cause analysis and tests, satisfying the mandatory post-deployment verification step.