conventional-comments

Conventional Comments format standardizes feedback with required labels (issue, suggestion, todo, question, note, typo), optional blocking indicators (!), and optional decorations (security, performance, a11y, ux). This ensures reviewers communicate intent clearly and reduces ambiguity in code reviews across all projects and languages.

Conventional Comments defines six labels: issue for bugs or problems, suggestion for improvements, todo for follow-up work, question for clarification, note for informational comments, and typo for spelling or formatting fixes. Each label signals the feedback's intent, making reviews faster to scan and act on.

Yes. Conventional Comments supports an optional blocking flag (!) to indicate feedback that must be addressed before merge, and optional decorations like security, performance, a11y, and ux to highlight the comment's impact category. This makes critical feedback immediately visible.

Conventional Comments syntax validation ensures required parts (label and subject) are present, supports optional blocking flags and decorations, and restricts labels to the allowed set. Generating comments in this format creates a standardized baseline that all reviewers can follow.

Yes. Conventional Comments is language-agnostic and applies to code review workflows across any language or project. The format itself is independent of syntax, making it suitable for polyglot teams and codebases.

Conventional Comments require a label and subject line. Optionally add a blocking indicator (!), decorations (security, performance, a11y, ux) to signal impact, and discussion text with context or suggested fixes. This structure keeps feedback actionable and unambiguous.