# Toolbox Changelog

> Generates user-facing changelogs for Devolutions Gateway and Devolutions Agent in Devolutions ToolBox format from CHANGELOG.md.

- Skill: `devolutions/toolbox-changelog` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add devolutions/toolbox-changelog`
- Raw SKILL.md: https://api.skillmd.com/api/skills/devolutions/toolbox-changelog/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: devolutions (https://skillmd.com/u/devolutions)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/devolutions/toolbox-changelog

---


# ToolBox Changelog Generator

Read `CHANGELOG.md` from the project root and produce two user-facing changelogs — one for **Devolutions Gateway** and one for **Devolutions Agent** — ready to paste into the Devolutions ToolBox change history.

## Step 1: Determine the target version

- If the user provided a version argument (e.g. `/toolbox-changelog 2025.3.4`), find the `## 2025.3.4 (...)` block in CHANGELOG.md.
- Otherwise, use the **first** (most recent) version block in the file.

## Step 2: Collect relevant entries

For each entry in the target version block, check the scope (the text in `_italics_` before the colon). An entry can have multiple scopes separated by commas (e.g. `_dgw,agent_:`).

**Scope routing:**

| Scope          | Product              | Label       |
|----------------|----------------------|-------------|
| `dgw`          | Devolutions Gateway  | `Service`   |
| `installer`    | Devolutions Gateway  | `Installer` |
| `agent`        | Devolutions Agent    | `Service`   |
| `agent-installer` | Devolutions Agent | `Installer` |

Ignore entries with any other scope (`webapp`, `jetsocat`, `build`, etc.) — they are internal or belong to other products.

When a single entry has multiple scopes (e.g. `_dgw,agent_:`), emit a separate line for each product it belongs to.

## Step 3: Classify into categories

Map each CHANGELOG section to a user-facing category:

| CHANGELOG section | Category      |
|-------------------|---------------|
| `### Features`    | New features  |
| `### Performance` | Improvements  |
| `### Security`    | Improvements  |
| `### Bug Fixes`   | Fixes         |
| `### Build`       | *(skip)*      |

If unsure, use your judgment: new capabilities → New features, polish/performance/UX → Improvements, fixes → Fixes.

## Step 4: Write user-friendly descriptions

The raw commit message title is often too technical. Rewrite each entry in plain English that a non-developer end user would understand:

- Remove implementation details (crate names, internal module names, PR numbers, commit hashes, protocol internals).
- Use active voice and plain language.
- Preserve the key user-visible benefit.
- Keep it to one line.

**Good examples:**
- `Service - Add options to use a dedicated certificate for CredSSP credential injection`
- `Installer - Allow downloading keys even when the certificate isn't trusted (useful in restricted/air-gapped environments)`
- `Service - Reduce noisy logs: benign client disconnects are now logged as DEBUG instead of ERROR`
- `Service - Add outbound proxy configuration support for HTTP/HTTPS and SOCKS`
- `Service - Automatically generate a self-signed certificate for CredSSP when no TLS certificate is configured`

**Bad examples (too technical):**
- `Service - Replace reqwest system-proxy with proxy_cfg crate for PAC file support` ← internal implementation detail
- `Service - Downgrade BrokenPipe/ConnectionReset/UnexpectedEof from ERROR to DEBUG` ← raw code terms
- `Installer - Fix 9a9f31ad71` ← commit hash, no context

Use the multi-line description under each entry (when present) to understand the user-facing impact — but don't reproduce it verbatim; summarize what the user gains.

**Handling vague entries:** When a commit message title is ambiguous and there is no multi-line description, inspect the commit diff to understand what actually changed. Each CHANGELOG entry contains a commit hash as a link — run `git show <hash>` to read the diff. Use what you find to write an accurate, user-friendly description. Only omit an entry if the diff confirms it is purely internal with no user-visible effect.

## Step 5: Output format

Print the final result. Omit any category that has no entries.

```
Devolutions Gateway

New features
Service - ...
Installer - ...

Improvements
Service - ...

Fixes
Service - ...
Installer - ...

---

Devolutions Agent

New features
Service - ...

Improvements
Service - ...

Fixes
Service - ...
Installer - ...
```

Each entry is on its own line. Categories are separated by a blank line. The two product sections are separated by `---` and a blank line. This makes it easy to copy individual lines directly into the Devolutions ToolBox.