drn/changelog
agents/skills/changelog/SKILL.md
Generate an intelligent changelog from recent commits. Use for release notes, version history, or documenting what changed.
$ install --global
skillsauthnpx skillsauth add drn/dots changelogInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 21, 2026, 10:41 AM52.4s1 file scanned
SKILL.md
- name:
- changelog
- allowed-tools:
- Bash(git log:*), Bash(git diff:*), Bash(git show:*), Bash(git tag:*)
- description:
- Generate an intelligent changelog from recent commits. Use for release notes, version history, or documenting what changed.
Context
- Current branch: !
git branch --show-current - Latest tag: !
git describe --tags --abbrev=0 2>/dev/null | head -1 - Recent commits (last 7 days): !
git log --oneline --since="7 days ago" 2>/dev/null | head -20
Arguments
$ARGUMENTS- Optional: time period to look back (e.g., "2 weeks", "since v1.2.0", "last 30 days", "2025-01-01..2025-02-01")
Your task
Generate a well-organized, human-readable changelog from recent git history.
Step 1: Determine the time range
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:
- Since a specific tag (if tags exist)
- Last N days/weeks
- A date range
- Since a specific commit
Step 2: Gather commits
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>
Step 3: Analyze and categorize
Read through all commit messages and diffs. Group changes into categories. Use only categories that have entries — skip empty ones. Choose from:
- Added — new features, commands, tools, or capabilities
- Changed — modifications to existing behavior, UI updates, refactors
- Fixed — bug fixes
- Removed — deleted features, deprecated code removal
- Infrastructure — CI/CD, build system, dependency updates, tooling
- Documentation — README, docs, comments
Step 4: Write the changelog
Write a changelog that is:
- Grouped by category with clear headers
- Concise but meaningful — each entry should explain what and why, not just parrot the commit message
- Deduplicated — combine related commits into a single entry (e.g., a feature + its follow-up fix = one entry)
- Ordered by significance within each category
- Free of noise — omit trivial changes like typo fixes or formatting unless nothing else happened
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.
Step 5: Present the changelog
Print the changelog in this format:
## Changelog: <description of range>
### Added
- Entry here
### Changed
- Entry here
### Fixed
- Entry here
After presenting, offer to:
- Copy to clipboard (
pbcopy) - Save to a file
Related Skills
drn/address-comments
development
VerifiedTrustedCommunity
Walk every unresolved review thread on a PR, triage each one, reply with a rationale of whether or not the comment will be acted upon, make the code change if warranted, and mark the thread resolved. Use when the user asks to address only the open PR comments without re-running CI, respond to review feedback, resolve review threads, or clear bot comments on a PR.
23SKILL.mdUpdated May 16, 2026
drn/rereview-loop
tools
VerifiedTrustedCommunity
Iteratively run /rereview, fix the findings, and loop until reviewers approve clean. Use for iterative automated review, when you want /rereview to loop until clean, or for a paranoid pre-merge review that auto-addresses every blocker.
23SKILL.mdUpdated May 13, 2026
drn/plannotator-visual-explainer
development
VerifiedTrustedCommunity
Generate self-contained HTML visualizations with Plannotator theming. Use for implementation plans, PR explainers, architecture diagrams, data tables, slide decks, and any visual explanation of technical concepts. Plans and PR explainers follow Plannotator's prescriptive approach; all other visual content delegates to nicobailon/visual-explainer.
23SKILL.mdUpdated May 13, 2026
drn/plannotator-setup-goal
development
VerifiedTrustedCommunity
Create reviewed Codex goal setup packages for long-running /goal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final /goal prompt.
23SKILL.mdUpdated May 13, 2026