Commit
Stage and create git commits after showing a commit plan, with no AI attribution. Explicit-only; run only when the user invokes /commit or asks to commit, never autonomously.From its SKILL.md
npx -y skills add corticalstack/flow --skill commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 4 commands, including `git status` and 3 more.
SKILL.md
1.9 KB, 384 tokens by cl100k_base, as published. Nobody here has run it
Commit Changes
You are tasked with creating git commits for the changes made during this session.
Process:
-
Think about what changed:
- Review the conversation history and understand what was accomplished
- Run
git statusto see current changes - Run
git diffto understand the modifications - Consider whether changes should be one commit or multiple logical commits
-
Plan your commit(s):
- Identify which files belong together
- Draft clear, descriptive commit messages
- Use imperative mood in commit messages
- Focus on why the changes were made, not just what
-
Present your plan to the user:
- List the files you plan to add for each commit
- Show the commit message(s) you'll use
- Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
-
Execute upon confirmation:
- Use
git addwith specific files (never use-Aor.) - Create commits with your planned messages
- Show the result with
git log --oneline -n [number]
- Use
Important:
- NEVER add co-author information or Claude attribution
- Commits should be authored solely by the user
- Do not include any "Generated with Claude" messages
- Do not add "Co-Authored-By" lines
- Write commit messages as if the user wrote them
Remember:
- Context may have been cleared during long sessions - rely on
git statusandgit diffto understand changes, not just conversation history - If unsure about change intent, read the modified files or ask the user
- Group related changes together
- Keep commits focused and atomic when possible
- The user trusts your judgment - they asked you to commit
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most pr commit review skills give in 384 tokens
Counted across 1,055 of the 1,911 authors here whose files we hold, read 2026-09-06
- Use conventional commit message formatin 150 of 1055, across 145 files
- Announce skill usage at startin 78 of 1055
- Use imperative mood for commit descriptionshere, and in 54 of 1055, across 51 files
- Add directory to gitignore if not ignoredin 52 of 1055, across 41 files
- Use imperative mood for commit subjectin 52 of 1055
- Run tests to verify clean baselinein 42 of 1055, across 32 files
- Push branch to originin 40 of 1055, across 38 files
- Verify worktree directory is ignored before creationin 39 of 1055, across 32 files
- Delete branches after mergingin 38 of 1055, across 30 files
- Create worktree with new branchin 37 of 1055, across 32 files
- Wrap body text at 72 charactersin 36 of 1055, across 34 files
- Auto-detect and run project setupin 35 of 1055, across 27 files
Said here and by no other author read
- Review conversation history
- Draft clear descriptive commit messages
- Show result with git log
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.