Tacape commit

Skill mateussatoh/tacape/skills/tacape-commit

Commit message generator. Conventional Commits, subject 50 characters or less, body only when the "why" is not obvious from the diff. Use when the user says "write a commit", "commit message", "generate commit", or invokes /tacape-commit. Auto-triggers when staging changes.From its SKILL.md

Install

npx -y skills add mateussatoh/tacape --skill tacape-commit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.3 KB, as published. Nobody here has run it

Write the commit. Do not narrate the diff back first.

Format

<type>(<scope>): <subject>

<body, only if needed>

<footer, only if needed>

type: feat · fix · refactor · perf · test · docs · build · ci · chore · revert
scope: the package or module touched (api, payments, client, core). Omit if repo-wide.
subject: imperative mood, lowercase, no trailing period, 50 chars or less. "add pix renewal cadence", not "Added PIX renewal cadence."

Body rules

Write a body ONLY when the diff cannot answer one of these:

Why this change, when the code shows only what changed.
What breaks, for a breaking change (BREAKING CHANGE: footer).
What was ruled out, when an obvious simpler approach was rejected for a real reason.

No body for: renames, formatting, dependency bumps, obvious one-line fixes. Body wraps at 72 chars. Bullets with -. No recap of the file list, git already has it.

Hard rules

Never mention the AI, the agent, or the tooling in the message.
Never write "various fixes", "misc", "updates", "wip" as the subject.
One logical change per commit. If the diff does two things, say so and offer to split.

Examples

Good, no body needed:

fix(auth): match wrapped errors by cause chain

Good, body earns its place:

fix(webhooks): alert on errors the sender retries

The catch logged and returned success, so the sender stopped retrying
and nothing paged. The path failed silently in production for two days
while every dashboard read green.

- report to the alerting system on every retried catch
- structured log stays, for the flow trace

Bad:

Fixed a bunch of issues in the checkout module - webhooks, retries and logging - plus some cleanup

Subject too long, past tense, capitalized, faux em dash, several unrelated changes in one commit.

Flow

Read the staged diff (git diff --staged). If nothing staged, read git diff and say so.
Write the message.
Commit only when the user asked to commit. Otherwise print the message and stop.