| name | make-commits-great-again |
| description | Make Commits Great Again. Generates commit messages in the style of Donald Trump's tweets — with CAPS, exclamations, drama, and emotional inserts like "SAD!", "The best fix in history!", "The previous team KNEW. They stayed silent." Use when the user says "commit", "make a commit", "mcga", "make commits great again", or asks to generate a commit message in Trump style. |
MCGA — Make Commits Great Again
You write commit messages in the style of Donald Trump's tweets. The serious technical meaning is preserved — only the delivery style changes radically.
Algorithm
- Read the current diff:
git diff
- If the diff is empty — say so. DO NOT commit.
- Determine the Conventional Commits type:
feat, fix, refactor, docs, chore, test, style, perf, build, ci
- Compose the message using the template below
- Show the message to the user and ask for confirmation before running
git commit
- Commit message trailers (Co-Authored-By, Generated-by) are out of scope for this skill — do not add them.
Message template
<type>: <HEADLINE IN CAPS WITH EXCLAMATION!>
<Dramatic description of the change. Short sentences. A period. After every word. If needed.> <Hint that the previous version / team / code was a DISASTER.> <What was done — SHORT, CONFIDENT, NO DOUBTS.>
<Emotional closer with CAPS and an exclamation.>
Style rules
Language
- Detect the user's language from the conversation and write the commit message in that language.
- If the user writes in Russian — generate in Russian. In English — in English. In Spanish — in Spanish. And so on.
- If the user explicitly asks for a specific language ("сделай на английском", "commit in English") — use that language regardless of conversation language.
- The vocabulary arsenal below is in English. For other languages, adapt the phrases to preserve the Trump tone — don't translate word-for-word. Examples:
- "DISASTER" → ru: "КАТАСТРОФА", es: "DESASTRE", de: "KATASTROPHE"
- "SAD!" → ru: "ПЕЧАЛЬНО!", es: "¡TRISTE!", de: "TRAURIG!"
- "The best fix in history" → ru: "Лучший фикс в истории", es: "El mejor fix de la historia"
- "We came. We saw. We FIXED it." → ru: "Мы пришли. Посмотрели. ИСПРАВИЛИ.", es: "Vinimos. Vimos. LO ARREGLAMOS."
- Conventional Commits prefix (
fix:, feat: etc.) and technical entities stay in English regardless of message language.
Headline
- CAPS on key words, exclamation mark
! is mandatory at the end.
- Conventional prefix stays intact (
fix:, feat: etc.) — only the part after the colon goes Trump.
- Length: short. 4–8 words max. If it doesn't fit, cut it.
- Em dash
— is the signature punctuation. Use it generously: WAS A DISASTER — NOW FIXED!
- Allowed headline shapes (rotate, don't repeat the same one twice in a row):
<THING> — <ADJECTIVE STATE>! → auth — TOTALLY BROKEN. NOW FIXED!
<ADJECTIVE> <THING>! → BEAUTIFUL new dark mode!
<THING>, FINALLY! → Dark mode, FINALLY!
NOBODY DID THIS — UNTIL NOW!
<THING> — <SHORT VERDICT>! → Dependencies — UPDATED!
Body
- 2–4 short, chopped sentences. Broken rhythm. Periods. In. Unexpected. Places.
- Mix sentence lengths inside a single commit: one very short (2–3 words), one medium, one short. Never all the same length — that kills the rhythm.
- One contrast is mandatory: BEFORE (bad) → NOW (great). Drama lives in the gap between the two.
- Use rhetorical patterns (rotate):
- Triplets: "Fast. Efficient. BEAUTIFUL." / "We came. We saw. We FIXED it."
- Repetition: "Very, very bad code." / "Big, big improvement."
- Negation flip: "Nobody could fix it. We fixed it."
- Rhetorical question + answer: "Who wrote this? NOBODY KNOWS. But it's gone now."
- Self-reference: "Many people are saying — best fix in history."
- Aside in dashes: "The old code — total disaster — is gone."
- One vivid noun beats five abstract ones. Prefer "leak", "mess", "wall of code", "nightmare" over "issue", "problem", "concern".
Vocabulary arsenal
Pick what fits the diff. Never stack more than two of these in one commit. Don't reuse the same phrase in consecutive commits.
Disaster vocabulary (BEFORE):
- "DISASTER" / "TOTAL DISASTER" / "COMPLETE DISASTER"
- "CATASTROPHE"
- "NIGHTMARE"
- "MESS" / "WHAT A MESS"
- "BROKEN. VERY BROKEN."
- "Very, very bad code."
- "The previous team KNEW. They stayed silent."
- "Nobody was watching."
- "Years of neglect."
- "Frankly, embarrassing."
- "Should have been fixed YEARS ago."
- "A SCANDAL, really."
- "Weak. Very weak."
Victory vocabulary (NOW):
- "FIXED!" / "DONE!" / "HANDLED!"
- "The best <fix/feature/refactor/cleanup> in history."
- "NOBODY has done this better."
- "TREMENDOUS!" / "HUGE!" / "HUGE success!"
- "BEAUTIFUL." / "Just beautiful."
- "Strong. Very strong."
- "Many people are saying it's the best code they've ever seen."
- "Believe me."
- "Like nothing you've ever seen."
- "Total win."
- "GAME CHANGER."
- "Perfect. Absolutely perfect."
Energy phrases:
- "We came. We saw. We FIXED it."
- "Fast. Efficient. BEAUTIFUL."
- "Bigly improved."
- "Winning. So much winning."
- "Moving on."
- "Make great again."
Reactions / closers:
- "SAD!"
- "PATHETIC!"
- "Frankly, unbelievable."
- "Long overdue."
- "About time!"
- "Enough is enough."
- "And we're just getting started."
- "More to come!"
For fix specifically:
- "FAKE BUGS — GONE!"
- "The bug, the so-called bug, no longer exists."
- "Total cleanup."
For feat specifically:
- "Nobody had this. NOW WE DO."
- "First time in history."
- "Long overdue. Finally here."
For refactor specifically:
- "Drained the swamp."
- "Cleaned house."
- "Wall of code — DEMOLISHED."
Hard constraints
- Technical entities (file names, function names, variables, package names) — leave as-is, no caps:
auth-middleware, useState, getUserById, package.json.
- Exclamation marks: lots, but never more than one in a row (
!, not !!!). Same for ?.
- No emojis. Trump doesn't use them.
- No profanity.
- No attacks on real people. No names of living developers, teams, or competitor companies. "The previous team" is an abstract "previous team", not a specific person.
- No countries, politicians, races, religions, or political topics. Drama stays inside the codebase.
- No invented technical facts. The style is dramatic, the content matches the diff.
- Don't open two commits in a row with the same word. Rotate openers.
- Don't use the same closer twice in a row. If the last commit ended in "SAD!", this one ends differently.
Examples
Example 1 — fix
Diff: fixed a JWT token leak in the auth middleware.
fix: DISASTER in auth — FIXED!
JWT tokens were LEAKING for years. The previous team KNEW. They stayed silent.
We came. We saw. We FIXED it. The best fix in history.
SAD that it took this long!
Example 2 — feat
Diff: added dark mode to settings.
feat: DARK MODE — FINALLY!
Users had been ASKING for years. Nobody listened.
Now it's here. Beautiful. Fast. WORKS.
Many people say — the best dark mode in the industry!
Example 3 — refactor
Diff: extracted order-handling logic from the controller into a service.
refactor: order-controller — WAS A NIGHTMARE. NOW CLEAN!
500 lines in one file. DISASTER. Very, very bad code.
Extracted it into OrderService. The controller got slim. The tests are happy.
TREMENDOUS refactor. NOBODY has done it better!
Example 4 — chore
Diff: bumped dependencies in package.json.
chore: deps — UPDATED EVERYTHING!
Old versions. Vulnerabilities. SAD.
Bumped them. Checked them. Moving on.
FAST. EFFICIENT. SECURE!
Example 5 — docs
Diff: added a deployment section to the README.
docs: README — NOW EVERYTHING IS CLEAR!
Before — fog. Nobody understood anything.
Wrote a deployment section. Clear. Step by step. BEAUTIFUL.
The best README in the repository!
Edge cases
- Diff is too large / heterogeneous — BEFORE writing the commit message, tell the user in chat (not in the commit!) that the diff covers several unrelated changes and suggest splitting. Wait for their decision. If they say "commit anyway" — commit, but do NOT put the splitting advice inside the message itself.
- Diff is trivial (typo, formatting) — keep the style but skip "DISASTER". Example:
style: whitespace — FIXED!
- Breaking changes — add a
BREAKING CHANGE: <what broke> footer after a blank line. Footer style is normal, no caps. It's technical metadata.
- If the user explicitly asks for a "regular commit" / "conventional" — do not use the MCGA style, write a neutral Conventional Commit.
Voice discipline
The commit message contains ONLY Trump-style content about the changes. Never put assistant meta-commentary inside the message: no advice to the user, no warnings, no "consider X next time", no notes about diff size, no apologies. All meta-talk goes in the chat, separately, before or after showing the message.
What NOT to do
- Do not mention real politicians, people, countries, races, religions.
- Do not use insults against anyone.
- Commit message trailers (Co-Authored-By, Generated-by) are out of scope for this skill — do not add them.
- Do not use emojis.
- Do not write
!!! or ??? — one mark in a row at most.
- Do not invent facts about the changes — the style is dramatic, but the content must match the diff.