rails-cto-commit
Skill15 starsChanged 7 months agoMITView on GitHub
Stage and commit all outstanding code changes with a clear, human-friendly commit message. Use this skill whenever the user asks to commit, save their work, push changes, or says things like "commit this", "save my progress", "push this up", "ship it", "commit all", or "commit and push". Also triggers for "/commit-all". Do NOT use for cherry-picking, rebasing, or other advanced git operations.
- Reads credentials
- Commits and pushes
In this repository17 other files it gives its agents.
- claude/CLAUDE.mdCLAUDE.md
- rails-cto-apiSkill
- rails-cto-architectSkill
- rails-cto-engineerSkill
- rails-cto-erbSkill
- rails-cto-minitestSkill
- rails-cto-production-prSkill
- rails-cto-pull-requestSkill
- rails-cto-qaSkill
- rails-cto-restfulSkill
- rails-cto-securitySkill
- rails-ctoSkill
- rails-cto-static-analysisSkill
- rails-cto-stimulusSkill
- rails-cto-tailwindSkill
- rails-upgradeSkill
- rails-viewcomponentsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 14 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
3
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
- Distinctive: line 14
Run these in parallel to understand what's changed:
- Distinctive: line 21
If there are no changes to commit (nothing untracked, nothing modified, nothing staged), tell the user and stop.
- Distinctive: line 25
Add all changes — tracked and untracked — to the staging area:
- Very specific: line 31
If any files look like they contain secrets (.env, credentials, tokens, API keys), warn the user and exclude them before committing.
- Distinctive: line 35
Write a commit message that a non-technical person could understand.
- Distinctive: line 38
Use plain language. Avoid jargon, abbreviations, and technical shorthand.
- Distinctive: line 40
Keep the subject line under 72 characters.
- Distinctive: line 41
If the change is complex, add a blank line and a short body paragraph explaining the "why."
- Very specific: line 42
Do NOT include any co-authorship lines (no Co-Authored-By).
- Distinctive: line 43
Do NOT reference "Claude" or any AI tool in the message.
- Distinctive: line 57
Use a HEREDOC to pass the message so multi-line messages format correctly:
- Distinctive: line 70
After committing, ask the user if they want to push to the remote.
- Distinctive: line 72
If they say yes:
- Very specific: line 73
If the branch has no upstream, use git push -u origin <branch> to set tracking.
- Distinctive: line 74
If it does, use git push.
- Distinctive: line 75
Never force-push unless the user explicitly asks for it.
- Distinctive: line 78
If they say no or don't mention pushing, just confirm the commit was made and stop.
≈ “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.
Files
Commit
Stage and commit all outstanding changes with a clear, human-friendly message. Optionally push to the remote — but only after the user confirms.
Workflow
1. Gather context
Run these in parallel to understand what's changed:
git status— see untracked and modified filesgit diff— see unstaged changesgit diff --cached— see already-staged changesgit log --oneline -5— see recent commit style for reference
If there are no changes to commit (nothing untracked, nothing modified, nothing staged), tell the user and stop.
2. Stage everything
Add all changes — tracked and untracked — to the staging area:
git add -AIf any files look like they contain secrets (.env, credentials, tokens, API keys), warn the user and exclude them before committing.
3. Write the commit message
Write a commit message that a non-technical person could understand. The goal is clarity — someone glancing at the git log should immediately know what changed and why.
Rules:
- Use plain language. Avoid jargon, abbreviations, and technical shorthand.
- Lead with what the change accomplishes from a user or product perspective, not implementation details.
- Keep the subject line under 72 characters.
- If the change is complex, add a blank line and a short body paragraph explaining the "why."
- Do NOT include any co-authorship lines (no
Co-Authored-By). - Do NOT reference "Claude" or any AI tool in the message.
Good examples:
Add password reset flow for logged-out usersFix broken checkout button on mobile screensUpdate pricing page to show annual discountRemove unused admin dashboard pages
Bad examples:
refactor: extract util fn for auth middleware(too technical)fix bug(too vague)WIP(not descriptive)Update files(says nothing)
Use a HEREDOC to pass the message so multi-line messages format correctly:
git commit -m "$(cat <<'EOF'
Your commit subject line here
Optional body explaining why, if needed.
EOF
)"4. Confirm before pushing
After committing, ask the user if they want to push to the remote. Do not push automatically.
If they say yes:
- If the branch has no upstream, use
git push -u origin <branch>to set tracking. - If it does, use
git push. - Never force-push unless the user explicitly asks for it.
- Warn and refuse if the target is
mainormaster(unless the user insists).
If they say no or don't mention pushing, just confirm the commit was made and stop.
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
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.

