# Conventional Commit Title Validation Rules in no-mistakes: How the CLI Enforces Standards

> Learn how the no-mistakes CLI enforces conventional commit title validation rules using regex and type inference. Ensure your commit messages meet strict standards for cleaner code.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: how-to-guide
- Published: 2026-07-17

---

**The no-mistakes CLI enforces strict conventional commit formatting through regex validation and automatic type inference in [`internal/conventional/title.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/conventional/title.go).**

The `kunchenguid/no-mistakes` repository implements a rigorous validation system to ensure all pull request titles follow the conventional commit specification. This validation engine lives in [`internal/conventional/title.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/conventional/title.go) and provides both strict checking and intelligent auto-correction capabilities. Understanding these rules helps contributors ensure their PR titles pass automated checks and trigger correct semantic versioning.

## Regex Structure Requirements

Valid titles must match the compiled regular expression defined in `titleRe` at line 8:

```

^([a-z]+)(\([^)]+\))?(!)?: (.+)$

```

This pattern enforces four strict structural components:

- **Lowercase type** – One or more lowercase letters at the start
- **Optional scope** – Parenthetical context like `(parser)` or `(api)`
- **Optional breaking marker** – An exclamation mark `!` for breaking changes
- **Separator and description** – A colon, space, and the actual commit message

The regex captures these components to enable granular validation of each part.

## Allowed Commit Types

The `validTypes` map (lines 10–22 in [`internal/conventional/title.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/conventional/title.go)) restricts titles to these eleven conventional commit types:

- `feat` – New features
- `fix` – Bug fixes
- `docs` – Documentation changes
- `style` – Code style changes (formatting, semicolons, etc.)
- `refactor` – Code changes that neither fix bugs nor add features
- `perf` – Performance improvements
- `test` – Test additions or corrections
- `build` – Build system or dependency changes
- `ci` – Continuous integration changes
- `chore` – Other changes that don't modify source or test files
- `revert` – Reverts previous commits

Any type outside this set causes validation to fail, even if the regex structure matches.

## Validation Logic with IsTitle

The `IsTitle` function (lines 26–29) performs the actual validation through a two-step process:

1. Trims whitespace from the input string
2. Applies the regex match and checks if the captured type exists in `validTypes`

The function returns `true` only when both conditions are satisfied. This ensures that malformed titles or titles with unsupported types are rejected immediately.

```go
// Example: a valid title passes the check
title := "feat(parser): add support for JSON"
ok := conventional.IsTitle(title) // true

```

## Automatic Title Correction via TightenTitle

When validation fails, the `TightenTitle` function (lines 31–40) attempts intelligent auto-correction:

- Trims whitespace from the input
- Returns empty string if input is empty
- If regex fails or type is invalid, prefixes the original text with an inferred type and colon (`type: original-title`)

The type inference relies on the `inferType` function, which analyzes title content using helper functions:

- `hasDocumentationLanguage` – Detects documentation-related terminology
- `hasProductImpactLanguage` – Identifies user-facing changes
- `isFeatureLanguage` – Recognizes feature addition cues
- `isFixLanguage` – Identifies bug fix terminology

```go
// Example: an invalid title is auto-corrected
raw := "Add new JSON parser"
fixed := conventional.TightenTitle(raw) // "feat: Add new JSON parser"

```

## Release Type Guidance

The constant `ReleaseTypeRule` (lines 24–25) provides policy guidance for distinguishing between `feat`, `fix`, and non-release types. This rule feeds into the AI prompts used by the *suggest* agent, ensuring that automatically generated commit suggestions follow semantic versioning principles.

## Integration Across the Workflow

The validation rules integrate into multiple workflow stages:

- **[`internal/pipeline/steps/pr.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/pr.go)** – Applies `conventional.TightenTitle` to PR titles before creation
- **[`internal/agent/suggest.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/agent/suggest.go)** – Uses the same validation logic (lines 31–35) to generate conventional commit subjects for AI-suggested commits

This ensures consistency whether titles come from human contributors or automated agents.

## Summary

- **Strict regex matching** requires the pattern `^([a-z]+)(\([^)]+\))?(!)?: (.+)$` in [`internal/conventional/title.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/conventional/title.go)
- **Eleven allowed types** are enforced: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, and `revert`
- **Dual validation** through `IsTitle` checks both structure and type membership
- **Auto-correction** via `TightenTitle` infers types using natural language analysis when titles don't match conventions
- **Workflow integration** ensures PR titles and AI suggestions both conform to conventional commit standards

## Frequently Asked Questions

### What regex pattern does no-mistakes use for title validation?

The validator uses the pattern `^([a-z]+)(\([^)]+\))?(!)?: (.+)$` compiled into `titleRe` at line 8 of [`internal/conventional/title.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/conventional/title.go). This requires a lowercase type, optional scope in parentheses, optional breaking change marker, colon, space, and description.

### Which commit types are supported by the validator?

The `validTypes` map recognizes eleven types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, and `revert`. These map to the conventional commit specification categories and determine semantic versioning impacts.

### How does the automatic title tightening work?

The `TightenTitle` function attempts to fix non-compliant titles by analyzing the content through `inferType`. If the title lacks a valid type or structure, the function prefixes the original text with an inferred type (such as `feat:` or `fix:`) based on documentation keywords, product impact language, or feature/fix cues detected in the text.

### Where is the validation logic integrated in the no-mistakes workflow?

The validation runs in [`internal/pipeline/steps/pr.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/pr.go) to clean PR titles before submission, and in [`internal/agent/suggest.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/agent/suggest.go) to ensure AI-generated commit suggestions follow conventional commit standards. Both locations call `conventional.TightenTitle` to enforce consistency across manual and automated contributions.