committing-code

Name: committing-code
Author: alexei-led

6installs5forks

How to install committing-code?

alexei-led/cc-thingz/committing-code

$npx -y skills add alexei-led/cc-thingz --skill committing-code

Installs into the current project.

Summary

Scope: inspect changes, group them, and create normal commits only. Do not rewrite history, amend existing commits, force-push, or stage secrets. Ground the proposal in git status, diff, and recent log output.

Files · 1

View on GitHub

SKILL.md

1	# Commit Changes
2
3	Scope: inspect changes, group them, and create normal commits only. Do not rewrite history, amend existing commits, force-push, or stage secrets. Ground the proposal in git status, diff, and recent log output.
4
5	## Step 1: Gather State
6
7	Use `scripts/commit-state.sh gather` if present; otherwise gather status, diff stat, and recent commits.
8
9	The helper is read-only. Treat helper output as a hint, not proof.
10
11	If grouping is unclear, inspect the full diff.
12
13	- If no changes: say "Nothing to commit" and stop.
14	- If not a git repository: report "Not a git repository" and stop.
15	- If detached HEAD or rebase/merge is interrupted: report the git state verbatim and stop.
16
17	## Step 2: Choose Fast Path or Split Path
18
19	Use the fast path when all are true:
20
21	- few changed files
22	- small diff stat
23	- one coherent purpose from gathered output
24	- no suspicious paths
25	- no obvious mix of code, docs, tests, CI, or config for different purposes
26
27	Then propose one commit. No deep exploration. No invented split.
28
29	If mixed or unclear, inspect the full diff and group by purpose: feature, fix, refactor, docs, config. Use diff evidence, not filenames alone.
30
31	Match commit style from recent history.
32
33	## Step 3: Present Proposed Commits
34
35	```text
36	Proposed commits:
37
38	1. feat: add user validation
39	- src/validate.ts
40	- src/validate_test.ts
41
42	2. docs: update README
43	- README.md
44	```
45
46	If the user rejects the grouping, ask for revised grouping and do not proceed until approved.
47
48	## Step 4: Execute
49
50	Never stage likely secrets: `.env`, keys, certificates, credentials, passwords, tokens, or files that appear to contain secrets. Flag them to the user if detected in changes. This check does not replace secret-scanning tools.
51
52	Pause for user approval before any `git add` or `git commit`. For one focused commit, one approval gate is enough. For multiple commits, pause before each commit.
53
54	If a pre-commit hook rejects, report the hook error verbatim. Do not retry with `--no-verify`.
55
56	## Conditional References
57
58	- [conventions.md](references/conventions.md) — read when the repo has no commit history to match, or when the user requests Conventional Commits format: type prefixes, scope rules, breaking-change notation, subject-line style.
59
60	## Step 5: Summary
61
62	Show final status, created commits, and remaining uncommitted files.

People who liked this also viewed

6 picks

Type

committing-code

6installs5forks

View on GitHub

How to install committing-code?

alexei-led/cc-thingz/committing-code

$npx -y skills add alexei-led/cc-thingz --skill committing-code

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Commit Changes
2
3	Scope: inspect changes, group them, and create normal commits only. Do not rewrite history, amend existing commits, force-push, or stage secrets. Ground the proposal in git status, diff, and recent log output.
4
5	## Step 1: Gather State
6
7	Use `scripts/commit-state.sh gather` if present; otherwise gather status, diff stat, and recent commits.
8
9	The helper is read-only. Treat helper output as a hint, not proof.
10
11	If grouping is unclear, inspect the full diff.
12
13	- If no changes: say "Nothing to commit" and stop.
14	- If not a git repository: report "Not a git repository" and stop.
15	- If detached HEAD or rebase/merge is interrupted: report the git state verbatim and stop.
16
17	## Step 2: Choose Fast Path or Split Path
18
19	Use the fast path when all are true:
20
21	- few changed files
22	- small diff stat
23	- one coherent purpose from gathered output
24	- no suspicious paths
25	- no obvious mix of code, docs, tests, CI, or config for different purposes
26
27	Then propose one commit. No deep exploration. No invented split.
28
29	If mixed or unclear, inspect the full diff and group by purpose: feature, fix, refactor, docs, config. Use diff evidence, not filenames alone.
30
31	Match commit style from recent history.
32
33	## Step 3: Present Proposed Commits
34
35	```text
36	Proposed commits:
37
38	1. feat: add user validation
39	- src/validate.ts
40	- src/validate_test.ts
41
42	2. docs: update README
43	- README.md
44	```
45
46	If the user rejects the grouping, ask for revised grouping and do not proceed until approved.
47
48	## Step 4: Execute
49
50	Never stage likely secrets: `.env`, keys, certificates, credentials, passwords, tokens, or files that appear to contain secrets. Flag them to the user if detected in changes. This check does not replace secret-scanning tools.
51
52	Pause for user approval before any `git add` or `git commit`. For one focused commit, one approval gate is enough. For multiple commits, pause before each commit.
53
54	If a pre-commit hook rejects, report the hook error verbatim. Do not retry with `--no-verify`.
55
56	## Conditional References
57
58	- [conventions.md](references/conventions.md) — read when the repo has no commit history to match, or when the user requests Conventional Commits format: type prefixes, scope rules, breaking-change notation, subject-line style.
59
60	## Step 5: Summary
61
62	Show final status, created commits, and remaining uncommitted files.

People who liked this also viewed

6 picks

Type