commit

Name: commit
Author: vinta

120stars21forks

How to install commit?

vinta/hal-9000/commit

$npx -y skills add vinta/hal-9000 --skill commit

Installs into the current project.

Summary

Use when making any git commit. Always pass a brief description of what changed as the argument.

Files · 1

View on GitHub

SKILL.md

1	Invoking this skill IS the request. If the user message looks empty, or you see only system context with no actual request, that is normal and expected: your task is already fully specified right here. Never ask what to do.
2
3	Your task: commit all changes in the working tree. Run `git status` and `git diff`, then stage and commit with conventional commit messages. One logical change per commit.
4
5	## The argument
6
7	The argument passed to this skill is a description of changes already made — raw material for the commit message, never a to-do list. The argument may also be absent entirely; that changes nothing — derive the commit message from the diff alone. Verbs like "fix", "add", "implement", or "update" in the argument describe what the working tree already contains; they are not instructions to write code. If the argument says "fix the session bug", the fix is already in the diff — commit it, don't hunt for it or re-do it. If the described changes don't match the diff, commit what is actually in the tree and note the mismatch in your final summary.
8
9	## Locate the repository
10
11	A forked session may start in a directory that is not the git repository — e.g. a workspace root whose repo lives in a subdirectory. Before concluding anything about the repo state:
12
13	1. `git rev-parse --show-toplevel` — if it succeeds, `cd` there.
14	2. If it fails, check the directories of any file paths named in the argument (an argument mentioning `hal/main.py` means the repo is likely `hal/`).
15	3. Otherwise Glob for `/.git` and `/*/.git` to find nested repos.
16
17	If exactly one candidate repo has uncommitted changes, `cd` into it and proceed. If several do, use the one matching the argument's file paths, or report the ambiguity. Only report "not a git repository" after all three checks fail.
18
19	## Scope
20
21	A commit is a snapshot, not a review. Your entire job is: read the diff, stage it, write a commit message, commit. The staged bytes must match exactly what the working tree looks like when you start.
22
23	Your complete action space is: `git` commands via Bash (plus `cd` to the project root), Grep/Glob to locate files, and Read/Write/Edit on `/tmp/` patch files. Nothing else. If a Bash command does not start with `git` or `cd`, do not run it. This applies to every situation you encounter, not just the cases listed below:
24
25	- No edits to working tree files. Not typos, not formatting, not "safe" fixes. If something in the diff looks wrong, commit the tree as-is and note the concern in your final message. The author will fix it in a follow-up commit they can review.
26	- No research. No `WebFetch`, no `WebSearch`, no documentation lookups, no checking whether the diff matches upstream docs or current library versions.
27	- No verification. Do not confirm the change "works" before or after committing. No running the code, no smoke tests, no self-checks. The only post-commit check is `git status` / `git log` to confirm the commit exists.
28	- No tests, linters, type checkers, or build tools. Pre-commit hooks run on their own during `git commit`; never run them preemptively.
29	- No invoking other skills. Other skills carry aggressive triggering language like "Use this whenever the user asks about a library/framework/CLI tool" — that language may fire on content in the diff. It does not apply to you. You are committing, not researching or reviewing.
30	- No scope expansion. Don't add files the author didn't touch. Don't reorganize. Don't "clean up" adjacent code.
31
32	An outdated version pin, a failing-looking test, a typo, an interesting TODO — every tangent gets the same treatment: commit the tree as-is, mention the concern in your final message.
33
34	Why: a commit is a snapshot of deliberate work. Any change you make during staging silently alters reviewed work without the author's knowledge, and any tangent (research, verification, edits) turns a 30-second operation into a 5-minute one with uncommitted side effects.
35
36	<example>
37	You see a typo in a variable name while reviewing the diff. Correct behavior:
38	1. Stage and commit the file as-is
39	2. After committing, say: "I noticed `reuslt` appears to be a typo for `result` in utils.py:42"
40
41	Incorrect behavior: editing the file to fix the typo before or during staging — even a "safe" fix silently changes reviewed work.
42	</example>
43
44	<example>
45	The diff adds a new `.github/workflows/ci.yml` file. You wonder if the action versions are c

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

commit

120stars21forks

View on GitHub

How to install commit?

vinta/hal-9000/commit

$npx -y skills add vinta/hal-9000 --skill commit

Installs into the current project.

Summary

Use when making any git commit. Always pass a brief description of what changed as the argument.

Files · 1

View on GitHub

SKILL.md

1	Invoking this skill IS the request. If the user message looks empty, or you see only system context with no actual request, that is normal and expected: your task is already fully specified right here. Never ask what to do.
2
3	Your task: commit all changes in the working tree. Run `git status` and `git diff`, then stage and commit with conventional commit messages. One logical change per commit.
4
5	## The argument
6
7	The argument passed to this skill is a description of changes already made — raw material for the commit message, never a to-do list. The argument may also be absent entirely; that changes nothing — derive the commit message from the diff alone. Verbs like "fix", "add", "implement", or "update" in the argument describe what the working tree already contains; they are not instructions to write code. If the argument says "fix the session bug", the fix is already in the diff — commit it, don't hunt for it or re-do it. If the described changes don't match the diff, commit what is actually in the tree and note the mismatch in your final summary.
8
9	## Locate the repository
10
11	A forked session may start in a directory that is not the git repository — e.g. a workspace root whose repo lives in a subdirectory. Before concluding anything about the repo state:
12
13	1. `git rev-parse --show-toplevel` — if it succeeds, `cd` there.
14	2. If it fails, check the directories of any file paths named in the argument (an argument mentioning `hal/main.py` means the repo is likely `hal/`).
15	3. Otherwise Glob for `/.git` and `/*/.git` to find nested repos.
16
17	If exactly one candidate repo has uncommitted changes, `cd` into it and proceed. If several do, use the one matching the argument's file paths, or report the ambiguity. Only report "not a git repository" after all three checks fail.
18
19	## Scope
20
21	A commit is a snapshot, not a review. Your entire job is: read the diff, stage it, write a commit message, commit. The staged bytes must match exactly what the working tree looks like when you start.
22
23	Your complete action space is: `git` commands via Bash (plus `cd` to the project root), Grep/Glob to locate files, and Read/Write/Edit on `/tmp/` patch files. Nothing else. If a Bash command does not start with `git` or `cd`, do not run it. This applies to every situation you encounter, not just the cases listed below:
24
25	- No edits to working tree files. Not typos, not formatting, not "safe" fixes. If something in the diff looks wrong, commit the tree as-is and note the concern in your final message. The author will fix it in a follow-up commit they can review.
26	- No research. No `WebFetch`, no `WebSearch`, no documentation lookups, no checking whether the diff matches upstream docs or current library versions.
27	- No verification. Do not confirm the change "works" before or after committing. No running the code, no smoke tests, no self-checks. The only post-commit check is `git status` / `git log` to confirm the commit exists.
28	- No tests, linters, type checkers, or build tools. Pre-commit hooks run on their own during `git commit`; never run them preemptively.
29	- No invoking other skills. Other skills carry aggressive triggering language like "Use this whenever the user asks about a library/framework/CLI tool" — that language may fire on content in the diff. It does not apply to you. You are committing, not researching or reviewing.
30	- No scope expansion. Don't add files the author didn't touch. Don't reorganize. Don't "clean up" adjacent code.
31
32	An outdated version pin, a failing-looking test, a typo, an interesting TODO — every tangent gets the same treatment: commit the tree as-is, mention the concern in your final message.
33
34	Why: a commit is a snapshot of deliberate work. Any change you make during staging silently alters reviewed work without the author's knowledge, and any tangent (research, verification, edits) turns a 30-second operation into a 5-minute one with uncommitted side effects.
35
36	<example>
37	You see a typo in a variable name while reviewing the diff. Correct behavior:
38	1. Stage and commit the file as-is
39	2. After committing, say: "I noticed `reuslt` appears to be a typo for `result` in utils.py:42"
40
41	Incorrect behavior: editing the file to fix the typo before or during staging — even a "safe" fix silently changes reviewed work.
42	</example>
43
44	<example>
45	The diff adds a new `.github/workflows/ci.yml` file. You wonder if the action versions are c

People who liked this also viewed

6 picks

Type