write-commit
Skill1 starsChanged 44 days agoMITView on GitHub
Writes a commit message in the repo's own convention, validated and saved to .workflow/<KEY>/commit.txt. Use when asked to commit, or to write or fix a commit message.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- adhamhaithameid/write-skillstheir own version, first seen Nov 8, 2026
- sh4wty1/fassi-skillstheir own version, first seen Oct 9, 2026
- openjck/agent-skillstheir own version, first seen Jun 21, 2026
- ZAidBinAsif/flutter-ai-startertheir own version, first seen Jun 20, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- sh4wty1/fassi-skills★ 2same name
- adhamhaithameid/write-skills★ 1same name
- openjck/agent-skills★ 0same name
- ZAidBinAsif/flutter-ai-starter★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- address-reviewSkill
- draft-prSkill
- frame-productSkill
- implement-changeSkill
- plan-changeSkill
- review-diffSkill
- trace-incidentSkill
- triage-taskSkill
- write-handoverSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
Check it: Write the draft to a file, then commit check --file <path> --key <KEY>.
- Distinctive: line 50
One logical change per commit: If the subject needs an "and", it is probably two commits.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
write-commit
wb <args> # wb not on PATH: python <this skill's directory>/../../lib/wb.py <args>This skill writes the message. Committing stays the user's call: the CLI prints
the command and runs it only for an explicit --execute.
Steps
- Learn the house style.
commit convention. It reports what this repo already does — conventional commits, ticket-prefixed subjects, or free-form — from its own history, plus the author identity and whether it matches the context. Follow it; a message in a different style is noise in the log forever. If it reportsfree-formand the team has decided to adopt a style, record it once withcommit convention --set <style>— do not impose one silently. - See what changed.
git difffor the files,review contextif you need the zones. If a plan exists:sdd get <KEY> --section summarygives the objective in one line. - Write it.
- Subject: imperative, specific, under 72 characters, no trailing period. "fix expired coupon charging the card" — not "fixes" and not "bug fix".
- Body, when the change is not self-evident: why, not what. The diff already says what. Wrap at 72.
- Reference the ticket key if the repo's history does.
BREAKING CHANGE:in the body if a contract changed.
- Check it. Write the draft to a file, then
commit check --file <path> --key <KEY>. On pass with a key it is saved to.workflow/<KEY>/commit.txt; on failure nothing is saved and the reasons are listed. Fix the message, not the check. - Hand it over. Show the message.
git commit <KEY>prints the exact commit command, carrying the saved message and the author the context expects; add--executeonly if the user asked you to commit. It refuses on a protected branch and with nothing staged — choosing what goes in a commit stays theirs.
Rules
- One logical change per commit. If the subject needs an "and", it is probably two commits.
- Never describe what you did not do. No "add tests" in the subject when no test file changed.
- No unfinished markers.
wip,fixup!andsquash!are rejected. - Never put a credential in a message. The check refuses anything that looks like one.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.