# Quickstart

Publish your first release on releaseszn, on the website or with your coding agent.

This guide walks you through publishing a release. There are two ways, with
the same checks and the same result: [on the website](#publish-from-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](/docs/release-requirements))

## Publish from the website

No coding agent or API token needed.

1. [Sign in](/login) with GitHub and open
   [Add a project](/settings/projects/new) (also on
   [your projects](/settings/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:

```text
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](/login) 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](/settings/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.

> [!WARNING]
> 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](/settings/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.

```bash
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](/docs/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](/docs/ranking), it also competes
for Release of the Day, Week and Month.

## Next steps

<div class="doc-cards">
<a class="doc-card" href="/docs/release-requirements"><strong>Release requirements</strong><span>The screenshot checks and how to pass them.</span></a>
<a class="doc-card" href="/docs/api-endpoints"><strong>Endpoints</strong><span>Every request the agent makes, if you want to do it by hand.</span></a>
</div>