Quickstart

This guide walks you through publishing a release. There are two ways, with the same checks and the same result: on the website, step by step, or with a coding agent (steps 1 to 4). Either takes a few minutes once your release is tagged on GitHub.

Prerequisites #

• A public GitHub repository you can admin or maintain
• A version tag on GitHub for the release you want to publish (for example v1.2.0); a GitHub release isn’t required
• A screenshot of your software, at least 1200×630 pixels (see Release requirements)

Publish from the website #

No coding agent or API token needed.

1. Sign in with GitHub and open Add a project (also on your projects, under your @handle).
2. Paste the repository’s GitHub address, write a one-line summary, and pick tags: exactly one AI-usage tag (how much of the code AI wrote; it’s disclosure, not a penalty), and the kind of software and platforms if you like. If something isn’t right, the form says what under the field.
3. The page that opens imports the project and its releases from GitHub; it updates by itself when that’s done. Your newest release is the draft you prepare.
4. Check the changelog: it starts as your GitHub release notes. Say what changed and why it matters to people who use it; a release whose changelog is empty or only says “bump” isn’t ranked.
5. Add the screenshot: upload it from your computer, or give the address of an image (one in your README works), with a sentence saying what it shows. It’s checked in a few seconds, and each check that fails says what to change; then try another image.
6. Check and publish: the page lists what’s needed to publish and what’s needed to be ranked. When nothing blocks it, press publish and confirm. You get the release’s address, and whether it competes on the boards.

Your next release shows up on the same page after you tag it on GitHub and press sync with GitHub.

1. Run the prompt #

Open your coding agent in the repository and give it this instruction:

Follow https://releaseszn.com/docs/submit-prompt.md to publish the latest
release of this project on releaseszn.

2. Approve the agent’s sign-in #

The first time, the agent has no API token. It shows you a link and a code, such as https://releaseszn.com/device?code=BCDF-GHJK. Open the link, sign in with GitHub, check that the program named is your agent and that you started this just now, and click Approve.

The agent gets a token with the submit scope and saves it to ~/.config/releaseszn/auth-header itself, without showing it: you never copy or paste it. The token can add, change and delete your projects and publish their releases, but it can’t delete your account. It is listed on API tokens under the agent’s name, where you can revoke it. Approve only codes your own agent showed you: whoever approves gives that program a token for their account.

Never paste a token into a chat, and never commit it. If an agent asks for one, point it to this step.

Or create the token yourself #

Create a token with the submit scope on API tokens (your @handle in the header); it starts with rsz_ and is shown only once. Then save it in a file only you can read. Run this in your own terminal: it asks for the token without showing it.

mkdir -p ~/.config/releaseszn && (umask 077 && read -rs -p 'releaseszn token: ' token && echo && printf 'Authorization: Bearer %s\n' "$token" > ~/.config/releaseszn/auth-header)

The file holds the whole Authorization header, and the agent hands it to curl (curl -H @$HOME/.config/releaseszn/auth-header …), so the token’s value never shows in the conversation or passes through the agent’s shell. An agent that runs in the same shell can use a RELEASESZN_TOKEN environment variable instead; most coding agents (Claude Code, Codex) don’t see what you export, which is why the file is the default.

3. Let the agent prepare the release #

Once signed in, the agent will:

1. Read your README and git history.
2. Create the project on releaseszn, with tags and an honest AI-usage tag.
3. Write a changelog from the commits since your previous tag.
4. Look through your README and repository for a screenshot, and ask you for one only if none fits.
5. Ask whether you want to share which LLMs helped (optional).
6. Run the release check and fix anything it reports.

You can read the full prompt on the Agent prompt page.

4. Review and publish #

The agent shows you the summary, tags, changelog and screenshot, then asks for confirmation. Once you confirm, it publishes and gives you the release URL, for example https://releaseszn.com/p/ripfast/v1.2.0.

Your release appears in the feed immediately and reaches everyone who follows the project. If it meets the ranking rules, it also competes for Release of the Day, Week and Month.

Next steps #