Every commit explains itself.

Run npx @chamoji/cli changelog in your repository. It prints a Markdown changelog with a section for each release tag and an Unreleased section for newer commits. Add --output CHANGELOG.md to write the file, or --format json or --format html for other formats. It needs Node.js 22 or newer and git.

No. chamoji reads emoji commits, Conventional Commits and plain messages like "Fix crash on startup". Dependency updates from Dependabot or Renovate collapse into one line. A short "Why:" line helps, but nothing is required.

From the commits since the last semver tag. ✨ or feat: makes a minor release, 🐛 or fix: a patch, and 💥, a ! after the type or a BREAKING CHANGE: footer a major. chamoji next-version prints it, and chamoji release 2.0.0-rc.1 releases a version you choose instead.

No. chamoji release writes CHANGELOG.md, bumps the version in package.json, package-lock.json, pyproject.toml and Cargo.toml, and makes the release commit and an annotated tag. With --push it pushes them and creates the GitHub release through the GitHub CLI. Publishing to npm, PyPI or crates.io stays a separate step, such as a workflow that runs on the new tag.

Yes. By default it releases the whole repo as one version. Run chamoji setup once and it writes a release section in chamoji.config.json; then each app or package gets its own version, tag, CHANGELOG.md and GitHub release, with tags such as web/v1.3.0. In an app monorepo, a change to a shared package never releases on its own: it rides along into the next release of each app that uses it, marked with the package it came from, such as "via packages/supabase". Releases per app need chamoji 0.13.0 or newer, and chamoji setup needs 0.14.0. See a monorepo release

Run chamoji setup. It works out how the repo is laid out and how it has been released from git and the repo's files, with no AI, and asks only what it can't work out. In a monorepo it shows each app's next release, such as web 0.1.0 → 0.2.0 (minor) web/v0.2.0, and replays your last releases next to what you shipped. One Enter writes the release section of chamoji.config.json; it never commits. It keeps the tag formats you already use, and leaves a starter template's tags and commits out of your notes. It can also turn on memory sharing, connect Claude Code and install the commit hook, each with a yes or no. chamoji setup --yes takes every recommended answer and never installs the hook. It needs chamoji 0.14.0 or newer. See chamoji setup

Yes. chamoji's GitHub Action writes each pushed tag's notes to its GitHub Release, keeps a comment on every pull request with the changelog lines it adds and the version it would make, and can cut the whole release from a button.

semantic-release releases and publishes from CI on every push to the release branch, and expects Conventional Commits by default. changesets builds the changelog from files developers add with each change, and suits monorepos. release-please keeps a release pull request open for Conventional Commits. chamoji reads the commits you already have, in any of three styles, and cuts the release in one command from your terminal, CI or coding agent. In a monorepo, it can version each app or package on its own. See the full comparison

Yes. The CLI is MIT licensed and does everything a single developer needs. Cloud only adds sharing and hosting for teams.

It sorts commits that rules can't place and flags what reviewers should look at. It never marks a change as breaking or overrides what an author wrote. The CLI's --ai is off by default, uses your own TypeSafe key, and sends at most 300 characters of a commit's subject and body, with emails removed.

Cloud works from commit messages and the metadata chamoji keeps in git. Sending diffs is a separate, explicit opt-in, and it's off by default.

We'll email everyone on the waitlist, once, when the first teams can start. Until then, the free CLI already writes your changelogs.