github-issue-fix

Name: github-issue-fix
Author: BoltzmannEntropy

15stars3forks

How to install github-issue-fix?

boltzmannentropy/osxskills/github-issue-fix

$npx -y skills add BoltzmannEntropy/OSXSkills --skill github-issue-fix

Installs into the current project.

Summary

Reproduce, diagnose, fix, verify, commit, and push changes for GitHub issue reports and bug tickets. Use when the user provides a GitHub issue URL/number, asks to reproduce a reported crash or workflow failure, wants a blocker-first debugging workflow, or needs issue-linked commi

Files · 1

View on GitHub

SKILL.md

1	# GitHub Issue Reproduction And Fix Workflow
2
3	Treat the issue as the contract. Do not code until the failure mode, affected workflow, and acceptance checks are explicit.
4
5	## 1. Intake
6
7	- Read the issue directly with `gh issue view` or from the provided text.
8	- Extract the exact repository, issue number, environment, version, expected behavior, actual behavior, and any workaround.
9	- Classify severity before doing anything else.
10
11	Use this severity baseline:
12
13	- `Blocker`: crash, data loss, corrupt output, unrecoverable stuck state, app cannot relaunch, backend process leak, or a critical user flow becomes unusable.
14	- `Critical`: major feature broken without a clean workaround.
15	- `Major`: degraded behavior with a workaround.
16	- `Minor`: cosmetic or low-risk defect.
17
18	Escalate immediately to `Blocker` when the report includes any of these:
19
20	- App crashes during a normal workflow
21	- App cannot relaunch after the crash
22	- Background process remains alive and keeps a required port bound
23	- Manual terminal cleanup is required for a normal user to recover
24
25	For reports like “app crashes when switching tabs during download” and “app will not relaunch because a Python process still holds the port”, treat both as blocker conditions that must be reproduced and verified explicitly.
26
27	## 2. Reproduce Before Patching
28
29	- Check the repo status with `git status --short` and avoid mixing unrelated local changes into the bugfix.
30	- Identify the current branch and commit SHA.
31	- Run the app or service using the repo’s standard local workflow.
32	- Reproduce the failure with the exact issue steps first; only generalize after a successful reproduction.
33	- Record the smallest deterministic repro sequence in your notes.
34
35	For crash issues, always collect:
36
37	- Frontend logs or console output
38	- Backend logs
39	- Crash stack trace if available
40	- Process and port state before and after the crash
41
42	Useful commands:
43
44	```bash
45	gh issue view <number> --repo <owner>/<repo>
46	git status --short
47	git rev-parse HEAD
48	lsof -i :<port>
49	ps -Ao pid,ppid,etime,command \| rg '<process-name>'
50	```
51
52	If the issue mentions a leaked process or blocked port:
53
54	- Confirm which process owns the port before the repro.
55	- Repeat the repro until the crash happens.
56	- Confirm whether the backend process remains alive after the UI dies.
57	- Confirm whether a normal relaunch fails because the port is still occupied.
58
59	Do not claim a fix unless the original reported sequence has been reproduced or there is hard evidence that the current code already differs from the reported build.
60
61	## 3. Find The Root Cause
62
63	Trace the failing workflow end to end:
64
65	1. User action in the UI
66	2. State transition in the frontend
67	3. API call, background task, or download job
68	4. Backend handler or worker process
69	5. Cleanup path on tab switch, route change, window close, or crash
70
71	Prefer root-cause fixes over symptom masking.
72
73	Common patterns to inspect first:
74
75	- UI state changes while a long-running task still owns listeners or controllers
76	- `setState()` or notifier updates after disposal
77	- uncancelled timers, stream subscriptions, or progress listeners
78	- tab/router changes that dispose a screen while download callbacks still target it
79	- backend child process lifecycle not tied to app shutdown or crash cleanup
80	- relaunch logic that assumes the old port is free without checking process ownership
81	- error paths that skip cleanup because only the success path stops the worker
82
83	For frontend plus backend apps, verify both:
84
85	- the crash trigger
86	- the cleanup path after the trigger
87
88	The second path matters for reports where the app cannot relaunch because an orphaned Python backend still owns the port.
89
90	## 4. Implement The Smallest Defensible Fix
91
92	- Change only the code required to eliminate the root cause and make cleanup reliable.
93	- Preserve unrelated user changes in the worktree.
94	- Add or update tests when the repo has a clear testing surface.
95	- If the fix is mostly lifecycle or cleanup code, add a targeted regression test or a narrowly scoped assertion when practical.
96
97	Prefer fixes like:
98
99	- cancel subscriptions or listeners on dispose
100	- guard UI updates with lifecycle state
101	- move long-running work off the UI-critical path
102	- serialize state transitions so tab switches cannot race active downloads
103	- ensure backend shutdown runs on app close, crash recovery, and failed startup paths
104	- free or rebind ports deterministically instead of assuming process exit
105
106	Avoid:
107
108	- speculative refactors unrelated to the issue
109	- silent retries that hide the crash but leave state inconsistent
110	- “fixes” that only kill the symptom without proving cleanup correctness
111
112	## 5. Verify The Fix
113
114	Veri

People who liked this also viewed

6 picks

Type

github-issue-fix

15stars3forks

View on GitHub

How to install github-issue-fix?

boltzmannentropy/osxskills/github-issue-fix

$npx -y skills add BoltzmannEntropy/OSXSkills --skill github-issue-fix

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# GitHub Issue Reproduction And Fix Workflow
2
3	Treat the issue as the contract. Do not code until the failure mode, affected workflow, and acceptance checks are explicit.
4
5	## 1. Intake
6
7	- Read the issue directly with `gh issue view` or from the provided text.
8	- Extract the exact repository, issue number, environment, version, expected behavior, actual behavior, and any workaround.
9	- Classify severity before doing anything else.
10
11	Use this severity baseline:
12
13	- `Blocker`: crash, data loss, corrupt output, unrecoverable stuck state, app cannot relaunch, backend process leak, or a critical user flow becomes unusable.
14	- `Critical`: major feature broken without a clean workaround.
15	- `Major`: degraded behavior with a workaround.
16	- `Minor`: cosmetic or low-risk defect.
17
18	Escalate immediately to `Blocker` when the report includes any of these:
19
20	- App crashes during a normal workflow
21	- App cannot relaunch after the crash
22	- Background process remains alive and keeps a required port bound
23	- Manual terminal cleanup is required for a normal user to recover
24
25	For reports like “app crashes when switching tabs during download” and “app will not relaunch because a Python process still holds the port”, treat both as blocker conditions that must be reproduced and verified explicitly.
26
27	## 2. Reproduce Before Patching
28
29	- Check the repo status with `git status --short` and avoid mixing unrelated local changes into the bugfix.
30	- Identify the current branch and commit SHA.
31	- Run the app or service using the repo’s standard local workflow.
32	- Reproduce the failure with the exact issue steps first; only generalize after a successful reproduction.
33	- Record the smallest deterministic repro sequence in your notes.
34
35	For crash issues, always collect:
36
37	- Frontend logs or console output
38	- Backend logs
39	- Crash stack trace if available
40	- Process and port state before and after the crash
41
42	Useful commands:
43
44	```bash
45	gh issue view <number> --repo <owner>/<repo>
46	git status --short
47	git rev-parse HEAD
48	lsof -i :<port>
49	ps -Ao pid,ppid,etime,command \| rg '<process-name>'
50	```
51
52	If the issue mentions a leaked process or blocked port:
53
54	- Confirm which process owns the port before the repro.
55	- Repeat the repro until the crash happens.
56	- Confirm whether the backend process remains alive after the UI dies.
57	- Confirm whether a normal relaunch fails because the port is still occupied.
58
59	Do not claim a fix unless the original reported sequence has been reproduced or there is hard evidence that the current code already differs from the reported build.
60
61	## 3. Find The Root Cause
62
63	Trace the failing workflow end to end:
64
65	1. User action in the UI
66	2. State transition in the frontend
67	3. API call, background task, or download job
68	4. Backend handler or worker process
69	5. Cleanup path on tab switch, route change, window close, or crash
70
71	Prefer root-cause fixes over symptom masking.
72
73	Common patterns to inspect first:
74
75	- UI state changes while a long-running task still owns listeners or controllers
76	- `setState()` or notifier updates after disposal
77	- uncancelled timers, stream subscriptions, or progress listeners
78	- tab/router changes that dispose a screen while download callbacks still target it
79	- backend child process lifecycle not tied to app shutdown or crash cleanup
80	- relaunch logic that assumes the old port is free without checking process ownership
81	- error paths that skip cleanup because only the success path stops the worker
82
83	For frontend plus backend apps, verify both:
84
85	- the crash trigger
86	- the cleanup path after the trigger
87
88	The second path matters for reports where the app cannot relaunch because an orphaned Python backend still owns the port.
89
90	## 4. Implement The Smallest Defensible Fix
91
92	- Change only the code required to eliminate the root cause and make cleanup reliable.
93	- Preserve unrelated user changes in the worktree.
94	- Add or update tests when the repo has a clear testing surface.
95	- If the fix is mostly lifecycle or cleanup code, add a targeted regression test or a narrowly scoped assertion when practical.
96
97	Prefer fixes like:
98
99	- cancel subscriptions or listeners on dispose
100	- guard UI updates with lifecycle state
101	- move long-running work off the UI-critical path
102	- serialize state transitions so tab switches cannot race active downloads
103	- ensure backend shutdown runs on app close, crash recovery, and failed startup paths
104	- free or rebind ports deterministically instead of assuming process exit
105
106	Avoid:
107
108	- speculative refactors unrelated to the issue
109	- silent retries that hide the crash but leave state inconsistent
110	- “fixes” that only kill the symptom without proving cleanup correctness
111
112	## 5. Verify The Fix
113
114	Veri

People who liked this also viewed

6 picks

Type