feat: add commit message generator skill for concise message suggestions
This commit is contained in:
62
.factory/skills/commit_message/SKILL.md
Normal file
62
.factory/skills/commit_message/SKILL.md
Normal file
@@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
name: commit_message
|
||||||
|
description: Generate a concise one-liner commit message by analyzing staged changes and recent git history. Use when the user wants a commit message suggestion before committing.
|
||||||
|
user-invokable: true
|
||||||
|
disable-model-invocation: false
|
||||||
|
---
|
||||||
|
|
||||||
|
# Commit Message Generator
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
Generate a concise, meaningful one-liner commit message by inspecting the staged diff and recent commit history. Sometimes staged files relate to a prior commit, so the previous commit is also reviewed for context.
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Step 1: Gather Context
|
||||||
|
|
||||||
|
Run these commands to collect the necessary information:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Get the last commit message and diff for context
|
||||||
|
git log -1 --format="%h %s" && echo "---" && git diff HEAD~1 --stat
|
||||||
|
|
||||||
|
# Get the staged diff (what will be committed)
|
||||||
|
git diff --staged
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 2: Analyze the Changes
|
||||||
|
|
||||||
|
- Read the staged diff to understand **what** changed.
|
||||||
|
- Read the last commit (`git log -1`) to understand if the staged changes are a continuation, fix, or follow-up to the previous commit.
|
||||||
|
- If staged files overlap with files in the last commit, treat the changes as related and reflect that in the message.
|
||||||
|
|
||||||
|
### Step 3: Generate the Message
|
||||||
|
|
||||||
|
Compose a **single-line** commit message following these rules:
|
||||||
|
|
||||||
|
- **Format:** `<type>: <concise description>`
|
||||||
|
- **Types:** `feat`, `fix`, `refactor`, `docs`, `style`, `test`, `chore`, `perf`, `ci`, `build`
|
||||||
|
- **Length:** Under 72 characters
|
||||||
|
- **Tone:** Imperative mood ("add", "fix", "update", not "added", "fixed", "updated")
|
||||||
|
- **No period** at the end
|
||||||
|
|
||||||
|
### Step 4: Output
|
||||||
|
|
||||||
|
Print only the suggested commit message — nothing else. No explanation, no alternatives.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
```
|
||||||
|
feat: add retry logic to API client
|
||||||
|
fix: correct off-by-one error in pagination
|
||||||
|
refactor: extract auth middleware into separate module
|
||||||
|
docs: update README with new installation steps
|
||||||
|
chore: bump dependencies to latest versions
|
||||||
|
```
|
||||||
|
|
||||||
|
## Tips
|
||||||
|
|
||||||
|
- If the staged diff is empty, inform the user: "No staged changes found. Stage files with `git add` first."
|
||||||
|
- If the staged changes clearly extend the previous commit (same files, same feature), phrase the message as a continuation rather than a new change.
|
||||||
|
- Keep it specific — avoid vague messages like "update code" or "fix stuff".
|
||||||
Reference in New Issue
Block a user