| name | generate-changelog |
| description | Generate concise, user-facing changelog entries for Microlink by inspecting git commits across relevant repositories. |
Generate Changelog
Generate concise, user-facing changelog entries for src/content/fragments/changelog.md by inspecting git commits across all Microlink repositories since the last changelog edit.
When to use
Run this skill when you need to update the changelog with recent changes. It scans all relevant repos and produces entries grouped by month. The changelog is read newest to oldest — both across months and within each month section.
Steps
1. Determine the cutoff date
Find the last time the changelog file was modified:
git log -1 --format="%ai" -- src/content/fragments/changelog.md
Use that date as the --after boundary for all repo scans.
2. Read the current changelog
Read src/content/fragments/changelog.md to understand the existing format and identify which months already have entries (to avoid duplicates).
3. Scan repositories for commits
Scan commits after the cutoff date across these repo groups:
Microlink repos at ~/Projects/microlink/:
| Repo | Changelog relevance |
|---|
api | API features, fixes, new parameters, resolution improvements |
metascraper | New integrations, detection improvements |
browserless | Major versions, Puppeteer upgrades, new packages |
mql | SDK changes, new features |
sdk | SDK changes |
www | New pages, landings, tools, blog posts |
html-get | Extraction improvements |
gateway | Dashboard changes (only if user-facing) |
openkey | Releases |
splashy | Releases |
youtube-dl-exec | Releases |
tinyspawn | Releases |
geolocation | UI changes, new features |
fonts | New features |
cards | New presets |
skills | New skills (only if user-facing) |
microlink | SDK and CLI — new methods, commands, flags, output formats |
function | Microlink Function SDK — new packages, API changes, runtime updates |
google | Releases, new Google product support |
is-antibot | Major versions (improves API antibot resolution) |
oembed-spec | Major versions only |
unavatar repos at ~/Projects/unavatar/:
| Repo | Changelog relevance |
|---|
unavatar | New providers, new features (public library) |
api | API changes, new endpoints |
www | Website changes |
For each repo, run:
cd <repo-path> && git log --format="%h %ad %s" --date=format:"%Y-%m-%d" --after="<cutoff>" --no-merges
4. Filter for user-facing changes
Include commits that match:
feat: or feat(...): — new features- New pages, landings, tools in
www
- New providers or integrations
- New presets (cards)
- Major version releases
- Blog posts
- Significant
fix: commits that affect user-visible behavior (resolution, rendering, extraction)
perf: commits with user-visible impact (e.g., Puppeteer upgrade)
Exclude commits that are purely internal:
chore: update dependencies / build(deps): — dependency bumpschore(release): — release tags (use them to identify versions, not as entries)ci: / build: — CI and build configtest: — test-only changeschore(statsd): / chore(sentry): — observability internalschore(k8s): / chore(base): — infrastructurerefactor: — unless it changes user-facing behaviorRevert — unless it reverts a user-facing feature
5. Group by month and compose entries
Group changes by month (### Month YYYY).
Within each month, sort entries newest first (reverse chronological). Use commit dates from the repo scans to determine order. When a change spans multiple repos on the same day, any stable order is fine — what matters is that earlier-in-the-month entries appear lower in the section.
Do not group by product within a month. The reader scans top-to-bottom from most recent to oldest.
When multiple user-facing changes ship on different dates under the same product (e.g., three dashboard updates across a week), prefer one entry per change so each line sits at the correct chronological position. Avoid rolling them into a single composite entry unless they shipped together.
Product link conventions (for writing entries, not for ordering):
[Microlink](/) — website pages, landings, tools[Microlink API](/docs/api/getting-started/overview) — API features and fixes[Browserless](https://browserless.js.org) — include version when relevant[Metascraper](https://metascraper.js.org) — include version when relevant[Microlink MQL](/docs/mql/getting-started/overview) — MQL changes[Microlink SDK](/docs/sdk/getting-started/overview) — SDK changes[Microlink OSS](/oss) — other OSS releases[unavatar.io](https://unavatar.io) — providers and features
6. Entry format rules
Each entry follows this format:
- [Product](link): Description.
Specific conventions:
- unavatar providers: link to
https://unavatar.io/<provider> (e.g., [Steam](https://unavatar.io/steam)). Group multiple providers in a single entry.
- Browserless/Metascraper versions: include version in product name (e.g.,
[Browserless v13](https://browserless.js.org)). Use release tags to determine version numbers.
- API parameters: link to the parameter docs page when available (e.g.,
[function](/docs/api/parameters/function)).
- www pages: link to the page path (e.g.,
[embed](/embed), [pricing](/pricing)).
- Blog posts: use format
[Microlink Blog](/blog): Published [Title](/blog/slug).
- Keep it concise: one line per entry, describe the user impact, not the implementation.
- No internal jargon: avoid mentioning Redis, Kubernetes, Datadog, Sentry, statsd, etc.
7. Present entries for review
Show the proposed entries to the user before editing the file. Ask if any entries should be added, removed, or reworded.
8. Insert into changelog
- New month: prepend the
### Month YYYY section at the top of the file, before the first existing month header. Sort all entries in that section newest first.
- Existing month: merge new entries into the matching month section and re-sort the entire section newest first. Do not append new entries at the bottom — that puts the freshest changes last, which is the wrong reading order.
- Older months: do not modify entries in months that are not being updated.
