agentleFS
Sign inStart free
emiliodominguezemiliodominguez/flow-skills/skills/flow-commit/SKILL.md

flow-commit

Skill1 starsChanged 46 days agoMITView on GitHub

Conventional commit messages and atomic commits. Use when asked only for a commit message or a commit; message-only requests never touch Git. Hands off to `flow-ship` when a push or review request was asked for.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify commit contents and remaining worktree.

    line 35
  2. Distinctive:

    If committing was requested, the commit matches the intended scope, passes required checks, and unrelated changes are preserved.

    line 48
  3. Very specific:

    Use flow-ship only for delivery actions already in the user's request.

    line 51

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Commit

Make one logical change understandable from history. A message draft, permission to commit, and pushing or opening a pull or merge request are separate outcomes.

Process

Decide the mode first. "Write a commit message" or "message for my staged changes" returns text only: no git add, no git commit, and say that nothing was committed.

  1. Inspect branch, status, staged, unstaged and relevant untracked changes. Read the index with git diff --cached; git diff alone misses staged content. Preserve unrelated staging and working files.
  2. Group changes by intent. Keep tests, generated artifacts and docs with the behavior they support; don't split an inseparable change to shrink file count.
  3. Conventional subject: type(scope): imperative description, following the repository's types, scopes, length and language. Describe the effect, not a file list.
  4. Body: the why and the user-visible effect in one plain sentence (for example "Exports over 10k rows now run in the background and email a download link."), plus constraints, significant tradeoffs and breaking-change migration notes. Never invent rationale or claim unrun checks. Follow the repository's Co-Authored-By / generated-credit convention.
  5. Message-only request: return the message and stop. Authorized commit: stage only intended paths/hunks. Use git add -p when interactive; in a noninteractive host use scoped paths or inspected patches rather than hanging.
  6. Inspect the final index, run the required gate, commit with hooks enabled. A failed plain commit creates nothing, so a retry must not amend the previous good commit. After an interrupted explicit amend, check HEAD before retrying.
  7. Verify commit contents and remaining worktree. Report SHA and scope; never claim it is pushed without remote confirmation.

Anti-patterns

  • git add . with unrelated changes in the index or working tree.
  • Mutating Git for "write me a commit message".
  • Bypassing hooks, weakening checks, or amending an unrelated commit after a failure.
  • Shell-interpolating a multi-line message; use a file or structured argument.

Done when

  • The message describes one logical change and its reason.
  • If committing was requested, the commit matches the intended scope, passes required checks, and unrelated changes are preserved.

Use flow-ship only for delivery actions already in the user's request.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free