From compound-engineering
Creates git commits with clear messages from working tree changes, following repo conventions or conventional commits. Handles clean trees and detached HEAD.
npx claudepluginhub everyinc/compound-engineering-plugin --plugin compound-engineeringThis skill uses the workspace's default tool permissions.
Create a single, well-crafted git commit from the current working tree changes.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Create a single, well-crafted git commit from the current working tree changes.
If you are not Claude Code, skip to the "Context fallback" section below and run the command there to gather context.
If you are Claude Code, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.
Git status:
!git status
Working tree diff:
!git diff HEAD
Current branch:
!git branch --show-current
Recent commits:
!git log --oneline -10
Remote default branch:
!git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
If you are Claude Code, skip this section — the data above is already available.
Run this single command to gather all context:
printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'
Use the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.
The remote default branch value returns something like origin/main. Strip the origin/ prefix to get the branch name. If it returned __DEFAULT_BRANCH_UNRESOLVED__ or a bare HEAD, try:
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
If both fail, fall back to main.
If the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.
If the current branch from the context above is empty, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding.
git checkout -b <branch-name>, then run git branch --show-current again and use that result as the current branch name for the rest of the workflow.Follow this priority order:
type(scope): description where type is one of feat, fix, docs, refactor, test, chore, perf, ci, style, build.Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.
Keep this lightweight:
git add -p or try to split hunks within a file.If the current branch from the context above is main, master, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content, create it with git checkout -b <branch-name>, then continue.
Write the commit message:
For each commit group, stage and commit in a single call. Prefer staging specific files by name over git add -A or git add . to avoid accidentally including sensitive files (.env, credentials) or unrelated changes. Use a heredoc to preserve formatting:
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
Run git status after the commit to verify success. Report the commit hash(es) and subject line(s).