Skip to content
FunCoding

Search

Search docs, Skills and MCP

pmstudio-changelog

Create or update a structured change log for a product or platform. Use when someone asks to "create a change log", "log this change", "what changed", "update the change log", "release notes", or "changelog". Reads project memory (CLAUDE.local.md Recent Changes) and meeting notes to build chronological change records. Supports init (backfill from memory), update (append new entries), and release (summarize for a version).

Git 与发布511skills/change-log/SKILL.md

Install

Send this to Claude Code, Codex or Cursor. The agent checks the Skill for safety first and installs it only after you confirm.

读取 https://funcoding.ai/skills/coco-research/coco/change-log/install.md ,按里面的步骤帮我安装这个 Skill。

SKILL.md

Change Log — Running Product Change Record

Purpose

Maintains a chronological, append-only record of all meaningful changes to a product. Unlike CLAUDE.local.md (which is AI context), the change log is a stakeholder-facing document suitable for sharing with leadership, auditors, and team members.

Process

Step 1: Determine Mode

  • /change-log init — Create new change log, backfill from CLAUDE.local.md
  • /change-log update — Find changes since last entry, propose new entries
  • /change-log release {version} — Create release summary from accumulated entries
  • /change-log (no args) — Same as update

Step 2: Read Context

Always read:

  • CLAUDE.local.md — Recent Changes section (primary source of truth for what changed)
  • Existing change log file (if update or release mode)

For init mode, also read:

  • Meeting-Notes/ directory listing — to identify decision-bearing meetings
  • PRD/ — version history sections
  • .sync-watch.json — project name

For update mode:

  • Find the date of the last change log entry
  • Read any Meeting-Notes/ files dated after that
  • Read CLAUDE.local.md Recent Changes entries dated after that

Step 3: Extract Changes

For each source, extract structured change data:

- Date: YYYY-MM-DD
- Summary: one-line description
- Type: Feature | Enhancement | Bug Fix | Configuration | Process | Security | Documentation
- Impact: High | Medium | Low
- Components: which modules/layers/documents were affected
- Author: who made or requested the change
- Approved By: who approved (if known from meeting notes)
- Details: bullet list of specific changes
- Rationale: why the change was made
- Downstream: what else was updated as a result

Impact classification:

  • High — Changes product behavior, affects users, or modifies architecture
  • Medium — Updates documentation, adds stakeholders, changes processes
  • Low — Minor fixes, formatting, internal-only changes

Step 4: Propose Entries (update/init)

Present proposed entries to user before writing:

## Proposed Change Log Entries

### [2026-03-17] PRD v0.9 — User Journey Sections
**Type:** Enhancement | **Impact:** High
**Components:** ProductB PRD, ProductB PRD Presentation
- Added Current User Journey (6-step timeline)
- Added Future User Journey (3-layer cascading)
- Renumbered all sections (19 total)

Accept? [Y/n] or modify?

Step 5: Write

File location: Data/Change-Log-{ProjectName}.md

File structure:

# Change Log — {Product Name}

> Running record of all changes. Newest entries first.
> Generated and maintained via `/change-log` skill.

Last updated: {date}
Total entries: {count}

---

## [YYYY-MM-DD] v{X.Y} — {Summary}

**Type:** {type} | **Impact:** {impact}
**Components:** {affected components}
**Author:** {name} | **Approved By:** {name or "—"}

### Changes
- {specific change 1}
- {specific change 2}

### Rationale
- {why this change was made}

### Downstream Effects
- {what else was updated}

---

## [YYYY-MM-DD] ...

For release mode:

Collect all entries since the last release entry (or all entries if first release). Produce a summary:

## Release: v{version} — {date}

### Summary
{2-3 sentence overview of what this release includes}

### Changes Included
| Date | Type | Summary | Impact |
|------|------|---------|--------|
| ... | ... | ... | ... |

### Highlights
- {Most important change}
- {Second most important}

### Known Issues
- {Any caveats}

Critical Rules

  1. Append-only. Never modify existing entries. Only add new ones at the top.
  2. Propose before writing. Always show the user what entries will be added.
  3. Don't duplicate. Check existing entries before proposing. If a change is already logged, skip it.
  4. Real content only. Don't log trivial changes (typo fixes, formatting) unless the user specifically asks.
  5. Dates from sources. Use the date from CLAUDE.local.md or meeting notes, not today's date, for the change date. Today's date is for entries about changes made today.

Similar Skills

ponytail-review
DietrichGebert/ponytail160k

ponytail-review

Quality review of a change: is the logic right, is it safe, does it hold under real load, is risky code tested, is it fast enough, and is every line needed. Reads the connected code, not only the diff. Each finding is explained in plain English. Use for "review this", "code review", "review the last commit", "review my PR", "is this over-engineered", /ponytail-review.

Git & releases

git-workflow-and-versioning
addyosmani/agent-skills104k

git-workflow-and-versioning

Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.

Git & releases

ci-cd-and-automation
addyosmani/agent-skills104k

ci-cd-and-automation

Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.

Git & releases

github-dashboard
nexu-io/open-design100k

github-dashboard

GitHub repository analytics dashboard — stars, forks, contributors, issues, pull requests, recent activity, and top contributors. Use when the brief asks for a GitHub repo dashboard, open-source growth report, repository health page, or GitHub analytics view.

Git & releases

babysit
thedotmack/claude-mem99k

babysit

Watch a pull request or review cycle until it is ready to merge. Use when asked to babysit, monitor, or keep checking PR comments, reviews, and CI until all actionable issues are resolved.

Git & releases

oh-my-issues
thedotmack/claude-mem99k

oh-my-issues

Cluster a GitHub issue backlog by root cause into a small set of plan-master issues, redirect children with a standardized comment, and bundle architectural-fix PRs that close clusters atomically. Use when an issue tracker has accumulated dozens of reports that share underlying defects, when asked to triage / consolidate / cluster / dedupe issues, when asked to build a plan series or roadmap from open issues, or when routing a new incoming bug into an existing plan.

Git & releases