dinhanhthi /cf-commit
Create a commit for the current changes. Hint: $ARGUMENTS
Workflow
Step 0: Custom Guide
bash "${CLAUDE_PLUGIN_ROOT}/lib/load-custom-guide.sh" cf-commit
If the block above printed anything, apply only the ## Before, ## Rules, and ## After sections; if it shows the raw command instead of output, re-run that exact load-custom-guide.sh fence now.
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 statusshows 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 .orgit 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()orTOKEN_TYPEare 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-reviewfirst? (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
- Use
- If
$ARGUMENTSis 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.