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.