Changelog From Commits

# Changelog from Commits / 提交转更新日志

## When to use

- The user is cutting a release and needs **user-facing** release notes.
- There is a clear range: a tag, a date, or a commit SHA to diff from.
- The audience is **users**, not contributors (Conventional Commits already exists for the latter).

## When NOT to use

- The repo has **no user-facing surface** (internal libraries, scripts) — a commit log is fine.
- The range covers **months of work**. Break it into smaller releases first.
- The user wants a **marketing post** — that's [launch-tweet](../launch-tweet/SKILL.md), not a changelog.

## Approach

1. Get the raw commit list:
   ```bash
   git log <prev-tag>..HEAD --pretty=format:"%h %s%n%b" --no-merges
   ```
2. **Group** commits into three buckets, in this order:
   - **Added** — net-new user-visible capability.
   - **Changed / Fixed** — behavior that users would notice.
   - **Internal** — refactors, deps, docs (collapse into a single line at the bottom).
3. **Translate from dev-speak to user-speak.**
   - ❌ "refactor: extract validation middleware"
   - ✅ (skip — internal)
   - ❌ "fix: handle null in payment.processor"
   - ✅ "Fixed a crash when applying coupons to gift cards."
4. **Drop noise.** Typo fixes, README tweaks, CI tweaks, version bumps → cut.
5. Each bullet is **one sentence**, past tense, user perspective.
6. If a bullet needs more than one sentence, it deserves its own blog post — link out.

## Output format

```markdown
## v<version> — YYYY-MM-DD

### Added
- <bullet>

### Changed
- <bullet>

### Fixed
- <bullet>

### Internal
- <one-line summary>: deps bumped, tests added, docs polished.
```