Announce a release from Claude Code

Why announce a release from the terminal?

Your coding agent already has the changelog, the diff and the pull request in front of it, so it can write an accurate announcement with no copying. You stay in your editor, and the post lands on your calendar for review.

This works well for solo developers and small teams, where the person who ships the code is also the person who tells people about it.

How do you connect Claude Code to Content Postiz?

Run one command in your terminal. It registers the Content Postiz MCP server with Claude Code.

claude mcp add --transport http content-postiz https://content-postiz.vercel.app/mcp

How do you sign in and choose a workspace?

Type /mcp inside Claude Code and choose Content Postiz to sign in. Log in with your Content Postiz account and pick the workspace Claude Code may use. It only sees that workspace.

You do not paste an API key anywhere. The sign-in uses OAuth, and you can disconnect at any time from Claude Code or from Content Postiz.

What should you ask Claude Code to do?

Describe the post the way you would to a teammate. Say which release, which networks, who the audience is and when it should go out. A good prompt names the file to read and the tone to use.

Write a thread about v2.4 from CHANGELOG.md for developers. Post it to X and LinkedIn tomorrow at 10:00. Keep it plain and link to the release notes.

What makes a good release announcement?

Lead with what changed for the user, not with the version number. Developers and customers want to know what is new, why it matters and where to learn more.

• Open with the benefit in one sentence.
• Show one concrete example, such as a command or a screenshot.
• Link to the full notes instead of pasting them.
• Thank the people who reported the issues, where it fits.
• Tailor the length to the network: a thread for X, a short post for LinkedIn.

How do you review it before it goes out?

The posts land on your Content Postiz calendar, where you can read and edit them. Nothing is published that you could not see first. If you work with a team, turn on approvals, and the posts wait for a yes.

Read the drafts as a user would. Check version numbers, links and any claim about speed or features. An assistant can be confidently wrong, so a quick check is worth it.

Can you automate it for every release?

You can make it a habit. After you tag a release, ask Claude Code to read the new changelog entry and prepare the announcement. Some teams add a short note about this step to their release checklist or to the project’s CLAUDE.md file, so the request is always worded the same way.

Keep the review step. Automating the drafting is useful, and automating the publishing without a look is where mistakes happen.

What should the prompt include?

The more clearly you describe the job, the better the first draft. A good release prompt names the source, the audience, the networks, the timing and the tone. You do not need to write much, but each of these details removes a guess from the assistant.

For example, “Read the v2.4 entry in CHANGELOG.md and write a short thread for developers who already use the tool. Keep it plain, no hype, and link to the release notes. Post it to X and LinkedIn tomorrow morning” covers everything it needs.

If the first draft is close but not right, say what to change rather than starting again: “make the first line a question”, “cut it to four posts” or “mention the performance fix before the new command”.

How do you handle a big release differently from a small one?

A patch release rarely needs more than one short post. A major release deserves a small campaign. Ask Claude Code for a short run of posts: a teaser a few days before, an announcement on the day, and a follow-up a few days later that shows one feature in detail.

Space them out. Three posts in a morning will compete with each other, while three posts across a week give your audience time to notice and react. Schedule them in advance, so you are free on launch day to answer questions.

For a very large release, add a post for each audience. Existing users want to know what changed for them, while people who have never heard of the tool want to know why they should care.

How do you keep the tone right for developers?

Developers tend to distrust marketing language. Plain statements and concrete details work better than adjectives. Say what the change does, show a command or a short code sample and link to the documentation.

Tell Claude Code to avoid words like “revolutionary” and “game-changing”, and to prefer specifics such as “startup is now three times faster on a cold cache”. If you have measured something, include the number. If you have not, do not let the assistant invent one.

What should you check before you approve the posts?

Read each draft against the real changelog. An assistant can mix up version numbers, mention a feature that is still in beta or overstate a speed improvement. Check every link and every command.

• Is the version number right?
• Does every link work and go where it should?
• Does each claim match the changelog?
• Is the tone right for each network?
• Is the time zone and the publish time what you intended?

What if Claude Code cannot see the Content Postiz tools?

Type /mcp and check that Content Postiz is listed and signed in. If it is not, run the add command again and sign in. If it is listed but the tools do not appear in the session, start a new session.

If a post goes to the wrong workspace, disconnect and reconnect, and choose the right workspace at the sign-in step. If a post is missing from the calendar, check whether approvals are on, since the post may be waiting for review.

Where else can you use the same routine?

The release announcement is the clearest example, but the same routine fits other moments in a developer’s week. You can ask Claude Code to turn a merged pull request into a short post about what you fixed, to summarise a blog article you wrote into a thread, or to share a lesson from a bug that took you a day to find.

Each time, the pattern is the same: the assistant reads the source in your project, writes the post, and puts it on your calendar for review. You decide what is worth sharing, and the tool takes care of the rest. Over a few weeks, these small posts add up to a steady presence without ever feeling like a separate job.

Frequently asked questions