ワンクリックで
changelog
Use when the user asks for a changelog, release notes, or summary of recent changes
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when the user asks for a changelog, release notes, or summary of recent changes
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the user wants to do a QA session or report multiple bugs — interactive session where bugs are reported conversationally and agents fix them in parallel
Use when executing implementation plans with independent tasks — orchestration pattern for worktree isolation, TDD discipline, and two-stage review. Referenced by execute-plan, fixit, and bugbash.
Use when the user reports a bug or issue that can be fixed without blocking their current work — backgrounds an agent in a worktree to fix and merge back without breaking stride
Use after implementing changes in an OpenSpec project to review implementation against the active change's deltas — auto-fixes confident issues, parks questions for the user
Install the anutron (claude-skills) kit into the current project — symlinks or copies skills, registers hooks, compiles CLAUDE.md from snippets.
Uninstall the anutron (claude-skills) kit from the current project — reverses everything /anutron-install did.
| name | changelog |
| allowed-tools | Bash(git log:*), Bash(git diff:*), Bash(git show:*), Bash(git tag:*) |
| description | Use when the user asks for a changelog, release notes, or summary of recent changes |
| tags | ["personal"] |
git branch --show-current 2>/dev/null || echo '(not in a git repo)'git describe --tags --abbrev=0 2>/dev/null | head -1git log --oneline --since="7 days ago" 2>/dev/null | head -20$ARGUMENTS - Optional: time period to look back (e.g., "2 weeks", "since v1.2.0", "last 30 days", "2025-01-01..2025-02-01")Generate a well-organized, human-readable changelog from recent git history.
If the user provided a time period in $ARGUMENTS, use it. Otherwise, ask the user what time period they want the changelog to cover. Suggest useful options based on the context above:
Run git log for the chosen time range with full commit messages:
git log --format="%H%n%s%n%b%n---END---" <range>
If there are merge commits, also look at what was merged:
git log --merges --format="%H %s" <range>
If there are very few commits, also inspect the diffs to understand what changed:
git diff --stat <range>
Read through all commit messages and diffs. Group changes into categories. Use only categories that have entries — skip empty ones. Choose from:
Write a changelog that is:
Format each entry as a bullet point. Include relevant context like file paths or component names only when it helps the reader understand the scope.
Print the changelog in this format:
## Changelog: <description of range>
### Added
- Entry here
### Changed
- Entry here
### Fixed
- Entry here
After presenting, offer to:
pbcopy)