Developer toolingeasy

Changelog generator from conventional commits

A CLI that turns conventional commit history into grouped Markdown release notes and suggests the next semver.

Suggested effort
~3h focused work
Window
24 hours
Starts from
An empty repo
Stack
Requires git
Sign in to start this build →

Opens in a new tab. The clock starts when you press Start inside the environment, not before, and your workspace is kept while you step away.

Time window 24 hours. Suggested effort about 3 hours.

Context

The team writes commit messages in the Conventional Commits style (feat(api): add pagination, fix!: drop node 16) but still assembles release notes by hand. Build a CLI that does it for them.

Core requirements

  • Read commits between two refs from a git repository (changelog --from v1.2.0 --to HEAD), defaulting to "since the latest tag".
  • Parse type, optional scope, the ! breaking marker and BREAKING CHANGE: footers.
  • Output Markdown grouped into Breaking changes, Features, Fixes and Other, each entry with its scope and short hash.
  • Suggest the next semantic version (major for breaking, minor for feat, patch otherwise) with --next-version.
  • Commits that do not follow the convention are listed under Other, never dropped.

Acceptance criteria

  • The commit-message parser is a pure function with unit tests for at least 12 message shapes, including multi-line bodies, footers, scopes with dashes, and malformed headers.
  • An integration test builds a throwaway git repository in a temp directory, makes commits and tags, and checks the output.
  • Running it in a repository with no tags works and says what range it used.
  • --help documents every option.

Stretch goals (optional)

  • Prepend to an existing CHANGELOG.md without duplicating a release.
  • Link hashes to a configurable repository URL.
  • A --json output for other tools.

Constraints

  • Any language. Suggested: Node, Python or Go, calling the git binary or a git library.

Deliverables (every project)

  • Source code committed in this repository (the grader diffs against the first commit).
  • README.md that replaces the stub, with: how to install, run and test it (copy-pasteable commands); the decisions and trade-offs you made; what you would do next with more time; and a short note on how you used the AI agent (what you delegated, what you checked or rewrote).
  • Automated tests that run with a single command (npm test, pytest, go test ./... or cargo test).
  • No secrets in the repository. Anything configurable reads from environment variables with safe defaults.

Ground rules

  • The 24-hour clock is a window, not a workload. Stop at roughly the suggested effort, then write down what you would do next. A small, finished, tested core beats a large unfinished one.
  • Use the AI agent as much or as little as you like: every prompt is recorded and the report shows how it was used. You are judged on the result and on whether you understood and verified what the agent produced.
  • The work is yours. PraxisAI uses it only to produce your assessment report.