How do I install the Change Log skill?

Run npx skillmds@latest add giostriquer/change-log in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Change Log safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Change Log?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Change Log free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Change Log?

giostriquer (@giostriquer) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Change Log by giostriquer — Agent Skill

Name: Change Log
Author: giostriquer

Change Log

Use when a change ships in a plugin version bump (workbench, toolkit) and needs its release-notes entry in docs/change-log.md. Not for repo-only work (structure, docs, and decisions, which live in docs/decisions/ and git history), formatting edits, or scratch work.

giostriquer 79b847c 2.2 KB Updated Sep 17, 2026

File contents

Change Log: the plugins' release notes

docs/change-log.md is a release-notes file for the shipped plugins: one section per released version, newest first, bounded length. It is not a repository history: docs/decisions/ and the git log own that.

Rules

Plugin releases only. A section exists because a plugin version shipped (## workbench x.y.z: YYYY-MM-DD, ## toolkit x.y.z: …). Repo-only work gets no section, ever. If asked to log repo-only work, say the release notes don't record it and point to docs/decisions/.
Release-notes style. Inside a section: one bullet per change, opening with a bold lead phrase, 1–4 tight sentences. Link the decision note for rationale, never restate it. No TODOs, no next-steps, no authoring narrative.
One section per version. Several changes shipping under one bump are bullets in the same section. If the section already covers the change, amend the bullet instead of adding a duplicate.
Retention cap: 15 sections. After adding a section, count the ## sections; delete the oldest beyond 15. Git history preserves everything, so the file must not grow indefinitely.
Ground every bullet in the actual diff at landing time.

Workflow

Identify the version shipping the change (the bumped version in the plugin manifests). No bump → no entry.
Read docs/change-log.md.
Add the version section at the top (or amend it if this version's section already exists), one bullet per change.
Enforce the retention cap.

When invoked by another agent

Trust the caller's pre-read diff context; still read the file before editing. Return a short confirmation: the section touched, the bullet added or amended, or that no entry was needed (no version shipped).

Scope

Operates on this repo's docs/change-log.md only.
Does not commit or push unless explicitly asked.

---name: change-logdescription: Use when a change ships in a plugin version bump (workbench, toolkit) and needs its release-notes entry in docs/change-log.md. Not for repo-only work (structure, docs, and decisions, which live in docs/decisions/ and git history), formatting edits, or scratch work.---# Change Log: the plugins' release notes`docs/change-log.md` is a **release-notes file** for the shipped plugins:one section per released version, newest first, bounded length. It is not arepository history: `docs/decisions/` and the git log own that.## Rules- **Plugin releases only.** A section exists because a plugin version shipped (`## workbench x.y.z: YYYY-MM-DD`, `## toolkit x.y.z: …`). Repo-only work gets no section, ever. If asked to log repo-only work, say the release notes don't record it and point to `docs/decisions/`.- **Release-notes style.** Inside a section: one bullet per change, opening with a **bold lead phrase**, 1–4 tight sentences. Link the decision note for rationale, never restate it. No TODOs, no next-steps, no authoring narrative.- **One section per version.** Several changes shipping under one bump are bullets in the same section. If the section already covers the change, amend the bullet instead of adding a duplicate.- **Retention cap: 15 sections.** After adding a section, count the `## ` sections; delete the oldest beyond 15. Git history preserves everything, so the file must not grow indefinitely.- Ground every bullet in the actual diff at landing time.## Workflow1. Identify the version shipping the change (the bumped version in the plugin manifests). No bump → no entry.2. Read `docs/change-log.md`.3. Add the version section at the top (or amend it if this version's section already exists), one bullet per change.4. Enforce the retention cap.## When invoked by another agentTrust the caller's pre-read diff context; still read the file beforeediting. Return a short confirmation: the section touched, the bulletadded or amended, or that no entry was needed (no version shipped).## Scope- Operates on this repo's `docs/change-log.md` only.- Does not commit or push unless explicitly asked.

Frequently asked questions