菜单
Use when the user wants to generate a changelog, release notes, or document what changed between versions, tags, or PRs
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | changelog |
| description | Use when the user wants to generate a changelog, release notes, or document what changed between versions, tags, or PRs |
Auto-generate human-friendly changelogs from git history. Follows Keep a Changelog format, polishes commit messages into user-friendly language, and optionally creates GitHub Releases.
The primary input is a git ref range. Resolve the argument (if provided):
... or .. -> git ref range (e.g. v1.0.0...v1.1.0)#\d+ pattern -> PR (extract changes from that PR only). For single PR input: read the PR diff and description, categorize changes, use the PR title as the entry. Skip the version header. Ask the user if they want to append these entries to an existing changelog version or create a new one.digraph changelog {
rankdir=TB;
"Resolve input" [shape=box];
"Phase 1: Gather" [shape=box];
"Phase 2: Categorize" [shape=box];
"Phase 3: Polish" [shape=box];
"Phase 4: Review" [shape=box];
"Approved?" [shape=diamond];
"Phase 5: Output" [shape=box];
"Resolve input" -> "Phase 1: Gather";
"Phase 1: Gather" -> "Phase 2: Categorize";
"Phase 2: Categorize" -> "Phase 3: Polish";
"Phase 3: Polish" -> "Phase 4: Review";
"Phase 4: Review" -> "Approved?";
"Approved?" -> "Phase 3: Polish" [label="revisions"];
"Approved?" -> "Phase 5: Output" [label="yes"];
}
Do NOT skip phases. Ask questions at a natural pace. If the user answers multiple at once, accept bundled answers and skip ahead.
If the user says "just pick defaults" or similar, pick reasonable defaults, state what you chose, and ask for a single confirmation.
Run git log between the two refs to collect all commits. If the repo uses PRs, also check for merged PRs in the range using gh pr list --state merged.
For each commit/PR, extract:
Read if they exist: README, package.json (or equivalent). Goal: understand what the product is to write user-friendly descriptions.
If nothing found, ask: "Can you briefly describe the product? I need context to write user-friendly changelog entries."
Check if the repo has an existing CHANGELOG.md. If it does:
If no existing changelog:
Sort all changes into Keep a Changelog categories. Breaking Changes get a dedicated section at the top:
feat!:, fix!:, BREAKING CHANGE: footers, or removed/renamed APIs in the diff.Categorization rules:
feat:, fix:, etc.), use the type to categorizePresent the categorized list:
"Here's what I found in this range:"
Added (3)
- Feature A
- Feature B
- Feature C
Fixed (2)
- Bug fix A
- Bug fix B
"Anything to add, remove, or recategorize?"
Do NOT proceed until the user confirms.
Rewrite each entry into human-friendly language:
(#123))Format: ## [version] - YYYY-MM-DD
If the upper bound of the range is a version tag (e.g. v1.2.0), use that as the version. If the upper bound is HEAD or a branch name, ask: "What version number should this changelog use?"
Use the date of the most recent commit in the range, in ISO format (YYYY-MM-DD).
After generating the user-friendly changelog, ask:
"Want me to also generate a technical appendix with implementation details? (useful for developer-facing docs)"
If yes, generate a more detailed section with technical specifics, breaking change migration guides, and API changes.
Present the complete changelog entry:
"Here's the changelog:"
## [1.2.0] - 2026-04-11 ### Added - You can now export reports to PDF (#123) ### Fixed - Dashboard no longer flickers on page load (#456)"Want any changes?"
Wait for approval. Only proceed to output once the user confirms.
Detect existing CHANGELOG.md in the repo root. If found, read the entire file, identify the insertion point (before the first ## [ line), present the proposed insertion point to the user, and confirm before writing. If not found, create one with a standard header:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/).
Always confirm before writing:
"I'll prepend this to
CHANGELOG.md. Good to go?"
After saving the changelog, ask:
"Want me to also create a GitHub Release with this changelog?"
If yes, use gh release create <tag> --notes "<changelog content>" to create the release. If gh is not available, inform the user and skip.
gh not available -> inform user, skip PR enrichment and GitHub Release, rely on git log only/blog-post or /newsletter)Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.
Use when the user wants to write, draft, or author an RFC (Request for Comments) / technical design doc for a feature, change, or architectural decision. Interactively interviews the user, grounds the proposal in the actual codebase, presents 2-3 concrete API/code-snippet approaches to choose from, then writes a review-ready RFC. Triggers on "write an RFC", "draft an RFC", "RFC for X", "design doc for X", or /rfc.
Use when the user wants to create presentation slides, a slide deck, a technical talk, or a conference talk for a topic or library — built on Slidev. Interviews the user, deep-researches and code-grounds the topic FIRST, applies presentation-craft best practices, generates a Slidev deck, self-verifies it in a headless browser, and ends with the dev server running and the deck open in the browser with zero manual steps. Triggers on "make a presentation", "make slides", "build a deck", "presentation about X", "technical talk", "conference talk", "slidev deck", "build slides for X", "present <library>".
Use when the user wants to generate a rendered promotional video (not just a script) for a PR, feature, or product change — produces a HyperFrames HTML composition, iterates with `npx hyperframes preview`, and outputs mp4 + poster for X/LinkedIn/social.
Use when the user wants to turn a raw talking-head / screen-share recording into a finished, edited, annotated video plus a full content package. Removes silences, flags mistakes for the user to cut, transcribes, adds transcript-synced overlays (code, on-screen code highlights, word highlights, lists, comparisons, diagrams, section labels, punch-in zooms), renders with original audio, then generates blog/socials/YouTube content. Triggers on "produce a video", "edit my video", "annotate my recording", "/produce-video".
Use when the user wants to transcribe a video or audio file to text with word-level timestamps — spins up a self-contained local Whisper (whisper.cpp) Docker service bundled in this skill and returns transcript.txt, transcript.srt, and word-level transcript.words.json. Also used as a building block by /produce-video. Triggers on "transcribe this video", "get a transcript", "transcribe-video".