Group
  • Deployment

    Set up a changelog and release process

    Creates a lightweight changelog habit tied to deploys so 'what changed and when' is always answerable.

    • Automate workflows
    • Improve quality
    • Beginner
    • General

Free Prompt

Set up a lightweight changelog and release process for my app so I always know what shipped, when, and why. 1. Format: create a CHANGELOG.md at the repo root using the Keep a Changelog format: sections per release with Added, Changed, Fixed categories. Backfill just the current version as the starting point; do not archaeology the entire git history. 2. Versioning: decide my version scheme (semver with git tags is the default; date-based versions like 2026.08.1 are fine for apps) and tag the current state as the first version. 3. Habit hook: make the changelog hard to forget. Pick what fits my flow: a PR template with a 'changelog entry' line, a CI check that warns if CHANGELOG.md was not touched in a feature PR, or a pre-release script that drafts entries from commit messages for me to clean up. 4. Deploy linkage: connect versions to deploys: tag the release in git when it ships to production, and if I have deploy notifications, include the version or tag in them. 5. User-facing layer (optional): if my users would benefit, add a simple 'What's new' page or in-app section fed from the same changelog, so support questions about 'did something change?' have a public answer. 6. Discipline for incidents: add the rule that every production fix gets a Fixed entry, because the changelog doubles as incident history when debugging 'when did this break?'. Do not build release automation machinery beyond what I will actually use; a solo developer needs a template and a tag habit, not a release pipeline. Do not auto-publish raw commit messages as the user-facing changelog. Give me: the CHANGELOG.md with format and first entry, the versioning decision, the habit hook you installed, and the tag-and-deploy linkage.

What This Does / How This Helps

Sets up a changelog habit tied to your deploys, so 'what changed and when' is a document instead of an archaeology project. Three months after launch something breaks and the question is always the same: when did this last work, and what shipped since? Without a changelog the answer is scrolling git log and guessing. With one, it is a thirty-second lookup. It also quietly becomes your incident history and your 'what's new' page. The prompt keeps it deliberately light: a standard format, a version tag on each production deploy, a hook that makes forgetting hard, and the rule that fixes get logged, because those entries are the ones future you will search for.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts