Release Debrief

Release Notes Catch-Up

Summarise what's changed in a supported tool since the user last ran this skill against it. No walkthroughs, no exercises. Focused digest of the delta.

Supported Tools

Each tool has a profile in resources/tools/<tool>.md (source URLs, buckets, gotchas) and an output file in resources/outputs/<tool>.md (last-seen version and summary history). Resolve both paths relative to this SKILL.md, not the user's current working directory.

Tool selection: match the tool from the user's prompt against the aliases above. If the user names something not in this table, reply with the supported list and stop.

Flow

1. Load the tool profile. Read resources/tools/<tool>.md. It tells you where to fetch the changelog, how the version scheme works, which buckets to group under, what to drop, and what to watch out for. Treat the profile as authoritative for that tool.

2. Read state. Load the tool's output file. Parse last_seen_version from the frontmatter. If the file is missing, empty, or has no frontmatter version, treat as a first run: summarise the last 3 releases per the profile's version scheme, without prompting.

3. Fetch the current changelog. Use WebFetch or ctx_fetch_and_index against the profile's Primary source. Pull Supporting sources only when you need context for an entry (config schema comparison, API doc linking, editorial summary for colour).

4. Identify the delta. Keep entries newer than the stored version, up to the latest release. Compare versions using the scheme in the profile:

• semver - parse major.minor.patch and compare numerically per component.
• build-number - strip any prefix (b, v) and compare as integer.
• github-release-tag - use GitHub's release order (chronological).

Never compare version tags as lexicographic strings.

5. Summarise. Group entries under the profile's Buckets. For each item:

• One line on what it is.
• One line on why it matters or when you'd reach for it.
• A doc link (from the profile's Feature Link Table, or the release page itself) when the feature is non-trivial.

Apply the profile's Out of Scope list to drop low-signal entries. Apply the profile's Gotchas when deciding how to parse, group, or flag things. Keep tone dense and direct. Flag anything experimental, breaking, or schema-affecting prominently.

6. Persist state. Use Edit (or Write if the output file doesn't yet exist) to update the tool's output file:

• Set last_seen_version in the frontmatter to the latest version from the fetched changelog (the single newest one, even if the summary covers a range).
• Set last_updated to today's date (ISO format).
• Prepend a new ## <version> (<date>) section under # <Tool> Changelog Summaries containing the bucketed summary you just presented. When a single run covers multiple versions, use a range heading: ## <oldest> → <newest> (<date>).
• Keep only the newest two ## sections. If adding the new section would leave three or more, remove the oldest so exactly two remain.

Confirm in one line: Updated resources/outputs/<tool>.md to <version>. If the run fails or the user aborts before the summary is delivered, leave the file alone.

7. Open the output file. After a successful write, run open </absolute/path/to/resources/outputs/<tool>.md> so the user can read the summary in their default markdown viewer.

Storage File Format

Each output file follows this shape:

---
last_seen_version: 2.1.112
last_updated: 2026-04-17
---

# <Tool> Changelog Summaries

## <version> (<date>)

### <Bucket>
- ...

## <prior version> (<prior date>)

### <Bucket>
- ...

<version> in the heading can be a single version (2.1.112) or a range when one run covered several (2.1.109 → 2.1.112). last_seen_version in the frontmatter is always the single newest version. At most two ## sections: newest at top, prior run directly below. When prepending, drop the oldest.

Scope Overrides

• Explicit version ("what's new since 2.1.90"): use the user's version instead of last_seen_version. Still persist state unless they say not to.
• Date range ("everything in the last 2 weeks"): use changelog dates rather than version. Still persist state.
• Area filter ("just hooks"): filter the delta to that area, but still persist state. Note the filter in the new section's heading: ## <version> (<date>, hooks only).
• No persist ("don't update state"): skip step 6, tell the user state was not persisted.

Common Gotchas

• Resolve resources/tools/<tool>.md and resources/outputs/<tool>.md relative to this SKILL.md. Users invoke the skill from arbitrary working directories.
• Version parsing differs per tool - always read the profile's Version Scheme section before comparing. Don't assume semver.
• If the stored version is newer than anything in the fetched changelog (user bumped it manually, or the source hasn't updated yet), say so plainly and don't invent a delta.
• Use Edit to prepend the new section and remove the oldest so only two remain. Fall back to Write only when the file doesn't yet exist.
• Don't mix tools in one output file. Each tool owns its own output file.
• First-run heuristic (last 3 releases) applies per tool, not per invocation. If the user ran the skill on Claude Code yesterday and asks about OpenCode today, OpenCode is still a first run.

Claude Code Profile

Sources

• Primary (changelog to diff against):
• https://code.claude.com/docs/en/changelog - official Claude Code changelog, one entry per semver release, dense line-item format.
• Supporting (for context / linking):
• https://code.claude.com/docs/en/whats-new/ - weekly editorial summaries. Useful for context and wording, but occasionally omits smaller items - treat the raw changelog as source of truth.
• https://code.claude.com/docs/en/llms.txt - doc index; handy for finding the right feature page to link.
• https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7 - model "what's new" page when a release mentions a new Claude model.

Version Scheme

Semver strings like 2.1.95, 2.1.112. Compare numerically by component, not lexicographically (2.1.9 < 2.1.10). On first run, surface the last 3 releases.

Buckets

Group changelog entries under these headings. Buckets reflect Claude Code's feature surface area.

• Hooks: hook events, hook settings, matcher syntax, lifecycle changes.
• MCP & Plugins: MCP server support, plugin framework, plugin marketplaces.
• CLI & Terminal: slash commands, keybindings, status line, TUI/fullscreen, fast mode, interactive-mode tweaks.
• Skills & Commands: Skill tool, slash-command auto-discovery, user-invocable skills.
• Subagents: sub-agent launching, agent teams, worktree isolation.
• Permissions & Sandboxing: permission modes, sandbox filesystem/network rules, security model.
• Memory & Config: settings.json shape, env vars, .claude directory layout, CLAUDE.md behaviour.
• Web & Desktop: desktop app, Claude Code on the web, remote control, mobile push.
• Context & Performance: context window, checkpointing, auto-compaction, monitoring/costs.
• Scheduled Tasks: scheduled-task creation, management, cron semantics.
• Channels & Events: channels API, event streaming.

Feature Link Table

Deep-link to the relevant doc page when a feature is non-trivial. All paths are under https://code.claude.com/docs/en/.

Out of Scope

Skip unless the user explicitly asks:

• Agent SDK changes (/agent-sdk/*) - separate product.
• Cloud providers (Bedrock, Vertex, Foundry), authentication, LLM gateway, model config.
• IDE extensions (VS Code, JetBrains), CI/CD integrations (GitHub Actions, GitLab), Slack, Chrome.

Gotchas

• The changelog page is large. Fetch it via WebFetch or ctx_fetch_and_index, not Bash piping, to keep the main context lean.
• Don't conflate changelog entries with What's New summaries. The weekly summaries editorialise and occasionally omit smaller items, so treat the changelog as source of truth for the list and use the summaries only for colour.
• Some changelog entries span multiple 2.1.x patch versions; deduplicate when the same feature is iterated over several releases in a single window.

llama.cpp Profile

Server-focused. This profile covers llama-server (under tools/server/): HTTP API, server CLI flags, sampling and chat-template behaviour exposed through the server, new model and multimodal architectures the server can serve, and backend changes only when they show up as user-visible server performance or new serving capability. Everything else (non-server CLIs, library internals, model-arch work that doesn't reach the server, conversion-script hygiene) is out of scope.

Sources

• Primary (releases to diff against):
• https://github.com/ggml-org/llama.cpp/releases. Tags are b<N> (e.g. b8833). Each release body has one auto-generated title line derived from a single squash-merged commit, followed by the full commit message inside a <details> block, then a fixed "Assets" section listing per-platform binaries (macOS/iOS/Linux/Android/Windows/openEuler). Release notes are not curated, there is no "Highlights" section, and there is no CHANGELOG.md at the repo root.
• Supporting (for context / linking):
• https://raw.githubusercontent.com/ggml-org/llama.cpp/refs/heads/master/tools/server/README.md. Current user-facing llama-server docs: features list, CLI flags (common, sampling, server-specific), and HTTP API endpoint reference.
• https://github.com/ggml-org/llama.cpp/issues/9291. Pinned "server changelog" tracker issue, referenced from the server README for long-running feature history.

Version Scheme

Tags use a monotonically increasing build number: b<N> where N is the CI build counter (currently b8833, 2026-04-17). Every merge to master produces a tagged release, so there is no semver, no minor/major distinction, and no pre-release channel. Compare versions by stripping the leading b and doing an integer compare: int(tag[1:]). Do not lexicographically sort tag strings, b9000 sorts before b8833 as a string.

Buckets

Bucket by commit prefix parsed from the first non-empty line of the release body (or the release title, which is the same string). Everything should answer the question "does this change affect a user running llama-server?"; if not, drop it (see Out of Scope). Map server-relevant commits into:

• HTTP API and endpoints: server: commits that add/change endpoints, response shapes, streaming behaviour, OAI/Anthropic compatibility, function calling, multimodal over HTTP, /slots, /props, /health, /metrics, the built-in web UI. This is the highest-signal bucket.
• Server CLI flags and config: server: commits that add, rename, deprecate, or change defaults on llama-server flags (--host, --port, --ctx-size, --parallel, --cont-batching, --jinja, --chat-template, LLAMA_ARG_* env vars, etc.). Breaking flag changes are load-bearing for users' launch scripts.
• Sampling and chat templates (server-visible): tokenizer:, autoparser:, chat template parsing, jinja handling, tool-call parsing - but only when the change is exposed through the server's request/response or the --chat-template / --jinja flags. Purely library-internal parser work goes in Out of Scope.
• Model and multimodal support: model:, models:, mtmd:, and supporting convert: / tokenizer: work that lets llama-server load or serve a new architecture, vision/audio encoder, or chat template. New model families are high-signal even when only part of the commit sequence is server-facing - summarise the end-to-end story (arch added, conversion supported, chat template landed, server can serve it). Skip library-only arch work that doesn't reach the server.
• Server performance and serving capability: backend commits (CUDA:, metal:, vulkan:, sycl:, hexagon:, rpc:, ggml-cpu:, KV cache type additions, speculative decoding wiring) when they produce a measurable server-side speed-up, enable a new device for serving, or change default kernel selection. Drop pure kernel refactors.
• Serving-relevant quantisation: new quant types or KV cache types that can be loaded and served. Plain GGUF conversion-script changes that don't touch server loading belong in Out of Scope.
• Server build and packaging: Docker images for llama-server, new platform tarballs that include the server binary, CUDA/ROCm toolchain version bumps in published assets. Skip pure CMake plumbing.

Feature Link Table

The server README has stable slugified anchors per heading. Use these for deep-link summaries.

Always link to the specific b<N> release page alongside the server README anchor when a change is user-visible.

Out of Scope

This profile is server-only. Drop everything below unless the user explicitly asks for broader coverage.

• Non-server CLI binaries entirely: llama-cli, llama-run, llama-bench, llama-quantize, llama-mtmd-cli, llama-embedding, llama-gguf-hash, and friends. Any cli: prefix, any change scoped to tools/main/, tools/run/, tools/bench/, tools/quantize/, tools/imatrix/, etc.
• Library internals: ggml :, ggml-ext, ggml-cpu: kernel refactors, llama : internal changes, header moves, symbol renames, graph or allocator tweaks that don't alter server behaviour.
• The sync : ggml commits that pull upstream ggml changes. Always drop by default.
• Backend work (CUDA:, metal:, vulkan:, sycl:, opencl:, hexagon:, rpc:, ggml-webgpu:) that is a pure kernel tweak, op addition, or refactor with no user-visible server impact. Only keep backend commits that produce a measurable server speed-up, enable a new device for serving, or change server defaults.
• Model conversion tooling (convert:, convert-hf-to-gguf, tokeniser conversion) when it is pure script hygiene - refactors, error-message tweaks, or format fixups for models that were already convertible and servable. Keep conversion changes that unblock a new architecture or chat template for llama-server.
• Model-architecture commits that land an internal implementation but don't yet reach the server (no conversion, no chat template, no llama-server path). Flag these as "staged for future support" only if the user asks for a broader model-support view.
• CI tweaks (ci :), CMake plumbing that isn't a new user-facing build flag, test-only changes (server: tests: ..., generic tests:), doc changes unless the doc describes a new server feature.
• examples/ folder churn outside tools/server/.
• Asset/binary list changes unless the change adds, removes, or bumps a server-relevant platform or CUDA/ROCm toolchain.
• Python SDK / bindings changes (python :, libs : in gguf-py) unless they expose a new server feature.

Gotchas

• Tag b<N> sorts wrong as a string. Strip the b and compare as integer: sorted(tags, key=lambda t: int(t[1:])). b9000 > b8999 lexicographically is only coincidentally correct.
• Release cadence is extreme. Observed 30 tags in roughly 3 days (2026-04-14 to 2026-04-17), and 73 tags in the preceding ~7 days. A week-long delta commonly exceeds 50 releases. Group aggressively by bucket, deduplicate near-identical titles (e.g. multiple CUDA: kernel tweaks), and skip trivial entries.
• Each release body is a single squash commit, not a multi-item changelog. Do not look for bullet lists of changes per release, parse the commit title line for the prefix and the PR number ((#21611)).
• Prefix separators vary: server:, server :, CUDA:, [SYCL], ggml-cpu:. Normalise to lowercase and strip brackets and whitespace before bucketing.
• mtmd: prefix means multimodal tokeniser/decoder work. It is user-visible for vision/audio models and belongs in "Model support", not "Server".
• Asset list is long (macOS arm64/x64/Kleidi, iOS XCFramework, Linux x64/arm64/s390x with CPU/Vulkan/ROCm/OpenVINO variants, Android arm64, Windows x64/arm64 with CPU/CUDA 12/CUDA 13/Vulkan/SYCL/HIP, openEuler 310p/910b). Strip it from summaries, only surface diffs when a new platform or toolchain version is added.
• tools/server/README.md uses GitHub slugified anchors (lowercase, spaces to -, punctuation stripped). Construct anchors from the heading text rather than guessing.
• Release notes do not flag breaking changes explicitly. Watch for commits that rename CLI flags (LLAMA_ARG_* env vars), change default values (the README calls out several --no-* toggles), remove deprecated flags (e.g. -dt, --defrag-thold is marked DEPRECATED in current README), or change endpoint response shapes. Treat these as high-priority entries.
• First-run default of 3 releases is misleadingly narrow for llama.cpp - at the current cadence that can be under an hour of changes and mostly noise. On a genuine first run, ask the user what window they want (a day, a week, or a specific tag) before committing to the 3-release default.

llama-swap Profile

Sources

• Primary (releases to diff against):
• https://github.com/mostlygeek/llama-swap/releases - GitHub releases cut by a bot. Tags are monotonic build numbers (v164, v170, ..., v202). Bodies are usually empty or a one line note; the useful content is the auto-generated ## Changelog block (commit list, often with PR numbers).
• Supporting (for context / linking):
• https://raw.githubusercontent.com/mostlygeek/llama-swap/refs/heads/main/config.example.yaml - always-current example config with inline comments for every key. Use to validate whether a release changed the schema.
• https://github.com/mostlygeek/llama-swap/blob/main/docs/configuration.md - prose docs for config keys (ttl, macros, matrix, hooks, env, aliases, filters).
• https://raw.githubusercontent.com/mostlygeek/llama-swap/refs/heads/main/config-schema.json - JSON schema referenced by the YAML modeline; useful to confirm a new/renamed key.

Version Scheme

Tags are v<N> where N is a monotonically increasing integer build number, not semver. Newer tag = larger integer (v202 is newer than v164). "Newer than last_seen_version" is a numeric compare on the integer suffix. Do NOT sort tags lexicographically (v99 would appear after v200). Strip the leading v and compare as ints. Assets are named llama-swap_<N>_<os>_<arch>.tar.gz without the v.

Buckets

Group release entries under these headings. Assign by reading the commit prefix in the auto-generated changelog (e.g. proxy:, config:, docker/unified:, ui-svelte:, docs:, ci:, build(deps):).

• Proxy / routing: Request handling, new upstream endpoints (/v1/messages, /v1/images/generations, /sdapi, /infill), metrics capture, timeouts, panic recovery. Commits usually prefixed proxy: or proxy,proxy/config:.
• Model lifecycle (swap / matrix / groups): The solver-based matrix swap DSL (added in v202, #646), legacy groups, preload/evict behaviour, TTL, concurrent model orchestration.
• Config / YAML schema: New top-level keys or per-model fields, macros (including macro-in-macro, v164), macro expansion in new places (peer apiKey, filters, name, description), schema validation in CI.
• UI / playground (ui-svelte): The bundled Svelte UI - new tabs (Rerank, v195), request/response capturing, Vite upgrades, frontend security fixes.
• Docker / build: docker/unified image variants (rootless, CUDA, ik_llama.cpp), CMAKE_CUDA_ARCHITECTURES build arg, static llama.cpp builds, custom base image support.
• Observability / metrics: Metrics endpoint behaviour, wall-clock duration preservation, in-memory metrics buffer, loading-state streaming in the reasoning field.
• Fixes / hardening: Bug fixes with no new surface area (panic recovery, natural model sort, security patches). Use for items that don't fit the feature buckets above.

Feature Link Table

Deep-linkable anchors in docs/configuration.md are limited, so prefer linking to config.example.yaml line references or the feature row in the docs table. PR numbers resolve via https://github.com/mostlygeek/llama-swap/pull/<N>.

Out of Scope

Skip unless the user asks: build(deps): bumps (picomatch, Vite minor bumps, etc.) that don't change runtime behaviour, ci: workflow tweaks that don't ship in the binary, README wording fixes, asset-list boilerplate in the release page, and dependency security advisories that are already fixed by the bump itself.

Gotchas

• Release tags are v<build-number>, not semver. v202 is newer than v99, but alphabetical sort puts v99 last. Always parse the integer.
• Release bodies are usually empty. The real changelog is the auto-generated commit list under ## Changelog. Some tags (e.g. v164, v180, v185, v195) are single-commit releases, so one line in the changelog is the whole release.
• groups is legacy as of v202 and replaced by the new matrix solver (PR #646). A config can use matrix OR groups, never both - config loading errors out otherwise. Flag any user on an older build who writes groups: that they should plan to migrate.
• Config schema changes are load-bearing: when keys move, are renamed, or gain required subkeys, users' YAML stops validating against config-schema.json. Call schema-affecting commits out prominently and cross-reference the current config.example.yaml.
• The bundled UI (ui-svelte) ships inside the binary; a ui-svelte: security or Vite bump is still a user-facing change, not pure frontend housekeeping.

OpenCode Profile

Sources

• Primary (changelog to diff against):
• https://opencode.ai/changelog - single long page with every release block, newest on top. Each block is anchored by a semver tag (e.g. v1.4.10) and a human date (e.g. Apr 17, 2026).
• Supporting (for context / linking):
• https://opencode.ai/docs - docs index and "Intro" page, covers install, /connect, /init, and pointers into the rest of the docs tree.
• https://opencode.ai/docs/config/ - JSON/JSONC config schema, precedence order (remote -> global -> project -> managed), and .opencode/ directory layout for agents, commands, plugins, skills, tools, themes.
• https://github.com/anomalyco/opencode - source repo and GitHub Releases (note: npm package is opencode-ai, Homebrew tap is anomalyco/tap/opencode; the project is maintained under the anomalyco org).

Version Scheme

OpenCode ships semver releases (e.g. v1.3.9, v1.4.0, v1.4.10) and each release block on the changelog page also carries a human date like Apr 17, 2026. Releases are frequent (multiple per week - v1.4.0 through v1.4.10 land inside a fortnight), so lexical comparison of v1.3.9 vs v1.3.10 will be wrong; parse as proper semver (major.minor.patch) when computing "what's newer than last_seen_version". Patch numbers go double-digit, so string sort is unsafe. The date line is useful for display but the semver tag is the canonical identifier.

Buckets

Group changelog entries under these headings when summarising. OpenCode's own changelog already uses these as ### subheadings inside each release block, so mirror them rather than inventing new ones.

• Core: server/runtime changes - providers, models, sessions, workspaces, auth, ACP, LSP, bash tool, telemetry (OTEL/OTLP), HTTP proxy. Highest-signal bucket; lead with this.
• TUI: terminal UI behaviour - keybinds, pickers, attachments (PDF drag-drop), opencode run flags, paste handling, model/provider selectors.
• Desktop: the desktop app - Windows backend, terminal connections, prompt submission, session review, diff rendering.
• SDK: generated JS SDK and OpenAPI types for /providers, session/shell endpoints, error surfaces when hitting older servers.
• Extensions: plugins, themes-as-packages, plugin install/auth behaviour, package-export option defaults.
• Providers & Models: carve-out from Core when a release is heavy on provider work (Anthropic reasoning levels, GitHub Copilot, OpenRouter, Azure store=true, Alibaba retries, Cloudflare AI Gateway, Claude Opus 4.7 xhigh reasoning). Flag but don't always break out - only if a release has 3+ provider-specific items.
• Config & Permissions: changes to the JSON config schema, .well-known/opencode remote config, managed settings, permission prompts, --dangerously-skip-permissions.

Feature Link Table

The docs site has stable per-topic pages, so deep-link when relevant.

Out of Scope

• Individual provider SDK compatibility fixes (e.g. "Cloudflare AI Gateway drops max_tokens for reasoning models") unless the user uses that provider - flag but don't lead.
• Generated SDK/OpenAPI type regenerations that don't change surface behaviour.
• Windows desktop backend lifecycle fixes unless the user is on Windows.
• Theme-only plugin package plumbing (unless the user asked about themes).
• Contributor attribution lines ([(@handle)](...)) - keep the change text, drop the trailing credit unless the user asked for it.

Gotchas

• Entries aren't versioned as one-line-per-version; each release block contains several ### Core / ### TUI / ### Desktop / ### SDK / ### Extensions subsections with bullet lists under them. The diff key is the semver tag (v1.4.10), not individual bullets.
• Patch versions go double-digit (v1.3.17, v1.4.10) - parse as semver, never lexicographic, or v1.4.10 will sort before v1.4.2.
• The same bullet style ("Fix X", "Added Y") is used for both user-visible features and internal plumbing (e.g. "Fixed OTEL header parsing when a header value contains ="). Read the bullet before deciding it's user-facing.
• Many bullets name specific providers (Azure, OpenRouter, GitHub Copilot, Alibaba, Cloudflare AI Gateway, Claude Opus 4.7). These are only relevant to users of that provider - group them under Providers & Models and don't imply universal impact.
• The repo org is anomalyco (not sst or opencode-ai). If cross-referencing PRs or issues, use github.com/anomalyco/opencode. The npm package is opencode-ai.