anarlog: Skill for Claude Code

Product Update Newsletter

Announce a desktop release to users through the "Anarlog update (...)" campaign in Loops.

Run this after ../new-changelog/SKILL.md produces the entry and the version is released via ../release-new-version/SKILL.md. The published changelog is the copy source, not the raw commit log.

Nightly announcement

The newsletter follows stable releases. Do not send a newsletter for each Nightly. In the next stable update, include the opt-in Nightly announcement from nightly-announcement.md, alongside that stable release's changelog. Existing users remain on stable automatically.

Before describing Nightly as available, verify its published installers, update feed, and https://anarlog.so/download/nightly/. Use the released stable changelog as the main source; Nightly-only changes are not shipped stable features. Nightly release notes live in the app and GitHub prereleases, not the website changelog. Prepare copy locally before publication is ready; create or update the Loops campaign once the stable release and linked Nightly are live.

Source of Truth

Read https://anarlog.so/changelog/<version>, which renders packages/changelog/content/<version>.md.

The changelog is frequently edited after first publish. When told it changed, re-fetch and diff against the current email body, then apply only the delta. Do not reapply the whole rewrite.

Map items to the existing structure rather than appending a dump:

• Feature-level items become or extend an H3 section.
• Minor UX items become bullets under "Small things that add up".
• Reliability and privacy items append to the fixes paragraph after the bullets.

Keep beta or partially shipped work honestly qualified. If execution is not connected yet, say so.

Copy Style Contract

Write a product email, not an essay. Keep it crisp, concrete, and easy to scan.

• Open with what shipped and when. Prefer We shipped four releases since last week. Anarlog 1.4.8 is here. over scene-setting such as If you've been putting off updating, this is the one to take or It folds in four releases.
• If encouraging an update, use explicit loss framing tied to named features: If you aren't updating, you're missing out on Automations that run after every meeting, editable transcripts, meeting imports, and near-instant sync. Do not use vague hype, guilt, or blame.
• Lead with outcomes and specific numbers: 30 assistants, eight connect directly, about a second. Cut adjectives when a fact can do the work.
• Use short, active H3 headings such as Automations do the work now, Transcripts you can fix, and Sync you stop thinking about.
• Keep most paragraphs to one to three sentences. Split long chains, remove repeated setup, and do not restate the same framing in both the intro and fixes paragraph.
• Use contractions and direct verbs. Last week ... This week ... is a useful cadence when it connects one update to the next. Avoid cutesy transitions such as Now they earn it and vague phrases such as Accuracy got quieter improvements.
• Keep subjects compact and noun-led: Anarlog 1.4.8: automations, meeting imports, instant sync. Preview text should front-load concrete outcomes and stay near 90 to 140 characters.
• Self-critical language belongs only when Anarlog or the company was actually at fault. Never add an apology merely to sound personal.
• Read the final copy aloud and cut anything that can disappear without losing a fact, instruction, or point of view. Changelog lists are allowed; do not force prose just to avoid a list.