Use this skill to write concise commit messages in the Topcoat project’s Conventional Commits format. It helps choose a change type and scope, describe the update clearly, and mark breaking changes so release notes and version bumps can be based on commit history.
Always use this skill before authoring a commit message in the Topcoat repository
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Topcoat follows Conventional Commits. .github/workflows/semantic-pr.yml enforces the same format on PR titles, and PRs are squash-merged, so keep commits and PR titles consistent. release-plz reads the history to generate changelogs and pick version bumps (feat -> minor, fix -> patch, breaking -> major), so pick the type deliberately.
<type>(<scope>): <subject>
<body>
<footer>
Only the header is required.
Type -- one of feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Only feat and fix are user-facing and appear in the changelog.
Scope -- optional. The area touched: a crate name with the topcoat- prefix dropped (view, router, runtime, asset, cookie, session, tailwind, cli, core, font, icon, ui, htmx, alpine-ajax), or a finer subsystem (macro, module) when clearer. Omit it when the change spans crates or the type says enough (chore: bump dependencies).
Subject -- imperative present tense ("add", not "added"/"adds"), lowercase first letter, no trailing period, short.
Body -- optional; add one when the "what" or the "why" is not obvious from the subject. Same tense. State the motivation and contrast it with the previous behavior.
Footer -- reference closed issues (Closes #123). For a breaking change, add ! after the type or scope (feat(router)!: ...) and end with:
BREAKING CHANGE: <what breaks and how to migrate>
Plain ASCII only, per the style skill: -/-- not an em dash, -> not a Unicode arrow, ... not an ellipsis.
Maintainers already know Topcoat and Rust. State what changed and why; skip restated context and throat-clearing.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use this skill to check Topcoat changes locally before committing or opening a pull request. It runs the project’s Rust formatting, lint, test, and documentation commands, plus browser project checks when relevant, so problems can be caught before review.
Use this skill when building procedural macros for Topcoat in Rust. It explains how to preserve parsed syntax in AST nodes, separate parsing from meaning, and keep macro entry points focused on parsing input, expanding valid code, and reporting errors.
Use this skill to prepare a Topcoat pull request from the full branch diff. It guides you to write a Conventional Commits title and a concise body covering the change, verification performed, and an AI-use disclaimer when an agent creates the PR.
Use this skill to write long-form Markdown guides for Topcoat. It covers where documentation sources belong, how to structure explanations from basic to advanced, and how to keep prose plain, concise, and easier to maintain as implementations change.
Apply the project’s Rust conventions when editing code or documentation. The guidance covers module and type organization, workspace dependency declarations, plain English documentation, and tests that check meaningful behavior rather than fixed text.