/commit-push-pr
Commit changes, push to GitHub, and open a PR. Includes quality checks (security, patterns, simplification). Use --quick to skip checks.
$ npx -y skills add llama-farm/llamafarm --skill commit-push-pr --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/commit-push-pr
Context preview
The summary Claude sees to decide when to auto-load this skill.
Commit changes, push to GitHub, and open a PR. Includes quality checks (security, patterns, simplification). Use --quick to skip checks.
SKILL.md
commit-push-pr.SKILL.mdname: commit-push-pr
description: Commit changes, push to GitHub, and open a PR. Includes quality checks (security, patterns, simplification). Use --quick to skip checks.
allowed-tools: Bash, Read, Write, Edit, Grep, Glob, AskUserQuestion
Commit, Push & PR Skill
Automates the git workflow of committing changes, pushing to GitHub, and opening a PR with intelligent handling of edge cases.
Required Reading
Before executing, internalize the git workflow standards: @.claude/rules/git_workflow.md
Key rules:
- Use Conventional Commits format: `type(scope): description`
- **NEVER attribute Claude** in commits or PRs (no co-author, no mentions)
- **NEVER skip pre-commit hooks** (no `--no-verify`)
---
Execution Workflow
Step 1: Assess Git State
Run these commands to understand the current state:
# Detect the default branch (main, master, etc.)
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
# Fallback if symbolic-ref fails (e.g., shallow clone or missing HEAD)
if [ -z "$DEFAULT_BRANCH" ]; then
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
fi
# Final fallback to 'main' if detection fails
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
# Get current branch
BRANCH=$(git branch --show-current)
# Check for uncommitted changes
git status --porcelain
# Check for unpushed commits (if branch has upstream)
git log origin/$DEFAULT_BRANCH..HEAD --oneline 2>/dev/null || echo "No upstream or no commits ahead"
# Check if branch has upstream tracking
git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "No upstream"Determine the state:
- `HAS_CHANGES`: Are there uncommitted changes (staged, unstaged, or untracked)?
- `HAS_UNPUSHED`: Are there commits ahead of origin/$DEFAULT_BRANCH?
- `ON_DEFAULT_BRANCH`: Is current branch the default branch ($DEFAULT_BRANCH)?
- `HAS_UPSTREAM`: Does the branch track a remote?
Step 2: Handle "Nothing to Do" Case
If `!HAS_CHANGES && !HAS_UNPUSHED`:
Inform user: "No changes to commit and no unpushed commits. Nothing to do."
Exit gracefully.
Step 3: Handle "No Changes But Unpushed Commits" Case
If `!HAS_CHANGES && HAS_UNPUSHED`:
1. Check if PR already exists:
gh pr list --head "$(git branch --show-current)" --json number,url,title
2. If PR exists:
- Offer to push updates to the existing PR
- Report the PR URL
3. If no PR:
- Offer to push and create a new PR
- Proceed to Step 7
Step 4: Branch Management (if HAS_CHANGES)
**If on default branch ($DEFAULT_BRANCH):**
1. Inform user that changes need to go on a feature branch 2. Stage changes first to analyze them:
git add -A
git diff --staged --stat
3. Generate a conventional commit message based on the changes (see Step 5)
4. Derive branch name from commit message:
- `feat(cli): add project list` → `feat-cli-add-project-list`
- `fix: resolve memory leak` → `fix-resolve-memory-leak`
- Rules: lowercase, replace spaces/special chars with hyphens, max 50 chars
5. Create and checkout the new branch:
git checkout -b <branch-name>
**If already on feature branch:**
- Continue with the existing branch
- Check if PR exists for context
Step 5: Stage Changes and Generate Commit Message
1. Stage all changes:
git add -A
2. Analyze the staged changes:
git diff --staged --stat
git diff --staged
3. Generate a conventional commit message based on:
- Files changed (infer scope from directory)
- Nature of changes (feat/fix/refactor/docs/test/chore)
- Summarize the "why" not just the "what"
4. Present the commit message to the user. Example format:
Proposed commit message:
feat(cli): add project listing command
Adds a new 'lf project list' command that displays all projects
in the current workspace with their status.
Do you want to use this message, modify it, or provide your own?
Step 5.5: Quality Check
**Skip if**: `--quick` flag was passed.
Run quality checks on staged changes before committing.
1. Auto-fix trivial issues (no prompt needed)
Search for and remove debug statements:
# Find files with debug statements
git diff --staged --name-only | xargs grep -l -E "(console\.(log|debug|info)|debugger|print\()" 2>/dev/null
For each file found:
- Remove `console.log(...)`, `console.debug(...)`, `console.info(...)` statements
- Remove `debugger;` statements
- Remove `print(...)` statements (Python)
- Re-stage the file after fixes
Report: "Auto-fixed: Removed N debug statements from M files"
2. Check for issues requiring attention
Scan staged diff for:
| Issue | Severity | Action | |-------|----------|--------| | Hardcoded secrets (API keys, passwords) | BLOCK | Cannot auto-fix - user must remove | | Command injection (`shell=True`, `os.system`) | BLOCK | Cannot auto-fix - user must refactor | | Empty catch/except blocks | PROPOSE | Suggest adding error logging | | Duplicate code patterns | PROPOSE | Suggest extraction | | Unused imports | PROPOSE | Suggest removal | | TODO/FIXME comments | WARN | Note but allow proceed |
3. Handle blocking issues
If BLOCK issues found:
- List each issue with file:line reference
- Stop the workflow
- User must fix manually and re-run
4. Handle proposable fixes
For each PROPOSE issue:
- Show: file, line, problem, suggested fix
- Ask: "Apply this fix? (y/n/all/skip)"
- If approved: apply edit, re-stage
- If skipped: continue without fix
5. Handle warnings
For WARN issues:
- Display summary
- Continue without blocking
---
Step 6: Create the Commit
Create the commit with the approved message:
git commit -m "$(cat <<'EOF'
type(scope): short description
Optional longer description explaining the change.
EOF
)"
**Important:**
- Use HEREDOC for multi-line messages
- Never add co-author or Claude attribution
- Let pre-commit hooks run (never use `--no-verify`)
Read more
name: commit-push-pr description: Commit changes, push to GitHub, and open a PR. Includes quality checks (security, patterns, simplification). Use --quick to skip checks. allowed-tools: Bash, Read, Write, Edit, Grep, Glob, AskUserQuestion
Commit, Push & PR Skill
Automates the git workflow of committing changes, pushing to GitHub, and opening a PR with intelligent handling of edge cases.
Required Reading
Before executing, internalize the git workflow standards: @.claude/rules/git_workflow.md
Key rules:
- Use Conventional Commits format: `type(scope): description`
- **NEVER attribute Claude** in commits or PRs (no co-author, no mentions)
- **NEVER skip pre-commit hooks** (no `--no-verify`)
---
Execution Workflow
Step 1: Assess Git State
Run these commands to understand the current state:
# Detect the default branch (main, master, etc.)
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
# Fallback if symbolic-ref fails (e.g., shallow clone or missing HEAD)
if [ -z "$DEFAULT_BRANCH" ]; then
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
fi
# Final fallback to 'main' if detection fails
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
# Get current branch
BRANCH=$(git branch --show-current)
# Check for uncommitted changes
git status --porcelain
# Check for unpushed commits (if branch has upstream)
git log origin/$DEFAULT_BRANCH..HEAD --oneline 2>/dev/null || echo "No upstream or no commits ahead"
# Check if branch has upstream tracking
git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "No upstream"Determine the state:
- `HAS_CHANGES`: Are there uncommitted changes (staged, unstaged, or untracked)?
- `HAS_UNPUSHED`: Are there commits ahead of origin/$DEFAULT_BRANCH?
- `ON_DEFAULT_BRANCH`: Is current branch the default branch ($DEFAULT_BRANCH)?
- `HAS_UPSTREAM`: Does the branch track a remote?
Step 2: Handle "Nothing to Do" Case
If `!HAS_CHANGES && !HAS_UNPUSHED`:
Inform user: "No changes to commit and no unpushed commits. Nothing to do." Exit gracefully.
Step 3: Handle "No Changes But Unpushed Commits" Case
If `!HAS_CHANGES && HAS_UNPUSHED`:
1. Check if PR already exists:
gh pr list --head "$(git branch --show-current)" --json number,url,title
2. If PR exists:
- Offer to push updates to the existing PR
- Report the PR URL
3. If no PR:
- Offer to push and create a new PR
- Proceed to Step 7
Step 4: Branch Management (if HAS_CHANGES)
**If on default branch ($DEFAULT_BRANCH):**
1. Inform user that changes need to go on a feature branch 2. Stage changes first to analyze them:
git add -A git diff --staged --stat
3. Generate a conventional commit message based on the changes (see Step 5)
4. Derive branch name from commit message:
- `feat(cli): add project list` → `feat-cli-add-project-list`
- `fix: resolve memory leak` → `fix-resolve-memory-leak`
- Rules: lowercase, replace spaces/special chars with hyphens, max 50 chars
5. Create and checkout the new branch:
git checkout -b <branch-name>
**If already on feature branch:**
- Continue with the existing branch
- Check if PR exists for context
Step 5: Stage Changes and Generate Commit Message
1. Stage all changes:
git add -A
2. Analyze the staged changes:
git diff --staged --stat git diff --staged
3. Generate a conventional commit message based on:
- Files changed (infer scope from directory)
- Nature of changes (feat/fix/refactor/docs/test/chore)
- Summarize the "why" not just the "what"
4. Present the commit message to the user. Example format:
Proposed commit message: feat(cli): add project listing command Adds a new 'lf project list' command that displays all projects in the current workspace with their status. Do you want to use this message, modify it, or provide your own?
Step 5.5: Quality Check
**Skip if**: `--quick` flag was passed.
Run quality checks on staged changes before committing.
1. Auto-fix trivial issues (no prompt needed)
Search for and remove debug statements:
# Find files with debug statements git diff --staged --name-only | xargs grep -l -E "(console\.(log|debug|info)|debugger|print\()" 2>/dev/null
For each file found:
- Remove `console.log(...)`, `console.debug(...)`, `console.info(...)` statements
- Remove `debugger;` statements
- Remove `print(...)` statements (Python)
- Re-stage the file after fixes
Report: "Auto-fixed: Removed N debug statements from M files"
2. Check for issues requiring attention
Scan staged diff for:
| Issue | Severity | Action | |-------|----------|--------| | Hardcoded secrets (API keys, passwords) | BLOCK | Cannot auto-fix - user must remove | | Command injection (`shell=True`, `os.system`) | BLOCK | Cannot auto-fix - user must refactor | | Empty catch/except blocks | PROPOSE | Suggest adding error logging | | Duplicate code patterns | PROPOSE | Suggest extraction | | Unused imports | PROPOSE | Suggest removal | | TODO/FIXME comments | WARN | Note but allow proceed |
3. Handle blocking issues
If BLOCK issues found:
- List each issue with file:line reference
- Stop the workflow
- User must fix manually and re-run
4. Handle proposable fixes
For each PROPOSE issue:
- Show: file, line, problem, suggested fix
- Ask: "Apply this fix? (y/n/all/skip)"
- If approved: apply edit, re-stage
- If skipped: continue without fix
5. Handle warnings
For WARN issues:
- Display summary
- Continue without blocking
---
Step 6: Create the Commit
Create the commit with the approved message:
git commit -m "$(cat <<'EOF' type(scope): short description Optional longer description explaining the change. EOF )"
**Important:**
- Use HEREDOC for multi-line messages
- Never add co-author or Claude attribution
- Let pre-commit hooks run (never use `--no-verify`)
Enterprise AI capabilities on your own hardware. No cloud required. LlamaFarm is an open-source AI platform that runs entirely on your hardware.
Repo: llama-farm/llamafarm
Other skills on llamafarm.
- /cli-skills
CLI best practices for LlamaFarm. Covers Cobra, Bubbletea, Lipgloss patterns for Go CLI development.
Open skill - /code-review
Comprehensive code review for diffs. Analyzes changed code for security vulnerabilities, anti-patterns, and quality issues. Auto-detects domain (frontend/backend) from file paths.
Open skill - /common-skills
Best practices for the Common utilities package in LlamaFarm. Covers HuggingFace Hub integration, GGUF model management, and shared utilities.
Open skill - /config-skills
Configuration module patterns for LlamaFarm. Covers Pydantic v2 models, JSONSchema generation, YAML processing, and validation.
Open skill - /designer-skills
Designer subsystem patterns for LlamaFarm. Covers React 18, TanStack Query, TailwindCSS, and Radix UI.
Open skill - /electron-skills
Electron patterns for LlamaFarm Desktop. Covers main/renderer processes, IPC, security, and packaging.
Open skill

