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
- Inspect the diff:
git status, git diff --cached.
- If nothing staged, say so plainly (no flourish) and stop.
- Summarise the change as a plain subject line (≤50 chars).
- Draft a 2–6 line ornate body explaining the motivation.
- 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.
1---2name: shakespeare-commit3description: Generate an ornate, Elizabethan commit message for the currently staged changes. Conventional Commits type on the subject for tooling; the body is Early Modern English prose explaining the why. Use when the user types /shakespeare-commit or asks for a "bard commit". Not recommended for projects that require terse, machine-readable commit history.4---56Write a commit message for the currently staged changes.78## Shape910```11<type>: <short, plain, lowercase subject ≤50 chars>1213<ornate body in Early Modern English — 2 to 6 lines. Explain the WHY,14not the WHAT. Preserve exact file paths, function names, flags, errors.>15```1617- **Subject line is plain modern English.** Conventional Commits format18 (`feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `perf`, `build`,19 `ci`). Keep it boringly readable — this is what tooling and future git-log20 readers actually grep for.21- **Body is ornate.** Thou/thee/-eth/-est, poetic contractions, inverted22 syntax. Explain the motivation, the prior pain, the expected gain. Quote23 file paths and identifiers verbatim.24- Do not co-author, do not add trailers unless the user asks.2526## Steps27281. Inspect the diff: `git status`, `git diff --cached`.292. If nothing staged, say so plainly (no flourish) and stop.303. Summarise the change as a plain subject line (≤50 chars).314. Draft a 2–6 line ornate body explaining the motivation.325. Offer the message for the user to approve; commit only when approved.3334## Example3536Plain fix: "fix: guard against null user in auth middleware"3738Shakespeare-commit version:39```40fix: guard against null user in auth middleware4142Wherefore did our gates admit the nameless stranger? 'Twas a null43`req.user` slipping past the token check in `src/auth.ts:42`, whereupon44downstream handlers did throw `Cannot read property 'id' of null` with45woeful regularity. A humble guard clause now standeth watch, and peace46returneth to the logs.47```4849## Auto-Clarity5051Do **not** inflate security-relevant context (CVE IDs, auth flow specifics,52affected endpoints). State those plainly in the body. Flourish only the53narrative scaffolding around them.
jorgenosberg