メニュー
Propose CHANGELOG.md updates by analysing git tags and diffs. Uses Keep a Changelog format. Detects undocumented releases, reads actual code changes (not just commit messages), and outputs a proposed entry for review. Works with any language.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Teach a personal editor agent the user's own editing taste by reading the diff between an AI-drafted document and the user's hand-edit of it, encoding the lessons as procedures in the agent, and verifying with controlled re-runs. Use whenever the user has edited an AI-written document (README, docs, blog post) and wants their editor agent to learn from it, wants to build a personal editor agent from scratch, or says things like "teach my editor", "learn my house style", "train the humaniser on my edits", "make the editor agent edit more like me", or asks to compare what their editor agent would do against their own edit of the same document.
Generate a GitHub-style README.md for the current project by reading the actual codebase. Use when the user asks to "generate a readme", "write a readme", "document this project", "create a readme", or invokes /readme. Also callable from the github-create skill.
User's conventions and patterns for native macOS Swift apps. Use when working on a Swift or macOS app project
Streamlined workflow for implementing features with ait issue tracking. Handles: reading project context, checking outstanding work, planning new features, creating ait issues, and implementing with proper acceptance criteria checking. Use when starting a new session or beginning work on a feature.
One-stop review after feature work, or for a whole codebase. Runs deterministic checks (section ordering, arch conventions) free of charge, then fresh-eyes reviewer agents. Covers team conventions, test quality, complexity, security, and Livewire/Flux patterns - plus runtime checks (a11y, cold UX probe) when UI changed. Also has a quick mid-session sanity-check mode ("this seem ok?").
Turn a settled feature discussion or plan document into consultant-ready ait issues — an initiative/epic vision document plus implementation specs a fresh agent could pick up cold, tomorrow. Use towards the end of a feature conversation ("let's get this into ait"), or when converting a plan file. Also the knowledge base for the plan-to-ait agent. For driving the ait CLI itself, see the ait skill.
| name | changelog |
| description | Propose CHANGELOG.md updates by analysing git tags and diffs. Uses Keep a Changelog format. Detects undocumented releases, reads actual code changes (not just commit messages), and outputs a proposed entry for review. Works with any language. |
| allowed-tools | Read,Glob,Grep,Bash(git tag:*),Bash(git log:*),Bash(git diff:*),Bash(git show:*) |
| version | 0.1.0 |
| author | ohnotnow <https://github.com/ohnotnow> |
| license | MIT |
Generate and maintain a CHANGELOG.md following the Keep a Changelog format.
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## [1.2.0] - 2026-03-15
### Added
- New feature description
### Changed
- Modified behaviour description
### Fixed
- Bug fix description
[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/user/repo/compare/v1.1.0...v1.2.0
git tag --sort=creatordate
If there are multiple undocumented tags, tell the user:
"There are N undocumented releases since [last version]: [list]. Would you like me to do all of them, just the latest, or specific ones?"
Wait for the user's choice before proceeding.
For each tag range (<previous-tag>..<target-tag>):
Get the commit log (as hints — do NOT rely solely on these):
git log --oneline <prev>..<tag>
Get the diff stat to understand scope:
git diff --stat <prev>..<tag>
Read the actual diffs for key files. Focus on source code, not generated files or vendored dependencies. Use --stat output to identify which files changed significantly, then read those diffs:
git diff <prev>..<tag> -- '*.go' '*.py' '*.php' '*.js' '*.ts' '*.rs'
For large diffs, focus on the files with the most changes first. Skip test files for categorisation purposes (though a major test addition might indicate a new feature).
Categorise changes into Added / Changed / Fixed / Removed / Deprecated / Security. Use your judgement:
When commit messages are unhelpful (e.g. "WIP", "fix", "stuff"), lean entirely on the diff content. Describe what changed for the user, not implementation details.
Output the proposed changelog entry as a fenced code block. Do NOT write it to the file — the user will review first.
If this is a bootstrap (no CHANGELOG.md exists):
## [0.0.9] - 2026-02-20
If this is an incremental update (CHANGELOG.md already exists):
## [Unreleased]After proposing documented releases, check if there are commits after the latest tag:
git log --oneline <latest-tag>..HEAD
If there are, mention it: "There are also N commits since [latest tag] that haven't been tagged yet. Want me to add an [Unreleased] section?"
--tree flag for hierarchical list display" not "Implemented renderTree function in format.go".git tag -l --format='%(creatordate:short)' <tag>git remote get-url origin or the README.