commit

Files (3)

• SKILL.md
• good-bad-messages.md · examples/
• session.md · examples/

SKILL.md (first lines)

Read current changes and create a proper commit following commit message rules and writing style guidelines.

## What This Command Does

**Input**: None (examines current git state)

**Output**: A commit with a properly formatted message

**Does NOT**:
- Run tests
- Run cleanup commands
- Modify code
- Stage files (assumes files are already staged or will stage all changes)

## Workflow

### Step 1: Read Rules

Read `~/.ai/rules/6_writing_style.md` for writing style guidelines.

Apply these commit message rules:

- Only mention things that are different from the last commit
- Do not mention intermediary steps or changes that were added and then removed within the same commit session
- Focus on the final state, not the process of getting there
- Keep explanation of what was done short, quick, and direct
- Only add additional context beyond the first line if explaining why or if something is not easily inferred from the code



### Step 2: Examine Changes

Run these git commands to understand what's being committed:

1. **Check status**: `git status`
   - See what files are staged/unstaged
   - Understand overall scope of changes

2. **View diff**: `git diff HEAD` or `git diff --cached` (if files are staged)
   - See actual changes being committed
   - Understand what was added, modified, or removed

3. **Check recent commits**: `git log -3 --oneline`
   - Understand commit message style in this repo
   - See what's been done recently for context

### Step 3: Determine What to Stage

**If files are already staged**:
- Use staged files as-is

**If no files are staged**:
- Stage all modified/new files: `git add -A`

### Step 4: Draft Commit Message

Following the commit message rules above and `6_writing_style.md`:

**Structure**:
```
[First line: concise description of what changed]

[Optional body: additional context if needed]
```

**Rules to follow**:
- **First line**: Short, direct, describes final state (not process)
- **Active voice**: "Add feature" not "Added feature" or "Feature was added"
- **Focus on what changed**: Only mention differences from last commit
- **No process details**: Don't mention "first tried X, then Y"
- **Simple language**: Use common words, be direct (per `6_writing_style.md`)
- **No buzzwords**: No corporate speak or passive voice
- **Body optional**: Only add if explaining why or if not easily inferred

### Step 5: Create Commit

Create the commit using heredoc format for proper formatting:

```bash
git commit -m "$(cat <<'EOF'
[Commit message first line]

[Optional body]
EOF
)"
```

## Anti-Patterns to AVOID

**DO NOT**:
- Make commits without examining the actual changes
- Write vague messages like "update files" or "fix issues"
- Bypass pre-commit hooks with `--no-verify`. If a hook fails, fix the cause (run the formatter/linter, e.g. `yarn purtyhere`) and commit again. See `~/.ai/rules/10_commit_standards.md`.

For message-style rules (active voice, no buzzwords, focus on final state, etc.) trust the commit message rules and `~/.ai/rules/6_writing_style.md` — already covered in Step 1 — instead of restating them here.

For a worked example session, see [examples/session.md](examples/session.md).

For good and bad commit message examples, see [examples/good-bad-messages.md](examples/good-bad-messages.md).

From MihaiOnSoftware/.ai, MIT.

More from MihaiOnSoftware/.ai