changelog-md-workmanship

name	changelog-md-workmanship
description	Rebuild CHANGELOG.md files and release histories from git, tags, releases, and issue trackers. Use when writing changelogs, version timelines, or agent-facing project history summaries.

Changelog.md Workmanship

Core Insight: A real changelog is a research artifact. If the history work is weak, the prose is fake.

The Problem

Most changelogs fail in one of two ways:

• they are fake summaries written from vague memory
• they are unusable diff dumps that preserve chronology but destroy comprehension

The job is to build an orientation layer that lets another agent answer:

• what materially changed?
• when did it change?
• why did it change?
• which commits and workstreams should I inspect first?

The One Rule

Never draft a serious changelog from memory. Research exhaustively, then write incrementally while the evidence is still in hand.

For large repos, do not wait until the end to write CHANGELOG.md. After each research chunk, update:

• the changelog itself
• a compaction-resistant research memo

That is how you survive long histories without losing findings to context pressure.

---

THE EXACT PROMPT

Create or rebuild a serious CHANGELOG.md for this project.

Requirements:
1. Research the real history first: git commits, tags, releases, issue tracker, and existing docs.
2. Cover the requested scope window completely, from the beginning if needed.
3. Distinguish actual GitHub Releases from plain git tags.
4. Use live links for representative commits and version pages.
5. Include issue-tracker workstreams when available.
6. Organize by landed capabilities, not raw diff order, but keep a clear version timeline.
7. For large histories, split research into chunks and update CHANGELOG.md incrementally after each chunk.
8. Make it agent-friendly: another agent should be able to understand what changed without reading every diff.

Output:
- A canonical CHANGELOG.md
- A short note describing the evidence sources used