change-log
Use after completing a feature or bug fix to log the change in CHANGELOG.md using plain, business-user-friendly language
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use after completing a feature or bug fix to log the change in CHANGELOG.md using plain, business-user-friendly language
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use after implementing a change or opening a PR — proves the change works end-to-end by running the app, driving it in the browser, and recording an MP4 video as proof. The reviewer watches the recording and merges without pulling the branch.
Use when starting any feature (small or large), resuming work after context loss, or unsure if a feature plan already exists. For smaller features, use lightweight mode (no plan file, but all PDD rules still apply).
Use for any code change — bug fix, small feature, refactor, or improvement. Ensures TDD, clarifying questions, codebase investigation, DRY, proper branching/worktrees, UI skills, and doc updates. PDD invokes this automatically for large features.
Use when fixing a bug — enforces reproduce-first-then-fix discipline with a strict step-by-step protocol. Prevents wrong-approach loops by gating each step on success criteria.
Reconcile shipped code with the plan in both directions — additive drift (unplanned work that landed) and subtractive drift (dead files, stale TODOs, completed deferred items). Run as part of PDD's post-completion audit, before /simplify.
Generate 5 meaningfully distinct UI/UX variants of the same screen in parallel (one subagent each), reachable via ?style=1...5, so the user can compare and pick. Calling again on a chosen style refines within that direction.
SOC 職業分類に基づく
| name | change-log |
| description | Use after completing a feature or bug fix to log the change in CHANGELOG.md using plain, business-user-friendly language |
After every feature or bug fix is complete, add an entry to CHANGELOG.md. The log is written for business users, not developers — it powers the product updates blog. Use plain language that a non-technical person would understand.
plan-driven-development and bug-fix automatically)# Change Log
## 2026-03-20
- You can now see exactly which articles were added, updated, or deleted after each sync
## 2026-03-18
- Fixed an issue where disconnecting a connector would sometimes leave behind stale data
Creating a duplicate CHANGELOG.md is the most common failure mode of this skill. You must exhaustively search for an existing one before creating a new file. Run all of these steps in order and only fall through to the next if the previous turned up nothing:
Check CLAUDE.md for an explicit path. Grep the repo's CLAUDE.md files for CHANGELOG — project owners often pin the canonical path there (e.g., "the canonical changelog is at CHANGELOG.md at the repo root"). If CLAUDE.md names a path, use that path and skip the rest.
grep -nH -i "changelog" CLAUDE.md ./**/CLAUDE.md 2>/dev/null
Find the repo root, then look for CHANGELOG.md at the root. Do not assume your current working directory is the root — skills are often invoked from a subdirectory (e.g., chat-ui/, frontend/, apps/web/).
ROOT="$(git rev-parse --show-toplevel)"
ls "$ROOT"/CHANGELOG.md 2>/dev/null
Glob the entire repo for any CHANGELOG.md (case variants included), excluding vendored dirs. If matches exist, the canonical one is almost always at the repo root — pick that one. If multiple non-vendored copies exist, stop and ask the user which is canonical; do not silently pick one or create a third.
find "$ROOT" -iname "CHANGELOG*.md" \
-not -path "*/node_modules/*" \
-not -path "*/.next/*" \
-not -path "*/.venv/*" \
-not -path "*/venv/*" \
-not -path "*/dist/*" \
-not -path "*/build/*" \
-not -path "*/.claude/*"
Only if all of the above return nothing may you create CHANGELOG.md at the repo root ($ROOT/CHANGELOG.md) with the # Change Log heading and today's entry. Never create it in a subdirectory like chat-ui/CHANGELOG.md or frontend/CHANGELOG.md — the root is the canonical location.
Do not create a new CHANGELOG.md just because the existing one isn't where you expected, or because your cwd is a subdirectory and you didn't find one there. A "missing" changelog almost always means you searched the wrong directory.
simple-design-principles language. No jargon, no technical terms. Write what the user can now do or what got better, not what code changed.YYYY-MM-DD. Use today's date.CHANGELOG.md at the repo root. See "Finding the existing CHANGELOG" above — always search first, never create a duplicate.# Change Log heading.| Don't | Do |
|---|---|
"Added sync_run_changes table and API endpoint" | "You can now see which articles changed after each sync" |
| "Fixed null pointer in webhook handler" | "Fixed an issue where syncs would sometimes fail silently" |
| "Refactored connector registry to use ABC pattern" | (Don't log — internal refactor, not user-facing) |
| "Implemented incremental reindexing with changed_records" | "Syncs are now faster — only changed articles are re-processed" |