kn-commit

---
name: kn-commit
description: Use when committing code changes with proper conventional commit format and verification
---

# Committing Changes

**Announce:** "Using kn-commit to commit changes."

**Core principle:** VERIFY BEFORE COMMITTING - check staged changes, ask for confirmation.

## Inputs

- Current staged changes
- Relevant task IDs, scope, and reason for the change

## Preflight

- Confirm the correct files are staged
- Check whether the commit should reference a task or feature area
- Refuse to commit if the staged diff looks unrelated or mixed across multiple concerns

## Step 1: Review Staged Changes

```bash
git status
git diff --staged
```

## Step 2: Generate Commit Message

**Format:**
```
<type>(<scope>): <message>

- Bullet point summarizing change
```

**Types:** feat, fix, docs, style, refactor, perf, test, chore

**Rules:**
- Title lowercase, no period, max 50 chars
- Body explains *why*, not just *what*

## Step 3: Ask for Confirmation

```
Ready to commit:

feat(auth): add JWT token refresh

- Added refresh token endpoint

Proceed? (yes/no/edit)
```

**Wait for user approval.**

## Step 4: Commit

```bash
git commit -m "feat(auth): add JWT token refresh

- Added refresh token endpoint"
```

## Final Response Contract

All built-in skills in scope must end with the same user-facing information order: `kn-init`, `kn-spec`, `kn-plan`, `kn-research`, `kn-implement`, `kn-verify`, `kn-doc`, `kn-template`, `kn-extract`, and `kn-commit`.

Required order for the final user-facing response:

1. Goal/result - state whether a commit was proposed, blocked, or created.
2. Key details - include the proposed or final commit message, relevant diff concerns, and approval status.
3. Next action - recommend a concrete follow-up command only when a natural handoff exists.

Keep this concise for CLI use. Skill-specific content may extend the key-details section, but must not replace or reorder the shared structure.

Out of scope: explaining, syncing, or generating `.claude/skills/*`. Runtime auto-sync already handles platform copies, so this skill source only defines the built-in output contract.

For `kn-commit`, the key details should cover:

- the proposed commit title
- 1 short body explaining why
- any concerns about the staged diff
- a clear approval prompt

## Guidelines

- Only commit staged files
- NO "Co-Authored-By" lines
- NO "Generated with Claude Code" ads
- Ask before committing

## Next Step Suggestion

When a follow-up is natural, recommend exactly one next command:

- after proposing a commit: no command, wait for approval
- after a successful commit tied to active work: `/kn-verify`
- after a successful standalone commit: `/kn-extract` or the next task-specific workflow command if one is obvious

## Checklist

- [ ] Reviewed staged changes
- [ ] Message follows convention
- [ ] User approved
- [ ] Next action suggested when applicable

## Abort Conditions

- Nothing staged
- Staged diff includes unrelated work that should be split
- User has not explicitly approved the final message