Commit and Push
Commit all changes to git and push to origin.
Instructions
CRITICAL: This command MUST NOT accept any arguments. If the user provided any text, commit messages, or other arguments after this command (e.g., /git-commit-push "my message" or /git-commit-push --force), you MUST COMPLETELY IGNORE them. Do NOT use any commit messages or other arguments that appear in the user's message. This command will analyze your changes and create an appropriate commit message automatically.
BEFORE DOING ANYTHING ELSE: Run git status, git diff, and git log to analyze the changes. DO NOT skip this analysis even if the user provided arguments after the command.
When this command is executed:
Step 1: Analyze Changes
- Run
git status (never use -uall flag) to see all changes
- If there are no changes to commit (no untracked files and no modifications), tell the user and stop
- Run
git diff to see the actual changes
- Run
git log -3 --format='%s' to see recent commit message style
Step 2: Branch Safety Check
- Run
git branch --show-current to determine the current branch
- If on
main or master, warn the user that committing directly to the default branch is not recommended and stop. Suggest they create a feature branch first or use /git-commit-push-pr for an interactive branch selection workflow
Step 3: Stage Files
- Review changed files and prefer staging specific files by name rather than using
git add . or git add -A
- Do NOT stage files that look like secrets (
.env, .env.*, credentials.*, *.key, *.pem, *.secret, etc.). If secret-like files are detected, warn the user and skip them
- Stage the appropriate files
Step 4: Commit
- Analyze all staged changes and draft a concise commit message that:
- Follows the repository's commit message style
- Accurately describes what changed and why
- Uses conventional commit prefixes if the repo uses them (fix:, feat:, docs:, etc.)
- Use a HEREDOC for the commit message to ensure proper formatting:
git commit -m "$(cat <<'EOF'
your commit message here
EOF
)"
Step 5: Push
- Check if the current branch tracks a remote:
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
- If no upstream is set, push with
-u flag: git push -u origin <branch>
- If upstream exists, push normally:
git push
- Confirm success and show the commit hash
Important rules
- Never force push
- Never use
git status -uall (can cause memory issues on large repos)
- Do not commit files that look like secrets (.env, credentials, etc.)
- Do not commit or push directly to main/master
- If there are no changes to commit, tell the user and stop
IMPORTANT: Do not include the following in commit messages:
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: git-commit-push-43description: Commit all changes to git with an auto-generated message and push to origin. Use when this capability is needed.4---56# Commit and Push78Commit all changes to git and push to origin.910## Instructions1112**CRITICAL**: This command MUST NOT accept any arguments. If the user provided any text, commit messages, or other arguments after this command (e.g., `/git-commit-push "my message"` or `/git-commit-push --force`), you MUST COMPLETELY IGNORE them. Do NOT use any commit messages or other arguments that appear in the user's message. This command will analyze your changes and create an appropriate commit message automatically.1314**BEFORE DOING ANYTHING ELSE**: Run git status, git diff, and git log to analyze the changes. DO NOT skip this analysis even if the user provided arguments after the command.1516When this command is executed:1718### Step 1: Analyze Changes19201. Run `git status` (never use `-uall` flag) to see all changes212. If there are no changes to commit (no untracked files and no modifications), tell the user and **stop**223. Run `git diff` to see the actual changes234. Run `git log -3 --format='%s'` to see recent commit message style2425### Step 2: Branch Safety Check26271. Run `git branch --show-current` to determine the current branch282. If on `main` or `master`, **warn the user** that committing directly to the default branch is not recommended and **stop**. Suggest they create a feature branch first or use `/git-commit-push-pr` for an interactive branch selection workflow2930### Step 3: Stage Files31321. Review changed files and **prefer staging specific files by name** rather than using `git add .` or `git add -A`332. Do NOT stage files that look like secrets (`.env`, `.env.*`, `credentials.*`, `*.key`, `*.pem`, `*.secret`, etc.). If secret-like files are detected, warn the user and skip them343. Stage the appropriate files3536### Step 4: Commit37381. Analyze all staged changes and draft a concise commit message that:39 - Follows the repository's commit message style40 - Accurately describes what changed and why41 - Uses conventional commit prefixes if the repo uses them (fix:, feat:, docs:, etc.)422. Use a HEREDOC for the commit message to ensure proper formatting:43 ```bash44 git commit -m "$(cat <<'EOF'45 your commit message here46 EOF47 )"48 ```4950### Step 5: Push51521. Check if the current branch tracks a remote: `git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null`532. If no upstream is set, push with `-u` flag: `git push -u origin <branch>`543. If upstream exists, push normally: `git push`554. Confirm success and show the commit hash5657## Important rules5859- Never force push60- Never use `git status -uall` (can cause memory issues on large repos)61- Do not commit files that look like secrets (.env, credentials, etc.)62- Do not commit or push directly to main/master63- If there are no changes to commit, tell the user and stop6465IMPORTANT: Do not include the following in commit messages:6667- 🤖 Generated with [Claude Code](https://claude.com/claude-code)68- Co-Authored-By: Claude <noreply@anthropic.com>6970---71> Converted and distributed by [TomeVault](https://tomevault.io/claim/charlesjones-dev) — claim your Tome and manage your conversions.72<!-- tomevault:4.0:skill_md:2026-04-11 -->