What this prompt does
This prompt sets up an automated commit-message and changelog system for a [language] project. It produces a Conventional Commits specification with your custom [commit_types], a commitlint configuration using [lint_tool], Husky pre-commit hooks to validate messages, automated CHANGELOG.md generation grouped by type, semantic version bumping driven by commit types, and GitHub Release draft automation with categorized notes. It also includes a commit-message template with scope suggestions for your [project_areas].
The structure works because it makes good release practices fall out of the commit history instead of being manual chores. Once commitlint, Husky, and semantic versioning are wired together, changelogs and version bumps generate themselves from how people already commit. By bundling a team onboarding guide that explains the conventions, the prompt addresses the real adoption blocker: getting everyone to write commits in a consistent, machine-parseable format. The commit-message template seeded with scopes from your [project_areas] removes the guesswork of what scope to use, and the GitHub Release draft automation categorizes notes by type so release announcements stop being a manual copy-paste exercise. Together these turn release housekeeping into a byproduct of normal work rather than a separate chore someone dreads.
When to use it
- Your releases have become guesswork and you want changelogs generated from commits automatically.
- You want to enforce Conventional Commits with your own
[commit_types]across the team. - You need semantic version bumping tied to commit types rather than manual decisions.
- You want GitHub Release notes drafted and categorized without hand-assembly.
- You need scope suggestions for your
[project_areas]to keep commit messages consistent. - You want an onboarding guide so the whole team adopts the conventions, not just you.
Example output
Expect a full configuration bundle: a Conventional Commits spec listing your [commit_types], a [lint_tool] commitlint config, Husky hook setup for message validation, a changelog-generation configuration grouped by type, semantic-versioning rules, GitHub Release draft automation, and a commit-message template seeded with scopes from your [project_areas]. A team onboarding guide explaining the conventions usually accompanies the config files.
Pro tips
- Keep
[commit_types]close to the conventional defaults plus a few real additions; an overgrown type list confuses contributors more than it helps. - Seed
[project_areas]with your actual modules so the scope suggestions guide people toward consistent, meaningful commit messages. - Match
[lint_tool]to your ecosystem so the commitlint config and Husky hooks integrate without friction. - Share the onboarding guide early, because the system only pays off once the whole team writes conformant commits.
- Start with warnings before hard-failing commits, so the team adapts to the format without being blocked mid-flow.
- Iterate by reviewing the first auto-generated changelog and tweaking the type-to-section grouping until it reads well.
