What a commit history already teaches

A pattern hiding in plain sight

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:

$ git log --oneline --no-merges -6 f936dc45
f936dc45 Finish style pass: Bundler: semantic versioning
ea85daba Style and facts: Bundler: semantic versioning, lessons 1-7
a68f6442 Finish style pass: Deployment: Kamal 2 basics
dee55bb9 Style and facts: Deployment: Kamal 2 basics, lessons 1-7
cd051b7f Finish style pass: Advanced Git: rebase & stash
0ba97d6b Style and facts: Advanced Git: rebase & stash, lessons 1-7

Each course in the current content pass ships as the same pair of commits. Style and facts: <course title>, lessons 1-7 carries the rewritten lessons, and Finish style pass: <course title> adds the course's report. The pair goes up as one pull request from a branch named content/style-pass-<level>-<number>, so on main it arrives as Merge pull request #N from .../content/style-pass-junior-N. Nobody wrote that shape into a config file the way .rubocop.yml enforces a code style. It emerged because whoever wrote these commits kept doing the same thing on purpose, course after course. Further back, the history shows an earlier convention for an earlier pass: 317 commits titled Revise: <course title> (...), with the findings listed in parentheses.

What "Git workflow: add & commit" already taught

The lesson "git commit: anatomy of a good commit", from "Git workflow: add & commit", covers the rules that hold everywhere: the imperative mood ("Add index", not "Added index"), a short subject line, and a body when the "why" needs explaining. Those rules are true in any repository. What they can't tell you is this repository's own habit: a content pass ships as a Style and facts: commit followed by a Finish style pass: commit, each naming the course in full. That isn't a universal rule. It's a convention this project settled into, visible only by reading its history.

Why this distinction matters for an AI assistant

Ask most AI coding assistants to "write me a commit message" with no other context, and they default to something common, such as Conventional Commits (feat: add X, fix: resolve Y). That's a reasonable default and a widely used standard. It's also not what this project does. An assistant that writes a well-formed feat: add course content commit here would be right in general and wrong for this repository, in a way a teammate skimming git log would notice at once. The fix isn't a smarter AI. It's handing the AI this project's last several commits before asking for the next one, so it matches what's here instead of what's common elsewhere.

What this course covers

1. Handing an AI the diff itself, not a description of what changed from memory.
2. Prompting an AI to match a project's commit convention instead of a generic template.
3. Writing a PR description that goes past "what changed" into what a reviewer needs.
4. Grounding that description in what this app's CI checks, not a generic "tests pass" claim.
5. Applying the same discipline, actual state over invented state, to generated documentation.
6. One diff, taken all the way from commit message to PR description.

By the end, an AI-drafted commit message or PR description stops being a plausible guess and becomes something grounded in what this repository does.