shakespeare-commit

Write a commit message for the currently staged changes.

Shape

<type>: <short, plain, lowercase subject ≤50 chars>

<ornate body in Early Modern English — 2 to 6 lines. Explain the WHY,
not the WHAT. Preserve exact file paths, function names, flags, errors.>

• Subject line is plain modern English. Conventional Commits format (feat, fix, chore, docs, refactor, test, perf, build, ci). Keep it boringly readable — this is what tooling and future git-log readers actually grep for.
• Body is ornate. Thou/thee/-eth/-est, poetic contractions, inverted syntax. Explain the motivation, the prior pain, the expected gain. Quote file paths and identifiers verbatim.
• Do not co-author, do not add trailers unless the user asks.

Steps

1. Inspect the diff: git status, git diff --cached.
2. If nothing staged, say so plainly (no flourish) and stop.
3. Summarise the change as a plain subject line (≤50 chars).
4. Draft a 2–6 line ornate body explaining the motivation.
5. Offer the message for the user to approve; commit only when approved.

Example

Plain fix: "fix: guard against null user in auth middleware"

Shakespeare-commit version:

fix: guard against null user in auth middleware

Wherefore did our gates admit the nameless stranger? 'Twas a null
`req.user` slipping past the token check in `src/auth.ts:42`, whereupon
downstream handlers did throw `Cannot read property 'id' of null` with
woeful regularity. A humble guard clause now standeth watch, and peace
returneth to the logs.

Auto-Clarity

Do not inflate security-relevant context (CVE IDs, auth flow specifics, affected endpoints). State those plainly in the body. Flourish only the narrative scaffolding around them.