# 🗒️ Changelog Guide The `changelog` command automatically generates a `CHANGELOG.md` section based on your git history. It's designed to create professional, categorized changelogs that can be used directly for releases. ### Key Features - **Categorized Changes**: Automatically groups commits into `Added`, `Changed`, and `Fixed`. - **Gitea Compatible**: The output is formatted for easy pasting into Gitea release notes. - **Project Maintenance**: Automatically updates your existing `CHANGELOG.md` file. - **Smart Summaries**: Grok creates concise, imperative bullet points for each change. ### Usage Generate a clean `CHANGELOG.md` section from git history, designed specifically so the output can be pasted directly into Gitea release notes. ```bash # 1. Create your version tag first git tag v0.2.0 # 2. Generate preview + write (with safety confirmation) grokkit changelog # 3. Output ONLY the new section (perfect for Gitea "Release notes") grokkit changelog --stdout # 4. Write file + get commit reminder grokkit changelog --commit ``` ### Options | Flag | Description | |------|-------------| | `--since` | Start from this tag/ref (default: previous tag) | | `--version`, `-V` | Override the version number for the header (default: latest git tag) | | `--stdout` | Print ONLY the new section (useful for pasting into release notes) | | `--commit` | Reminds you to commit the changes after updating the file | | `--model`, `-m` | Override the default model (e.g., `grok-4`) | ### How it Works 1. **History Retrieval**: Grokkit finds the commits since the last tag. 2. **Categorization**: It sends the commit history to Grok to be categorized and summarized. 3. **Markdown Generation**: Grok returns a formatted markdown section. 4. **File Update**: Grokkit prepends the new section to your `CHANGELOG.md` or creates it if it doesn't exist. ### Best Practices - **Conventional Commits**: Use conventional commit messages to help the AI categorize changes more accurately. - **Use tags**: Ensure your project uses git tags so Grokkit can correctly identify the changes since the last version. - **Review before writing**: Always review the proposed changelog update before confirming.