| name | cf-commit |
| description | Smart conventional commit with diff analysis. Use when the user wants to commit changes — e.g. "commit this", "commit my changes", "save my work", "create a commit", "git commit", "commit what we did", "stage and commit". Also triggers when the user finishes a task and wants to commit the result.
|
| disable-model-invocation | true |
| model | haiku |
| allowed-tools | ["Bash","Read","Glob"] |
| created | 2026-02-17T00:00:00.000Z |
| updated | 2026-07-04T00:00:00.000Z |
/cf-commit
CLI Requirement: NONE — Works without coding-friend-cli. See CLI requirements for the full matrix.
Create a commit for the current changes. Hint: $ARGUMENTS
Workflow
Step 0: Custom Guide
Custom guide — auto-loaded below (if the raw command shows instead of its output, run it yourself):
bash "${CLAUDE_PLUGIN_ROOT}/lib/load-custom-guide.sh" cf-commit
If output is not empty, integrate returned sections: ## Before → before first step, ## Rules → apply throughout, ## After → after final step.
Step 1: Analyze Changes
bash "${CLAUDE_PLUGIN_ROOT}/skills/cf-commit/scripts/analyze-changes.sh"
Step 2: Identify Conversation-Related Changes
Review the current conversation to understand what task was performed and which files were modified as part of that task.
- Prioritize changes from the current conversation — files you edited or created during this session are the primary candidates for this commit
- Separate unrelated changes — if
git status shows files that were NOT part of the current task, do NOT include them
- If ALL changes are from the current conversation, proceed normally
- If there is a mix, clearly tell the user which files you will stage and which you will skip (and why)
Step 3: Stage & Scan
- Stage only files relevant to the current conversation's task
- Do NOT stage unrelated changes from other work
- Do NOT stage
.env, credentials, or secrets
- Do NOT use
git add . or git add -A
Secret scan — after staging, check for accidental secrets:
bash "${CLAUDE_PLUGIN_ROOT}/skills/cf-commit/scripts/scan-secrets.sh"
The script prints SECRETS=<count> and, if SECRETS > 0, shows matching lines with context.
If SECRETS > 0:
- Review each match — variable names like
getApiKey() or TOKEN_TYPE are OK, actual secret values are NOT
- If real secrets found: unstage the file (
git reset HEAD <file>), suggest adding to .gitignore
- If all matches are false positives (code references, not actual secrets): proceed
Step 4: Review Check
If no /cf-review was run in the current conversation, show a soft suggestion:
No review found in this session — run /cf-review first? (press Enter to skip and commit anyway)
If the user skips (presses Enter or says to proceed), continue. If they want a review, load /cf-review and resume /cf-commit after.
Step 5: Write Commit Message
Follow conventional commits format:
<type>(<scope>): <subject>
<body - optional, concise bullet list>
Types: feat, fix, refactor, test, docs, chore, style, perf, ci
Rules:
- Subject line < 72 characters
- Keep the body short. Prefer a subject-only commit for small changes — add a body only when the change is non-obvious.
- Body must be a concise bullet list, not prose:
- Use
- bullets, one line per bullet
- Max 4 bullets; each bullet ≤ 72 characters
- No trailing explanations, no paragraphs, no marketing/filler words
- Focus on "what" — skip "why" unless non-obvious
- If
$ARGUMENTS is provided, use it as context for the message
- Reference issue numbers if applicable
- NEVER include AI/agent attribution (no "Co-Authored-By", "Generated by", "Claude", "Copilot", "AI-assisted", etc.)
Step 6: Commit
git commit -m "<message>"
Show the commit result to the user.
Completion Protocol
- DONE — Commit created. Show: commit hash, message, files committed.
- DONE_WITH_CONCERNS — Commit created but with caveats (e.g., some tests skipped, unrelated changes exist). Show: what was committed + concerns.
- BLOCKED — Cannot commit. Show: why (tests failing, no changes, secret detected). Suggest next action.
