Cf Commit

---
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-09-09
---

# /cf-commit

Create a commit for the current changes. Hint: **$ARGUMENTS**

## Workflow

### Step 0: Custom Guide

```!
bash "<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
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.