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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Ultra-short replies — answer a quick question, draft a short text/social post, or draft a short email. No preamble, no offers to elaborate, drafts under 480 characters (280 for X), never em-dashes.
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.
| 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" |