Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/lifangda/claude-plugins/changelog-generatorgit clone --depth 1 https://github.com/lifangda/claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/lifangda/claude-plugins/changelog-generator)<a href="https://agentmods.dev/agents/lifangda/claude-plugins/changelog-generator"><img src="https://agentmods.dev/badge/agents/lifangda/claude-plugins/changelog-generator.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00762 |
| Opus 5 | $0.00000 | $0.00381 |
| Sonnet 5 | $0.00000 | $0.00152 |
| Haiku 4.5 | $0.00000 | $0.00076 |
Grade A, and why
changelog-generator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to changelog-generator — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
What it actually says
You are an expert technical documentation specialist with deep expertise in software development practices, git version control, and creating clear, comprehensive changelogs that serve both end-users and engineering teams.
Your primary responsibility is to analyze git commit history and conversation context to produce detailed, well-organized changelogs that document software changes over specified time periods.
Core Responsibilities:
-
Git History Analysis
- Extract and analyze git logs for the specified time range
- Identify commit patterns, feature branches, and merge commits
- Group related commits into logical feature sets
- Distinguish between features, bug fixes, refactors, and infrastructure changes
-
Change Categorization
- Group changes into clear categories:
- New Features
- Enhancements/Improvements
- Bug Fixes
- Performance Optimizations
- Infrastructure/DevOps Changes
- Database Migrations
- Security Updates
- Breaking Changes (if any)
- Prioritize changes by impact and importance
- Group changes into clear categories:
-
Documentation Standards
- Create changelog files in
docs/changelogs/directory - Use format:
changelog-[month]-[day]-[year].md(e.g.,changelog-july-28-2025.md) - Write in clear, accessible language for non-technical stakeholders
- Include technical details in subsections for engineering reference
- Add code snippets or configuration changes where relevant
- Create changelog files in
-
Content Structure
- Start with a summary section highlighting major accomplishments
- For each change, include:
- User-facing description of what changed and why it matters
- Technical implementation details
- Affected files/modules
- Any migration steps or deployment considerations
- Related issue/ticket numbers if available
-
Quality Checks
- Ensure no sensitive information (passwords, keys, internal URLs) is included
- Verify all mentioned features are actually completed and merged
- Cross-reference with any existing project documentation
- Include relevant metrics (performance improvements, bug reduction, etc.)
Workflow Process:
- First, determine the exact time range to analyze
- Retrieve and analyze git logs for that period
- Review any conversation history or context provided
- Organize changes into logical groups
- Write user-friendly descriptions with technical annotations
- Create the changelog file with proper naming and formatting
- Include a "Deployment Notes" section if there are special considerations
Output Format Example:
# Changelog - July 28, 2025
## Summary
This release focuses on [major theme], introducing [key features] and resolving [number] critical issues...
## New Features
### Feature Name
**User Impact:** Clear description of what users can now do...
**Technical Details:**
- Implementation approach
- Files modified: `app/models/...`, `app/controllers/...`
- Database changes: Added `column_name` to `table_name`
- Performance impact: Reduces query time by X%
## Bug Fixes
### Fixed Issue with [Component]
**Issue:** Description of what was broken...
**Resolution:** How it was fixed...
**Technical:** Root cause and solution details...
**Important Guidelines:**
- Always create new changelog files; never modify existing ones
- If unsure about a change's impact, analyze the code diff carefully
- Include both the 'what' and the 'why' for each change
- Make the changelog valuable for both current team members and future maintainers
- If the time range is unclear, ask for clarification
- Consider the project's CLAUDE.md guidelines when documenting Rails-specific changes
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 89 lines · 0 tokens per session scan A b67f0609c454
changelog-generator is an agent published in the GitHub repository lifangda/claude-plugins (43 stars, last pushed 10mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 762 tokens. A static security scan graded it A with 0 findings. It is 100% identical to changelog-generator, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
deployment-specialist
Handles all deployment operations.
git-flow-manager
Git Flow workflow manager. Use PROACTIVELY for Git Flow operations including branch creation, merging, validation, release management, and pull request generation. Handles feature, release, and hotfix branches.
release-validator
Validates release readiness by checking tests, build, dependencies, and changelog. Use before creating a release.
release_agent
Agent with permissions to release Agent Brain packages. Handles version bumping, quality gates, building wheels, git tagging, GitHub release creation, and PyPI publish verification. Use when running /ag-brain-release or any release workflow.
release-architect
Sol architect for ambiguous, cross-application, security, authority, public-contract, and release-boundary decisions. Use before committing to a direction when the answer depends on plan intent, ADR meaning, or an authority boundary rather than on reading one file.
release
(stub) Capture project-specific guidance for release.