Commit message from a diff
Write a commit message from a diff: a subject line that states what was found, then prose explaining why the change was made.
In Lobstack: Skills › Library › Add
What your agent will do.
A change is ready and needs a message. Also when rewriting one that says only what the diff already says.
- 01
Read the whole diff before writing anything. A message written from the branch name describes an intention, not a change.
- 02
Make the subject the finding rather than the activity: "the tray icon was a black square, not a missing file" beats "fix tray icon". Under 72 characters, no trailing full stop.
- 03
Then the body, in prose and in paragraphs, answering WHY — the diff already answers what. Name the cause you found, the symptom somebody saw, and the fix you considered and rejected.
- 04
Attach every claim to something checkable: a file and line, a quoted error, a measured number. "This is faster" is an opinion. "2.1s to 0.3s" is a finding.
- 05
Say what the change does not fix, when it leaves something standing.
Leave out a walk through the hunks and a list of the files touched. A reader gets both from git show, and a body that can be deleted without losing an argument was a restatement of the diff.
The whole SKILL.md: 31 lines of Markdown.
Add it in the app from Skills › Library, or copy it and paste it into Skills › Add a skill.
---name: commit-messagedescription: "Write a commit message from a diff: a subject line that states what was found, then prose explaining why the change was made."metadata: title: "Commit message from a diff" category: engineering tags: [git, writing]--- ## When to use this A change is ready and needs a message. Also when rewriting one that says onlywhat the diff already says. ## How 1. Read the whole diff before writing anything. A message written from the branch name describes an intention, not a change.2. Make the subject the finding rather than the activity: "the tray icon was a black square, not a missing file" beats "fix tray icon". Under 72 characters, no trailing full stop.3. Then the body, in prose and in paragraphs, answering WHY -- the diff already answers what. Name the cause you found, the symptom somebody saw, and the fix you considered and rejected.4. Attach every claim to something checkable: a file and line, a quoted error, a measured number. "This is faster" is an opinion. "2.1s to 0.3s" is a finding.5. Say what the change does not fix, when it leaves something standing. Leave out a walk through the hunks and a list of the files touched. A readergets both from git show, and a body that can be deleted without losing anargument was a restatement of the diff.
- Engineering
Triage a failing build
Triage a red CI run: find the first real failure, attribute it to a change, and say whether the code is wrong or the runner was.
SKILL.md · App - Engineering
Review what a linter cannot
Review a change for what a linter cannot see: whether it is correct, what it breaks elsewhere, and which parallel list it forgot to update.
SKILL.md · App - Engineering
Pull request description
Write a pull request description from the diff: why it exists, what changed, how it was tested, and where a reviewer should look first.
SKILL.md · App - Engineering
Incident postmortem
Write a blameless postmortem from an incident's alerts, logs and chat: timeline, impact, root cause, and actions with owners.
SKILL.md · App - Engineering
Reproduce a bug before fixing it
Fix a bug by reproducing it first: turn the report into a failing test or script, shrink it, make the smallest fix, and show the test pass.
SKILL.md · App - Engineering
Security review of a change
Review a change or repository for security holes (leaked secrets, injection, missing permission checks, unsafe input handling) with a real attack for each finding.
SKILL.md · App