Immutable. This exact content is served forever at /api/v1/blob/a316d63cfc1e57dc.
--- name: cf-commit description: > Smart conventional commit with diff analysis. Triggers: "commit this", "commit my changes", "save my work", "create a commit", "git commit", "stage and commit". created: 2026-02-17 updated: 2026-08-27 --- # /cf-commit > **CLI Requirement:** NONE — Works without `coding-friend-cli`. See [CLI requirements](../../../docs/cli-requirements.md) 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 "<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 bash "<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 bash "<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`: 1. Review each match — variable names like `getApiKey()` or `TOKEN_TYPE` are OK, actual secret values are NOT 2. If real secrets found: unstage the file (`git reset HEAD <file>`), suggest adding to `.gitignore` 3. 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 ```bash 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.