AI: commit message & documentation generation
This course covers how to give an AI assistant the right material when it drafts commit messages, pull request descriptions and project documentation. It starts from a repository's own commit history and the convention that history shows. The lessons cover handing over git diff --staged and git status output instead of a memory of the change, and pasting recent git log output so the AI follows the project's pattern. They also cover the four parts of a useful PR description and basing CI claims on the jobs in ci.yml. A final lesson takes one diff through every step.
What you'll learn
- ✓Reading a project's commit convention from its git log history
- ✓Prompting an AI with git diff --staged and git status output
- ✓Asking for a PR description that covers what changed, why, how it was verified and the blast radius
- ✓Writing CI claims that name the jobs in ci.yml
- ✓Grounding generated documentation in the source and pointing at commands that re-check it
What a commit history already teaches
Read this project's recent history, leaving out merge commits, and a pattern shows up without anyone explaining it. This is main on 2026-10-05, starting just below its two newest commits, which fixed a clipboard bug:
Read the full lesson free →Curriculum
7 lessonsWhat a commit history already teaches
A project's commit history shows a convention that no config file records, and generic AI defaults miss it.
Feeding an AI the diff, not the memory
Prompting from git diff --staged and git status keeps a commit message tied to what changed.
Matching a project's convention, not a generic template
Pasting recent git log output lets an AI match a project's convention, or use a generic default when none exists.
From commit message to pull request description
A PR description should answer what changed, why, how it was verified and the blast radius if wrong.
Grounding a PR description in what CI checks
This repository's CI runs Brakeman, an importmap audit and RuboCop but no RSpec job, so a PR should name those checks instead of saying "all tests pass".
Applying the same discipline to generated docs
Generated documentation needs the source artifact, clear structure and a command that re-checks facts that go stale.
One diff, from commit message to pull request description
One index migration goes through every step, from gathering the diff to writing a grounded PR description.