agentleFS
mystilleefmystilleef/spae-framework/skills/auto-commit/SKILL.md

auto-commit

Skill2 starsChanged 14 days agoMITView on GitHub

- Invoke for any repository with pending changes that should land as atomic commits. - Execute immediately upon invocation. Never wait for user input or confirmation before git status. - Analyze repository changes, form safe atomic groups, block secrets, stage targeted files, and create conventional commits in the current project. - Commit all eligible current-project changes as separate, logical, atomic commits. - Leave the working tree clean unless safety checks or git errors block completion. Determine input from the current…

  • Reads credentials

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 10 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Commit all eligible current-project changes as separate, logical, atomic commits.

    line 24
  2. Distinctive:

    Leave the working tree clean unless safety checks or git errors block completion.

    line 26
  3. Very specific:

    Commit message rules from references/conventional-commit.md.

    line 36
  4. Distinctive:

    Atomic Grouping: Commit files together only when they must change together, such as implementation plus matching tests.

    line 63
  5. Very specific:

    Gitignore Isolation: Commit .gitignore changes separately.

    line 65
  6. Very specific:

    On Secret Match: Run git --no-pager restore --staged -- <files>, halt, and report only file paths plus matched rule names.

    line 80
  7. Very specific:

    Git Commands: Use --no-pager for every git invocation.

    line 83
  8. Distinctive:

    Generated Files: Avoid staging sensitive or build-related files unless source control should track them.

    line 85
  9. Distinctive:

    No user approval for staging, messages, or commits.

    line 94
  10. Distinctive:

    No dependency on other skills.

    line 95
  11. Distinctive:

    No flagged secret, credential, or unsafe generated file may enter a commit.

    line 96
  12. Distinctive:

    Commit messages follow conventional commit format.

    line 106
  13. Distinctive:

    Keep prose terse while ensuring clarity.

    line 113
  14. Distinctive:

    Use lists and sub-lists for long sentences and dense paragraphs.

    line 116

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “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

Auto-commit agent

When to use

  • Invoke for any repository with pending changes that should land as atomic commits.
  • Execute immediately upon invocation. Never wait for user input or confirmation before git status.

Goal

  • Analyze repository changes, form safe atomic groups, block secrets, stage targeted files, and create conventional commits in the current project.
  • Commit all eligible current-project changes as separate, logical, atomic commits.
  • Leave the working tree clean unless safety checks or git errors block completion.

Input

Determine input from the current repository state:

  • Tracked, untracked, staged, unstaged, renamed, deleted, and ignored changes reported by git.
  • Atomic grouping heuristics from references/atomic-git-staging.md.
  • Commit message rules from references/conventional-commit.md.

Workflow

  1. GATE—Run git --no-pager status --porcelain=v2 --branch. Halt on no changes or git error.
  2. ORIENT—Goal: commit all eligible changes as atomic commits. Scope: current project. No changes outside git state.
  3. PLAN—Group files into logical commits. Isolate .gitignore changes. Apply fast path for a single unstaged file.
  4. ACT (repeat steps 4–6 per group until no eligible changes remain)—
    • Scan candidate paths and content for secrets (pre-stage).
    • Run git --no-pager diff --no-ext-diff --stat --minimal --patience --histogram --find-renames --summary --no-color -U10 <file_group>.
    • Run git --no-pager add <file1> <file2> ....
    • Scan staged diff for secrets (pre-commit).
    • Generate conventional commit message.
  5. VERIFY—Confirm staged diff matches intent and all secret checks pass. On failure: unstage, halt, report.
  6. PERSIST—Run git --no-pager commit -m "<message>". Confirm commit success.
  7. REPORT—Emit the result following the result directives and using the result template.

Directives

  • Atomic Grouping: Commit files together only when they must change together, such as implementation plus matching tests.
  • Gitignore Isolation: Commit .gitignore changes separately.
  • Sensitive Path Rules: Hard-block .env* except .env.example, *.key, *.pem, *.p12, *.pfx, *_rsa, *_dsa, id_*, secrets.*, credentials.*, .aws/, .ssh/, and .gnupg/.
<!-- vale off -->
  • Sensitive Content Rules: Hard-block real credential indicators: password=..., token: ..., api_key = ..., Bearer <value>, cloud/GitHub/Slack/OpenAI token prefixes with non-placeholder values, and private key blocks. Do not block policy text that merely names secret types or placeholder examples.
<!-- vale on -->
  • On Secret Match: Run git --no-pager restore --staged -- <files>, halt, and report only file paths plus matched rule names. Never print secret values, request overrides, or commit flagged files.
  • Git Commands: Use --no-pager for every git invocation; scope --no-ext-diff to git diff operations.
  • Generated Files: Avoid staging sensitive or build-related files unless source control should track them.
  • Efficiency: Batch operations by file group, target only relevant files, parallelize independent read-only checks when useful, and reduce output.

Constraints

  • Current project only.
  • No user approval for staging, messages, or commits.
  • No dependency on other skills; perform git commands directly.
  • No flagged secret, credential, or unsafe generated file may enter a commit.
  • Halt immediately on git errors, failed secret scans, or ambiguous safety state.

Verification

  • Working tree ends clean, or remaining files have explicit safety or error reasons.
  • Each commit contains one logical change.
  • Commit messages follow conventional commit format.
  • Commits exclude sensitive and inappropriate build-related files.
  • Final report lists commit hashes and subjects or explains failure.

Result directives

  • Minimum words. Maximum signal.
  • Keep prose terse while ensuring clarity.
  • Optimize prose for agent, token, and context efficiency.
  • Split actions, findings, and summaries into terse bullet points.
  • Use lists and sub-lists for long sentences and dense paragraphs.
  • Emit the result template as live markdown—never in a code fence.
  • Output nothing outside the template.

Result template

<!-- prettier-ignore-start -->
### Execution Summary

- **Actions**:
  - [Terse list of actions taken]
- **Files**:
  - [Terse list of affected files]
- **Findings**:
  - [Terse list of notable findings]
- **Commits**:
  - [Commit hash and subject per created commit]

> **Commit Status** • `[scope]`
> **Result**: [Committed | Clean Tree | Failed]
> **Impact**: [Terse impact statement]
>
> _[Terse working tree summary]_
<!-- prettier-ignore-end -->

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.