hotfix

Name: hotfix
Author: tranhieutt

69stars41forks

How to install hotfix?

tranhieutt/software_development_department/hotfix

$npx -y skills add tranhieutt/software_development_department --skill hotfix

Installs into the current project.

Summary

Executes a hotfix workflow: creates a hotfix branch, applies the targeted fix, runs verification, and prepares release artifacts. Use when a critical production bug needs immediate patching or when the user mentions hotfix or emergency fix.

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	> Explicit invocation only: This skill should only run when the user explicitly requests it with `/hotfix`. Do not auto-invoke based on context matching.
4
5	1. Assess the emergency — Read the bug description or ID. Determine severity:
6	- S1 (Critical): Product unplayable, data loss, security vulnerability — hotfix immediately
7	- S2 (Major): Significant feature broken, workaround exists — hotfix within 24 hours
8	- If severity is S3 or lower, recommend using the normal bug fix workflow instead
9
10	2. Create the hotfix record at `production/hotfixes/hotfix-[date]-[short-name].md`:
11
12	```markdown
13	## Hotfix: [Short Description]
14	Date: [Date]
15	Severity: [S1/S2]
16	Reporter: [Who found it]
17	Status: IN PROGRESS
18
19	### Problem
20	[Clear description of what is broken and the user impact]
21
22	### Root Cause
23	[To be filled during investigation]
24
25	### Fix
26	[To be filled during implementation]
27
28	### Testing
29	[What was tested and how]
30
31	### Approvals
32	- [ ] Fix reviewed by lead-programmer
33	- [ ] Regression test passed (qa-engineer)
34	- [ ] Release approved (producer)
35
36	### Rollback Plan
37	[How to revert if the fix causes new issues]
38	```
39
40	3. Create the hotfix branch (if git is initialized):
41	```
42	git checkout -b hotfix/[short-name] [release-tag-or-main]
43	```
44
45	4. Investigate and implement the fix — Focus on the minimal change that resolves the issue. Do NOT refactor, clean up, or add features alongside the hotfix.
46
47	5. Validate the fix — Run targeted tests for the affected system. Check for regressions in adjacent systems.
48
49	6. Update the hotfix record with root cause, fix details, and test results.
50
51	6b. Collect approvals — Use the Task tool to request sign-off:
52	- `subagent_type: lead-programmer` — Review the fix for correctness and side effects
53	- `subagent_type: qa-engineer` — Run targeted regression tests on the affected system
54	- `subagent_type: producer` — Approve deployment timing and communication plan
55
56	7. Output a summary with: severity, root cause, fix applied, testing status, and what approvals are still needed before deployment.
57
58	### Rules
59	- Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring, no "while we're here" changes
60	- Every hotfix must have a rollback plan documented before deployment
61	- Hotfix branches merge to BOTH the release branch AND the development branch
62	- All hotfixes require a post-incident review within 48 hours
63	- If the fix is complex enough to need more than 4 hours, escalate to technical-director for a scope decision
64
65	## Protocol
66
67	- Question: Confirms severity (S1/S2 = proceed; S3+ = defer to normal workflow)
68	- Options: Skip — severity drives path
69	- Decision: User approves fix approach before implementation begins
70	- Draft: Hotfix summary shown before committing fix
71	- Approval: "May I write to `production/hotfixes/hotfix-[date]-[name].md`?"
72
73	## Output
74
75	Deliver exactly:
76
77	- Hotfix summary: severity, root cause (1 sentence), fix applied, files changed
78	- Rollback plan: documented steps to revert if the fix causes regressions
79	- Approvals needed: list of sign-offs still outstanding before deployment
80	- Post-incident review: scheduled within 48 hours (link to `/postmortem-writing`)

People who liked this also viewed

6 picks

Type

hotfix

69stars41forks

View on GitHub

How to install hotfix?

tranhieutt/software_development_department/hotfix

$npx -y skills add tranhieutt/software_development_department --skill hotfix

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	> Explicit invocation only: This skill should only run when the user explicitly requests it with `/hotfix`. Do not auto-invoke based on context matching.
4
5	1. Assess the emergency — Read the bug description or ID. Determine severity:
6	- S1 (Critical): Product unplayable, data loss, security vulnerability — hotfix immediately
7	- S2 (Major): Significant feature broken, workaround exists — hotfix within 24 hours
8	- If severity is S3 or lower, recommend using the normal bug fix workflow instead
9
10	2. Create the hotfix record at `production/hotfixes/hotfix-[date]-[short-name].md`:
11
12	```markdown
13	## Hotfix: [Short Description]
14	Date: [Date]
15	Severity: [S1/S2]
16	Reporter: [Who found it]
17	Status: IN PROGRESS
18
19	### Problem
20	[Clear description of what is broken and the user impact]
21
22	### Root Cause
23	[To be filled during investigation]
24
25	### Fix
26	[To be filled during implementation]
27
28	### Testing
29	[What was tested and how]
30
31	### Approvals
32	- [ ] Fix reviewed by lead-programmer
33	- [ ] Regression test passed (qa-engineer)
34	- [ ] Release approved (producer)
35
36	### Rollback Plan
37	[How to revert if the fix causes new issues]
38	```
39
40	3. Create the hotfix branch (if git is initialized):
41	```
42	git checkout -b hotfix/[short-name] [release-tag-or-main]
43	```
44
45	4. Investigate and implement the fix — Focus on the minimal change that resolves the issue. Do NOT refactor, clean up, or add features alongside the hotfix.
46
47	5. Validate the fix — Run targeted tests for the affected system. Check for regressions in adjacent systems.
48
49	6. Update the hotfix record with root cause, fix details, and test results.
50
51	6b. Collect approvals — Use the Task tool to request sign-off:
52	- `subagent_type: lead-programmer` — Review the fix for correctness and side effects
53	- `subagent_type: qa-engineer` — Run targeted regression tests on the affected system
54	- `subagent_type: producer` — Approve deployment timing and communication plan
55
56	7. Output a summary with: severity, root cause, fix applied, testing status, and what approvals are still needed before deployment.
57
58	### Rules
59	- Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring, no "while we're here" changes
60	- Every hotfix must have a rollback plan documented before deployment
61	- Hotfix branches merge to BOTH the release branch AND the development branch
62	- All hotfixes require a post-incident review within 48 hours
63	- If the fix is complex enough to need more than 4 hours, escalate to technical-director for a scope decision
64
65	## Protocol
66
67	- Question: Confirms severity (S1/S2 = proceed; S3+ = defer to normal workflow)
68	- Options: Skip — severity drives path
69	- Decision: User approves fix approach before implementation begins
70	- Draft: Hotfix summary shown before committing fix
71	- Approval: "May I write to `production/hotfixes/hotfix-[date]-[name].md`?"
72
73	## Output
74
75	Deliver exactly:
76
77	- Hotfix summary: severity, root cause (1 sentence), fix applied, files changed
78	- Rollback plan: documented steps to revert if the fix causes regressions
79	- Approvals needed: list of sign-offs still outstanding before deployment
80	- Post-incident review: scheduled within 48 hours (link to `/postmortem-writing`)

People who liked this also viewed

6 picks

Type