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 andBREAKING 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.
--helpdocuments every option.
Stretch goals (optional)
- Prepend to an existing
CHANGELOG.mdwithout duplicating a release. - Link hashes to a configurable repository URL.
- A
--jsonoutput for other tools.
Constraints
- Any language. Suggested: Node, Python or Go, calling the
gitbinary or a git library.
Deliverables (every project)
- Source code committed in this repository (the grader diffs against the first commit).
README.mdthat 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 ./...orcargo 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.