hotfix

Manages post-merge bug fixes with TDD, GitHub issue gating, and scoped review criteria.

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/asengardeon/btt-sdd-pipeline --skill hotfix-asengardeon
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: hotfix
Source: https://github.com/asengardeon/btt-sdd-pipeline/tree/main/plugins/btt-sdd/skills/hotfix
Command: npx skills add https://github.com/asengardeon/btt-sdd-pipeline --skill hotfix-asengardeon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a bug is found in production after a spec has already been merged, or a small improvement arrives with no originating spec, teams need a lightweight path that skips PRD/TRD creation without skipping rigor. This Skill formalizes that post-merge correction flow inside an SDD pipeline. ## Core Features & Use Cases - Scoped correction workflow: Handles post-merge bugs and small spec-less improvements without generating PRD or TRD documents, while keeping TDD and code review mandatory. - Objective review criteria: Decides which reviews run (code review always; QA, security, and SRE based on explicit criteria) and records skipped reviews with standardized headings. - GitHub issue gate: Requires a confirmed or newly created GitHub issue (with milestone or spec label linkage) before any branch is created. - Use Case: A production bug is reported in a feature whose spec was merged last week. Use this Skill to create the issue, branch from main, implement the fix with TDD, run code review plus applicable reviews, and record everything in the related spec's artifacts. ## Quick Start Use the hotfix skill to fix the production login timeout bug reported after the auth spec was merged, creating the GitHub issue and running the applicable reviews.

Frequently Asked Questions about hotfix

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

FAQPage Schema
How do I handle a production bug after a spec was already merged?▼

Use the hotfix workflow: confirm or create a GitHub issue, branch from main with a hotfix/ or fix/ prefix, implement with strict TDD, and run code review plus any applicable QA, security, or SRE reviews. Results are recorded in the related spec's artifacts with a hotfix-<date> history entry.

When should I use a hotfix flow instead of creating a full PRD?▼

Use hotfix for concrete post-merge bugs or small low-risk improvements without an originating spec. If the change introduces new acceptance criteria, architectural decisions, or more than one slice of effort, it is a feature and should go through the normal PRD pipeline.

Which reviews are required for a hotfix?▼

Code review is always mandatory. QA runs when there is a concrete acceptance criterion to validate, security runs when the diff touches authentication, authorization, session management, or sensitive data, and SRE runs only for infrastructure, CI/CD, or dependency changes.

Can a hotfix proceed without a GitHub issue?▼

No. A confirmed or newly created GitHub issue is a mandatory gate before any branch is created, even for a one-line fix. If no GitHub remote is configured or authenticated, the process stops until the user sets up git remote and gh auth.

What happens if a hotfix grows in scope during execution?▼

If the correction grows in scope or risk mid-execution, the process stops and migrates to the full pipeline flow with PRD and TRD instead of continuing as a hotfix. This prevents the lightweight path from being used to skip rigor on larger changes.