git-discipline

Name: git-discipline
Author: UnpaidAttention

84stars18forks

How to install git-discipline?

unpaidattention/fable5-methodology/git-discipline

$npx -y skills add UnpaidAttention/fable5-methodology --skill git-discipline

Installs into the current project.

Summary

Rules for commits, branches, diffs, and history when working in a git repository — checkpoint strategy, pre-commit diff review, message format, and the hard prohibitions on destructive operations. Trigger this whenever work happens in a git repo and involves staging, committing,

Files · 1

View on GitHub

SKILL.md

1	# Git Discipline
2
3	Git is the safety net and the audit trail. Used carelessly it becomes the accident: history
4	rewritten, work destroyed, secrets published. The rules below are ordered: prohibitions first
5	because they are absolute; craft second.
6
7	## Hard prohibitions (no exceptions without explicit user instruction)
8
9	1. Never commit or push unless the user asked or their workflow clearly expects it. On a
10	long task, ask ONCE at the start: "checkpoint-commit as I go, or leave everything unstaged?"
11	If no commits are authorized, checkpoint with `git stash push -m "checkpoint: <state>"` or
12	record known-good SHAs in your notes instead.
13	2. No force pushes. No history rewrites of anything pushed (`rebase`, `commit --amend`,
14	`filter-branch` on published commits). To undo a pushed commit, use `git revert` — it
15	preserves history.
16	3. **No destructive working-tree operations without explicit confirmation in THIS
17	conversation:** `reset --hard`, `checkout -- .` over uncommitted work you didn't create,
18	`clean -fd`, branch deletion with unmerged work. Before asking, run `git status` and
19	`git stash list` and report what would be lost.
20	4. Never commit on the default branch. Branch first: `git checkout -b
21	<type>/<short-slug>` (e.g. `fix/csv-last-row`).
22	5. No secrets, ever. Before every commit, scan the staged diff for keys, tokens,
23	passwords, connection strings, and `.env` content. One match = unstage, move to env/secret
24	manager, and check whether the value was ever committed before (if yes, tell the user it
25	needs rotation — removal from HEAD does not un-leak it).
26	6. No generated junk: build artifacts, `node_modules`/`target`/`__pycache__`, editor
27	files, your own WORKING_NOTES.md. If it's generated and not ignored, fix `.gitignore` in
28	the same commit rather than committing the junk.
29
30	## Commit craft
31
32	1. Small and coherent: one logical change per commit — a commit you can describe in one
33	sentence without "and also". Mechanical rename and behavior change are two commits, so the
34	reviewer can skim one and scrutinize the other.
35	2. Stage by path, never blind: `git add src/lib/csv.ts tests/csv.test.ts` — never
36	`git add .` or `git add -A`, which are how junk, secrets, and unrelated edits get in.
37	3. Review the FULL staged diff before every commit: `git diff --staged`, read every hunk.
38	You are looking for: leftover debug prints, unrelated drive-by edits, secrets, and hunks
39	you can't explain. Any of those = fix before committing. This review is mandatory even
40	when "sure" — especially when sure.
41	4. Message format: imperative summary ≤72 chars stating the change
42	(`fix: include final row in CSV export`); body only when the WHY isn't obvious from the
43	diff — the constraint, the bug mechanism, the rejected alternative. Never narrate the
44	process ("tried X then Y").
45	5. Checkpoint rhythm (when commits are authorized): commit at every verified-green unit
46	boundary (see verification-loop). Never commit a known-red state; if you must save a red
47	work-in-progress, use a stash with a descriptive message instead.
48
49	## Recovery habits
50
51	- Before any risky operation you WERE authorized to run, note the current SHA
52	(`git rev-parse HEAD`) in your working notes — that's the rollback target.
53	- Prefer additive recovery (`revert`, new commit) over subtractive (`reset`) whenever the
54	branch may have been seen by anyone else.
55	- `git reflog` is the last-resort undo — remember it exists before declaring work lost.
56
57	## Worked example
58
59	Task: fix a bug; user said "commit as you go" at session start.
60
61	1. `git checkout -b fix/csv-last-row` (never on `main`).
62	2. Fix + regression test; `pnpm test` green.
63	3. `git add src/lib/csv.ts tests/csv.test.ts` (by path).
64	4. `git diff --staged` — review finds a `console.log(rows)` left in. Remove, re-stage, re-test.
65	5. Commit: `fix: include final row in CSV export when trailing newline absent`.
66	6. Later, a second improvement to error messages in the same file → separate commit, not
67	squashed in.
68	7. Push only because the user asked for a PR; `git push -u origin fix/csv-last-row` — no
69	force flags.
70
71	## Done when
72
73	Every commit on the branch is one sentence-sized logical change whose full staged diff you
74	read before committing; nothing was committed to the defa

People who liked this also viewed

6 picks

Type

git-discipline

84stars18forks

View on GitHub

How to install git-discipline?

unpaidattention/fable5-methodology/git-discipline

$npx -y skills add UnpaidAttention/fable5-methodology --skill git-discipline

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Git Discipline
2
3	Git is the safety net and the audit trail. Used carelessly it becomes the accident: history
4	rewritten, work destroyed, secrets published. The rules below are ordered: prohibitions first
5	because they are absolute; craft second.
6
7	## Hard prohibitions (no exceptions without explicit user instruction)
8
9	1. Never commit or push unless the user asked or their workflow clearly expects it. On a
10	long task, ask ONCE at the start: "checkpoint-commit as I go, or leave everything unstaged?"
11	If no commits are authorized, checkpoint with `git stash push -m "checkpoint: <state>"` or
12	record known-good SHAs in your notes instead.
13	2. No force pushes. No history rewrites of anything pushed (`rebase`, `commit --amend`,
14	`filter-branch` on published commits). To undo a pushed commit, use `git revert` — it
15	preserves history.
16	3. **No destructive working-tree operations without explicit confirmation in THIS
17	conversation:** `reset --hard`, `checkout -- .` over uncommitted work you didn't create,
18	`clean -fd`, branch deletion with unmerged work. Before asking, run `git status` and
19	`git stash list` and report what would be lost.
20	4. Never commit on the default branch. Branch first: `git checkout -b
21	<type>/<short-slug>` (e.g. `fix/csv-last-row`).
22	5. No secrets, ever. Before every commit, scan the staged diff for keys, tokens,
23	passwords, connection strings, and `.env` content. One match = unstage, move to env/secret
24	manager, and check whether the value was ever committed before (if yes, tell the user it
25	needs rotation — removal from HEAD does not un-leak it).
26	6. No generated junk: build artifacts, `node_modules`/`target`/`__pycache__`, editor
27	files, your own WORKING_NOTES.md. If it's generated and not ignored, fix `.gitignore` in
28	the same commit rather than committing the junk.
29
30	## Commit craft
31
32	1. Small and coherent: one logical change per commit — a commit you can describe in one
33	sentence without "and also". Mechanical rename and behavior change are two commits, so the
34	reviewer can skim one and scrutinize the other.
35	2. Stage by path, never blind: `git add src/lib/csv.ts tests/csv.test.ts` — never
36	`git add .` or `git add -A`, which are how junk, secrets, and unrelated edits get in.
37	3. Review the FULL staged diff before every commit: `git diff --staged`, read every hunk.
38	You are looking for: leftover debug prints, unrelated drive-by edits, secrets, and hunks
39	you can't explain. Any of those = fix before committing. This review is mandatory even
40	when "sure" — especially when sure.
41	4. Message format: imperative summary ≤72 chars stating the change
42	(`fix: include final row in CSV export`); body only when the WHY isn't obvious from the
43	diff — the constraint, the bug mechanism, the rejected alternative. Never narrate the
44	process ("tried X then Y").
45	5. Checkpoint rhythm (when commits are authorized): commit at every verified-green unit
46	boundary (see verification-loop). Never commit a known-red state; if you must save a red
47	work-in-progress, use a stash with a descriptive message instead.
48
49	## Recovery habits
50
51	- Before any risky operation you WERE authorized to run, note the current SHA
52	(`git rev-parse HEAD`) in your working notes — that's the rollback target.
53	- Prefer additive recovery (`revert`, new commit) over subtractive (`reset`) whenever the
54	branch may have been seen by anyone else.
55	- `git reflog` is the last-resort undo — remember it exists before declaring work lost.
56
57	## Worked example
58
59	Task: fix a bug; user said "commit as you go" at session start.
60
61	1. `git checkout -b fix/csv-last-row` (never on `main`).
62	2. Fix + regression test; `pnpm test` green.
63	3. `git add src/lib/csv.ts tests/csv.test.ts` (by path).
64	4. `git diff --staged` — review finds a `console.log(rows)` left in. Remove, re-stage, re-test.
65	5. Commit: `fix: include final row in CSV export when trailing newline absent`.
66	6. Later, a second improvement to error messages in the same file → separate commit, not
67	squashed in.
68	7. Push only because the user asked for a PR; `git push -u origin fix/csv-last-row` — no
69	force flags.
70
71	## Done when
72
73	Every commit on the branch is one sentence-sized logical change whose full staged diff you
74	read before committing; nothing was committed to the defa

People who liked this also viewed

6 picks

Type