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.
Engineering · For your bots
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
Download LobstackA change is ready and needs a message. Also when rewriting one that says only what the diff already says.
Read the whole diff before writing anything. A message written from the branch name describes an intention, not a change.
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.
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.
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.
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.
---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.