/changelog

description: Render release notes / a changelog from the cladding spec. Use when the user asks for release notes, a changelog, 릴리즈 노트, 변경 이력, or "what changed (since <ref>)" — run `clad changelog --json` for the deterministic shipped-changes manifest, then write the human-facing notes FROM it, sourcing every claim from a feature title or acceptance sentence. For audit asks, print the --audit table verbatim. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized projects.

Cladding changelog — release notes from the spec

The spec is the SSoT, so "what shipped?" is *collected*, never recalled. `clad changelog` turns `<since>..HEAD` into a deterministic manifest: feature shards classified (`added-as-done` / `flipped-to-done` / `modified-while-done` / `archived`), grouped by capability (plus an `uncategorized` bucket — itself a drift signal), the spec inventory diff, and conventional `feat:`/`fix:` commits that name no feature id (work that shipped *outside* the spec — report it honestly, don't hide it).

Protocol

1. **Collect.** Run `clad changelog --json --since <ref>` (omit `--since` to use the latest tag; if the repo has no tags the command says so — ask the user for a ref). 2. **Render EN + KO release notes from the manifest, in the CHANGELOG.md house style:**

• Open with a `**In one line:**` abstract (what a user gains, one breath).
• Group by the manifest's capability groups; use **user-impact verbs** ("the gate now runs

your entry point"), not implementation verbs ("refactored stage runner").

• **No `F-…`/`AC-…` ids in prose** (Soft Shell policy) — ids belong to the audit surface only.
• **Source every claim from the manifest** — a feature `title` or an `acceptance[]` sentence.

Never invent a change, never embellish beyond what an AC states. If the manifest is empty, say "no shipped changes since <ref>" — that line is the honest deliverable.

• Put `unsharded_commits` under an "Also changed" section, marked as not yet spec-tracked.

3. **Audit asks** ("show verification", "어디까지 검증됐어?") → print `clad changelog --audit --since <ref>` **verbatim** — that table keeps ids and marks every verification ref resolved ✓ / unresolved ✗ (a ✗ is spec-annotation drift worth reporting). 4. **Catalog asks** ("what does this project do, in full?") → `clad changelog --catalog` prints the whole capability → feature → acceptance listing of the living spec.

clad changelog                       # markdown since the latest tag (deterministic fallback)
clad changelog --json --since v0.5.2 # the manifest you render notes from
clad changelog --audit --since v0.5.2
clad changelog --catalog