--- 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] --- # /cf-commit Create a commit for the current changes. Hint: **$ARGUMENTS** ## Workflow ### Step 0: Custom Guide Run: `bash "${CLAUDE_PLUGIN_ROOT}/lib/load-custom-guide.sh" cf-commit` If output is not empty, integrate the returned sections into this workflow: - `## Before` → execute before the first step - `## Rules` → apply as additional rules throughout all steps - `## After` → execute after the final step ### Step 1: Analyze Changes ```bash 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 bash "${CLAUDE_PLUGIN_ROOT}/skills/cf-commit/scripts/scan-secrets.sh" ``` The script prints `SECRETS=` 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 `), 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: ``` (): ``` Types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `style`, `perf`, `ci` Rules: - Subject line < 72 characters - Body explains the motivation ("why"), not the mechanics ("what") - 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 "" ``` 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.