skill-forge-hitl

Name: skill-forge-hitl
Author: WrathZA

17stars0forks

How to install skill-forge-hitl?

wrathza/skillforge/skill-forge-hitl

$npx -y skills add WrathZA/skillforge --skill skill-forge-hitl

Installs into the current project.

Summary

Apply a numbered list one item at a time — status board upfront, per-item approve/skip, approve-all mode, commits after each approved item. Use when stepping through skill-forge-judge findings or any numbered changes. Triggers: apply these, go through each one, apply improvements

Files · 1

View on GitHub

SKILL.md

1	# HITL Loop
2
3	Throw the lasso, pull it tight, move to the next. One change at a time, one approval at a time — no bundling, no skipping ahead.
4
5	Core question for every item: What's the smallest change that makes this finding false? Apply only that — nothing more. Verify: if any part of the change were removed, would the finding still be true? If yes, the change is too large.
6
7	## Workflow
8
9	### 1 — Read the list
10
11	Parse the numbered improvement list from context. If there are multiple lists or it's unclear which to apply, ask once before starting — not mid-loop. If the response does not resolve the ambiguity, stop: "Still unclear which list to apply — please re-invoke with the target list quoted directly."
12
13	If improvements reference specific files, verify they still exist and haven't changed substantially since the evaluation. If a target file is missing or heavily modified, note it at the top of the board: "⚠ Target may be stale — <file> has changed since evaluation. Items may not apply cleanly. (c)ontinue / (Q)uit?"
14
15	If items have dependencies (item 3 requires item 1), note the dependency at the board level. Do not re-order — apply in sequence and mark dependent items `[○]` if their prerequisite was skipped.
16
17	Check git status before showing the board. If the working directory is not a git repo, note this at the top of the board and skip all commit steps:
18
19	```
20	ℹ No git repo — changes will be applied but not committed.
21	```
22
23	Display the full status board upfront: all items with `[ ]` markers, then `(A)pprove all / (s)tart` options. Symbols: `[ ]` pending, `[✓]` done, `[→]` in progress, `[–]` skipped, `[○]` obsolete.
24
25	If the user responds `A`: apply and commit all items in sequence, then show the final board per step 3.
26
27	If the user responds `s`: begin the per-item loop from item #1.
28
29	### 2 — Apply each one
30
31	Repeat for every item in order:
32
33	a. Announce — show `─── #N of M ───` and the full improvement description.
34
35	b. Apply
36
37	If the smallest change requires touching more than one logical unit (function, section, rule), the improvement is under-scoped — note this in the change summary and apply only the first unit.
38
39	Do not touch adjacent code, bundle items, or anticipate the next improvement. If applying this item overlaps with a later item (same lines, same function), apply only what's needed now and note the overlap in the change summary.
40
41	If an improvement requires non-edit actions (adding a dependency, creating a new file, running a command), describe the action in the change summary and let the user decide whether to perform it.
42
43	c. Show the change
44	```
45	Changed: <file>:<lines> — <one-line description>
46	<concise diff summary — not the full file>
47	```
48
49	d. Ask
50	```
51	(a)pprove, (r)evise, (s)kip, (o)bsolete, (A)ccept-all, (k)skip-all, (Q)uit?
52	```
53
54	Wait. Do not advance until the user responds. Any input not in the table below is a stop signal: show the current board and ask "Stop here? (y) to pause, (c)ontinue from #N?"
55
56	\| Key \| Commit? \| Mark \| Advance to \| Special \|
57	\|-----\|---------\|------\|------------\|---------\|
58	\| `a` \| yes \| `[✓]` \| next item \| — \|
59	\| `r` \| no \| — \| re-apply same item \| Collect guidance, re-show. After 3 revisions: "Revised N times — skip and file a separate issue, or keep going?" \|
60	\| `s` \| no \| `[–]` \| next item \| Note reason if given \|
61	\| `o` \| no \| `[○]` \| next item \| Already done / no longer applies / impossible \|
62	\| `A` \| yes (current + all remaining) \| `[✓]` each \| final board \| Skip per-item prompts for remaining \|
63	\| `k` \| no \| `[–]` current + all remaining \| final board \| — \|
64	\| `Q` \| no \| `[–]` all remaining (current unchanged) \| final board \| — \|
65
66	e. Update the board — after each decision, show the current state of all items using the status symbols. For accept-all (`A`): skip intermediate board updates — apply and commit each remaining item silently, then show the final board once in step 3.
67
68	### 3 — Done
69
70	When all items are processed, show the final board and a one-liner: `HITL complete. Applied: N Skipped: M Revised then applied: P`
71
72	## Commits
73
74	If in a git repo: commit after each approved change, before advancing to the next item:
75
76	```bash
77	git add <changed files>
78	```
79	```bash
80	git commit -m "<short description of this improvement>"
81	```
82
83	If commit fails (pre-commit hook, empty diff): show the error, fix the issue, re-stage, and retry. If the fix changes the applied improvement, re-show the diff and re-ask for approval — do not silently commit a different change than what was shown.
84
85	If not in a git repo: skip commits entirely. Mark each app

People who liked this also viewed

6 picks

Type

skill-forge-hitl

17stars0forks

View on GitHub

How to install skill-forge-hitl?

wrathza/skillforge/skill-forge-hitl

$npx -y skills add WrathZA/skillforge --skill skill-forge-hitl

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# HITL Loop
2
3	Throw the lasso, pull it tight, move to the next. One change at a time, one approval at a time — no bundling, no skipping ahead.
4
5	Core question for every item: What's the smallest change that makes this finding false? Apply only that — nothing more. Verify: if any part of the change were removed, would the finding still be true? If yes, the change is too large.
6
7	## Workflow
8
9	### 1 — Read the list
10
11	Parse the numbered improvement list from context. If there are multiple lists or it's unclear which to apply, ask once before starting — not mid-loop. If the response does not resolve the ambiguity, stop: "Still unclear which list to apply — please re-invoke with the target list quoted directly."
12
13	If improvements reference specific files, verify they still exist and haven't changed substantially since the evaluation. If a target file is missing or heavily modified, note it at the top of the board: "⚠ Target may be stale — <file> has changed since evaluation. Items may not apply cleanly. (c)ontinue / (Q)uit?"
14
15	If items have dependencies (item 3 requires item 1), note the dependency at the board level. Do not re-order — apply in sequence and mark dependent items `[○]` if their prerequisite was skipped.
16
17	Check git status before showing the board. If the working directory is not a git repo, note this at the top of the board and skip all commit steps:
18
19	```
20	ℹ No git repo — changes will be applied but not committed.
21	```
22
23	Display the full status board upfront: all items with `[ ]` markers, then `(A)pprove all / (s)tart` options. Symbols: `[ ]` pending, `[✓]` done, `[→]` in progress, `[–]` skipped, `[○]` obsolete.
24
25	If the user responds `A`: apply and commit all items in sequence, then show the final board per step 3.
26
27	If the user responds `s`: begin the per-item loop from item #1.
28
29	### 2 — Apply each one
30
31	Repeat for every item in order:
32
33	a. Announce — show `─── #N of M ───` and the full improvement description.
34
35	b. Apply
36
37	If the smallest change requires touching more than one logical unit (function, section, rule), the improvement is under-scoped — note this in the change summary and apply only the first unit.
38
39	Do not touch adjacent code, bundle items, or anticipate the next improvement. If applying this item overlaps with a later item (same lines, same function), apply only what's needed now and note the overlap in the change summary.
40
41	If an improvement requires non-edit actions (adding a dependency, creating a new file, running a command), describe the action in the change summary and let the user decide whether to perform it.
42
43	c. Show the change
44	```
45	Changed: <file>:<lines> — <one-line description>
46	<concise diff summary — not the full file>
47	```
48
49	d. Ask
50	```
51	(a)pprove, (r)evise, (s)kip, (o)bsolete, (A)ccept-all, (k)skip-all, (Q)uit?
52	```
53
54	Wait. Do not advance until the user responds. Any input not in the table below is a stop signal: show the current board and ask "Stop here? (y) to pause, (c)ontinue from #N?"
55
56	\| Key \| Commit? \| Mark \| Advance to \| Special \|
57	\|-----\|---------\|------\|------------\|---------\|
58	\| `a` \| yes \| `[✓]` \| next item \| — \|
59	\| `r` \| no \| — \| re-apply same item \| Collect guidance, re-show. After 3 revisions: "Revised N times — skip and file a separate issue, or keep going?" \|
60	\| `s` \| no \| `[–]` \| next item \| Note reason if given \|
61	\| `o` \| no \| `[○]` \| next item \| Already done / no longer applies / impossible \|
62	\| `A` \| yes (current + all remaining) \| `[✓]` each \| final board \| Skip per-item prompts for remaining \|
63	\| `k` \| no \| `[–]` current + all remaining \| final board \| — \|
64	\| `Q` \| no \| `[–]` all remaining (current unchanged) \| final board \| — \|
65
66	e. Update the board — after each decision, show the current state of all items using the status symbols. For accept-all (`A`): skip intermediate board updates — apply and commit each remaining item silently, then show the final board once in step 3.
67
68	### 3 — Done
69
70	When all items are processed, show the final board and a one-liner: `HITL complete. Applied: N Skipped: M Revised then applied: P`
71
72	## Commits
73
74	If in a git repo: commit after each approved change, before advancing to the next item:
75
76	```bash
77	git add <changed files>
78	```
79	```bash
80	git commit -m "<short description of this improvement>"
81	```
82
83	If commit fails (pre-commit hook, empty diff): show the error, fix the issue, re-stage, and retry. If the fix changes the applied improvement, re-show the diff and re-ask for approval — do not silently commit a different change than what was shown.
84
85	If not in a git repo: skip commits entirely. Mark each app

People who liked this also viewed

6 picks

Type