diff --git a/.claude/commands/release.md b/.claude/commands/release.md
new file mode 100644
index 0000000000..35774b79cd
--- /dev/null
+++ b/.claude/commands/release.md
@@ -0,0 +1,116 @@
+---
+description: Prepare changelog, set version, and commit a new release
+allowed-tools: Read, Bash, Edit, Grep, AskUserQuestion
+---
+
+# Release — Changelog, Set Version, Commit
+
+Full release flow: generate changelog entry, run `set_version`, and commit.
+
+**Arguments:** `$ARGUMENTS` = "$ARGUMENTS"
+
+Parse `$ARGUMENTS` for two optional parts (in any order):
+- A **version number** like `6.7` or `6.7.0` — if provided, use it as the new version exactly.
+- The word **"beta"** — if present, mark the release as beta.
+
+If no version number is given, auto-increment the patch component (see step 2).
+
+## Steps
+
+### 1. Check git status is clean
+
+Run `git status --porcelain`. If there are any uncommitted changes, **stop** and ask the user to commit or discard them before proceeding. Do not continue until status is clean.
+
+### 2. Read the current changelog
+
+Read `changelog.txt` from the repository root. Note the **latest version number** on the first line (e.g. `6.6.3 beta (12.03.26)`). Parse its major.minor.patch components.
+
+### 3. Determine the new version number
+
+- **If a version was provided in arguments**, use it directly (append `.0` if only major.minor was given).
+- **If no version was provided**, auto-increment from the latest changelog version:
+  - If it was a beta, and the new release is **not** beta, reuse the same version number but drop "beta".
+  - If the new release is beta and the latest was also beta with the same major.minor, bump patch.
+  - Otherwise bump the patch component by 1.
+- Present the chosen version to the user and ask for confirmation before proceeding. If the user suggests a different version, use that instead.
+
+### 4. Fetch tags and determine the last release tag
+
+Run `git fetch origin --tags` first to ensure all tags from the public repository are available locally. Then run `git tag --sort=-v:refname` and find the most recent `v*` tag. This is the baseline for the diff.
+
+### 5. Collect commits
+
+Run `git log <last-tag>..HEAD --oneline` to get all commits since the last release.
+
+### 6. Write the changelog entry
+
+Analyze every commit message. Group them mentally into features, improvements, and bug fixes. Then produce **brief, user-facing bullet points** following these rules:
+
+- **Style:** Match the existing changelog tone exactly — short, imperative sentences starting with a verb (Fix, Add, Allow, Show, Improve, Support…). Keep the trailing periods (the existing changelog uses them).
+- **Brevity:** Each bullet should be one short sentence, around 80 characters when possible. No implementation details. No commit hashes.
+- **Selection:** Only include changes that matter to end users. Skip CI, build infra, submodule bumps, code style, refactors, and intermediate WIP commits. Collapse many related commits (e.g. a dozen image-editor commits) into one or two bullets.
+- **Ordering:** Features first, then improvements, then bug fixes.
+- **Quantity:** Aim for 4-12 bullets total depending on the amount of changes.
+
+### 7. Format and insert into changelog.txt
+
+Use this exact format (date is today in DD.MM.YY):
+
+```
+<version> [beta ](DD.MM.YY)
+
+- Bullet one.
+- Bullet two.
+```
+
+Prepend the new entry at the very top of `changelog.txt`, separated by a blank line from the previous first entry. Use the Edit tool.
+
+### 8. Show the entry and wait for approval
+
+Print the full changelog entry in chat and ask the user to review it. Tell them they can:
+- Approve as-is.
+- Edit `changelog.txt` directly in the IDE and tell you to continue.
+- Tell you what to change in chat.
+
+**Do NOT proceed until the user explicitly approves.** If they request changes, apply them and show the updated entry again.
+
+### 9. Run set_version
+
+Once approved, run the `set_version` script from the repository root. On Windows:
+
+```
+.\Telegram\build\set_version.bat <version_arg>
+```
+
+Where `<version_arg>` is formatted as the `set_version` script expects:
+- Stable: `6.7.0` or `6.7`
+- Beta: `6.7.0.beta`
+
+Verify the script exits successfully (exit code 0). If it fails, show the error and stop.
+
+### 10. Commit
+
+Stage all changes and create a commit. The commit message format:
+
+**First line:**
+- For stable: `Version <major>.<minor>.` if patch is 0, otherwise `Version <major>.<minor>.<patch>.`
+- For beta: `Beta version <major>.<minor>.<patch>.`
+
+**Then an empty line, then the changelog bullets.** Each bullet line (starting with `- `) must be wrapped at around 77-78 characters. When wrapping, break at logically correct places (between words/phrases) and indent continuation lines with two spaces.
+
+Example commit message:
+```
+Beta version 6.6.3.
+
+- Drawing tools in image editor
+  (brush, marker, eraser, arrow).
+- Draw-to-reply button in media viewer.
+- Trim recorded voice messages.
+- Fix reorder freeze in chats list.
+```
+
+Use a HEREDOC to pass the message to `git commit -a`.
+
+### 11. Done
+
+Run `git log -1` to show the resulting commit and confirm success.