FREESKILL v1.0UPDATED 2026-08

Changelog

A changelog is a factual release record, not a celebration template. It keeps released, partial, planned, and unknown work distinct before anybody tells users what changed.

Raw delivery notes mix internal completion, customer availability, future plans, and technical shorthand. Publishing that mixture creates false ship claims and support confusion.

This playbook turns those notes into a Changelog Entry Set or an Internal Release Email. It checks status, date, audience, availability, user consequence, limitations, support, and required action before the copy is ready.

The date a task finished internally is not automatically the date users received it.

SIGNALS YOU NEED THIS

Release notes say improved without evidence of the user consequence.

Planned work appears beside shipped work without a visible status boundary.

An internal announcement lacks availability, limitations, support, or next steps.

REPLACES

Ticket dumps, false ship language, and release emails built before the facts are stable.

PAIRS WITH

Working Backwards, Voice of the Customer, and Business Writing.

0 of 4 steps complete

STEP 01Inventory and classify the release facts

Split every note into change, status, date, audience, availability, user consequence, and evidence gap. Keep unconfirmed work in Planned or Unknown.

RELEASED, AUGUST 6
  Added an inactive-member filter for all accounts.
  Fixed an export that omitted the status column.

PLANNED
  Settings redesign, September timing supplied as a plan only.

STEP 02Group what changed for the user

Use New, Improved, Fixed, or Removed or changed behavior. Translate implementation detail only when it changes availability, behavior, migration, support, or risk.

NEW
  Filter member lists by inactive status.
  Availability: all accounts, August 6.

FIXED
  Status now appears in member exports.
  Availability: all accounts, August 6.

STEP 03Expose gaps and practical limits

Do not infer benefit, affected population, fix scope, required action, or support destination. Put publication blockers before the entries and give each action an owner and due date.

EVIDENCE GAPS
  Customer benefit statement: Evidence needed.
  Support link: Link needed.
  Owner: Owner needed.
  Due: Date needed.

STEP 04Run the publication or send check

Confirm release status, dates, audience, availability, limitations, support, and user action. Draft the internal email only from the same factual base, and never send it from this workflow.

PUBLICATION CHECK
  Status verified: yes
  Availability verified: yes
  Unsupported claims: none
  Help path: /help/member-status
  Ready to publish: human approval needed

Download the folder into your agent's skills directory. It uses only the material you provide and makes no remote calls.

skills/changelog

changelog/
├── SKILL.md                         ← entries and release-email modes
├── meta.yaml                        ← version, sources, test prompts, changelog
├── LICENSE.md                       ← MIT
├── assets/
│   ├── changelog-entry-template.md  ← released and planned entry set
│   └── release-email-template.md    ← internal announcement draft
└── references/
    ├── changelog-writing-rules.md   ← status and publication rules
    └── release-email-guidance.md    ← limitations, support, and recognition

INVOKE IT LIKE THIS

"Write the changelog entry from this work."

Download skill v1.0 View source files

WORKS WITHClaude Code