Communityコーディング&開発github.com

Commitlint - コミットメッセージ検証

プロジェクトでコミットメッセージの検証を設定する際に使用します。プロジェクトにcommitlint.config.jsや.commitlintrcファイルがある場合、CI/CDパイプラインでコミットフォーマットを強制する場合、LLMプロンプト生成のためのコミットルールを抽出する場合、コミットメッセージのリジェクトエラーをデバッグする場合に役立ちます。

Commitlint - コミットメッセージ検証 とは?

Commitlintは、Conventional Commitsフォーマットに従ってコミットメッセージを検証するための強力なツールです。このスキルは、プロジェクトのコミットlint設定を検出、解析、適用する方法を包括的にガイドします。主な機能として、cosmiconfigを使用した設定ファイルの自動検出(.commitlintrc.*やcommitlint.config.*など、複数のフォーマットをサポート)、ルールの構成、@commitlint/config-conventionalのような共有可能設定との統合、CLIコマンドによる直接検証、プログラムによるAPI利用が可能です。また、LLMプロンプト生成のためのルール抽出パターンも提供し、AIエージェントがコミットメッセージ作成時にcommitlintルールを理解して適用できるようにします。タイプルール、スコープルール、ヘッダールール、ボディルール、フッタールールなど、豊富なルールリファレンスも含まれており、開発者は厳密なコミットメッセージ規約を簡単に設定できます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Jamie-BitFlight/claude_skills/tree/main/plugins/commitlint/skills/commitlint

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Commitlint

コミットlint設定とルールを使用して、Conventional Commitsフォーマットに対してコミットメッセージを検証します。

このスキルを使用するタイミング

以下の場合にこのスキルを使用します:

  • リポジトリにcommitlintを設定する
  • commitlintルールと共有可能設定を構成する
  • pre-commitフックやCI/CDパイプラインにcommitlintを統合する
  • commitlint設定からルールを抽出して、コミットメッセージ生成用のLLMプロンプトを生成する
  • プログラムでコミットメッセージを検証する
  • commitlint設定または検証エラーをトラブルシューティングする
  • commitlintのルール構文と重大度レベルを理解する
  • リポジトリ内のcommitlint設定ファイルを検出する

コア機能

設定の検出

Commitlintはcosmiconfigを使用して、以下の優先順位で設定ファイルを検索します:

専用設定ファイル:

.commitlintrc
.commitlintrc.json
.commitlintrc.yaml
.commitlintrc.yml
.commitlintrc.js
.commitlintrc.cjs
.commitlintrc.mjs
.commitlintrc.ts
.commitlintrc.cts
commitlint.config.js
commitlint.config.cjs
commitlint.config.mjs
commitlint.config.ts
commitlint.config.cts

パッケージファイル:

  • commitlint フィールドがある package.json
  • commitlint フィールドがある package.yaml (PNPM)

設定フォーマット

JavaScript ES Modules (推奨):

// commitlint.config.js または commitlint.config.mjs
export default {
  extends: ['@commitlint/config-conventional'],
};

TypeScript:

// commitlint.config.ts
import type { UserConfig } from '@commitlint/types';
import { RuleConfigSeverity } from '@commitlint/types';

const config: UserConfig = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [RuleConfigSeverity.Error, 'always', ['feat', 'fix', 'docs']],
  },
};

export default config;

JSON:

{
  "extends": ["@commitlint/config-conventional"]
}

YAML:

extends:
  - "@commitlint/config-conventional"

ルールの構成

ルールは配列として構成します:[level, applicability, value]

重大度レベル:

レベル意味TypeScript Enum
0無効RuleConfigSeverity.Disabled
1警告RuleConfigSeverity.Warning
2エラーRuleConfigSeverity.Error

適用性:

  • 'always' - ルールが一致しなければならない
  • 'never' - ルールが一致してはならない

ルールの例:

rules: {
  // タイプが列挙されていない場合エラー
  'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'perf', 'test', 'build', 'ci', 'chore', 'revert']],

  // タイプが空の場合エラー
  'type-empty': [2, 'never'],

  // 件名が空の場合エラー
  'subject-empty': [2, 'never'],

  // ヘッダーが100文字を超える場合エラー
  'header-max-length': [2, 'always', 100],

  // 件名がピリオドで終わる場合エラー
  'subject-full-stop': [2, 'never', '.'],

  // ボディの前に空白行がない場合警告
  'body-leading-blank': [1, 'always'],
}

一般的な構成

@commitlint/config-conventional

最も広く使われている共有可能設定。デフォルトのエラーレベルルール:

ルール構成合格例不合格例
type-enum['build', 'chore', 'ci', 'docs', 'feat', 'fix', 'perf', 'refactor', 'revert', 'style', 'test']fix: messagefoo: message
type-case'lowerCase'fix: messageFIX: message
type-emptyneverfix: message: message
subject-casenever + ['sentence-case', 'start-case', 'pascal-case', 'upper-case']fix: some messagefix: Some Message
subject-emptyneverfix: messagefix:
subject-full-stopnever, '.'fix: messagefix: message.
header-max-length100短いヘッダーヘッダー > 100文字
body-leading-blankalways (警告)ボディの前に空白行空白行なし
body-max-line-length100行 <= 100文字行 > 100文字
footer-leading-blankalways (警告)フッターの前に空白行空白行なし
footer-max-line-length100行 <= 100文字行 > 100文字

完全な構成スキーマ

// commitlint.config.js
export default {
  // 共有可能設定を拡張(ノード解決で解決)
  extends: ['@commitlint/config-conventional'],

  // コミットメッセージ解析用のパーサープリセット
  parserPreset: 'conventional-changelog-atom',

  // 出力フォーマッター
  formatter: '@commitlint/format',

  // カスタムルール(継承したルールを上書き)
  rules: {
    'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
  },

  // 特定のコミットを無視するための真を返す関数
  // デフォルトの無視(マージコミット、リバート、セマバータグ)とマージ
  ignores: [(commit) => commit.includes('WIP')],

  // デフォルトの無視パターンを使用するかどうか
  // デフォルトパターン: 'Merge pull request', 'Revert X', 'v1.2.3' など
  defaultIgnores: true,

  // 失敗時に表示されるカスタムヘルプURL
  helpUrl: 'https://example.com/commit-guidelines',

  // プロンプト設定(@commitlint/cz-commitlint用)
  prompt: {
    messages: {},
    questions: {
      type: {
        description: '変更のタイプを選択してください:',
      },
    },
  },
};

CLIの使用方法

インストール

# npm
npm install -D @commitlint/cli @commitlint/config-conventional

# yarn
yarn add -D @commitlint/cli @commitlint/config-conventional

# pnpm
pnpm add -D @commitlint/cli @commitlint/config-conventional

一般的なコマンド

# 最後のコミットをlint
npx commitlint --last

# コミット範囲をlint
npx commitlint --from HEAD~5

# 特定のコミットからlint
npx commitlint --from abc1234

# 標準入力からメッセージをlint
echo "feat: add feature" | npx commitlint

# ファイルからメッセージをlint
npx commitlint < .git/COMMIT_EDITMSG

# 編集フラグでlint(.git/COMMIT_EDITMSGを読み取る)
npx commitlint --edit

# カスタム設定パスでlint
npx commitlint --config ./custom-commitlint.config.js

# 解決された設定を表示
npx commitlint --print-config

# 厳格モード(警告が終了コード2になる)
npx commitlint --last --strict

終了コード

コード意味
0成功(エラーなし)
1lintエラーが見つかった
2警告が見つかった(厳格モードのみ)
3エラーが見つかった(厳格モード)
9設定ファイルが見つからない(-gフラグ使用時)

ルールリファレンス

タイプルール

ルール条件デフォルト適用性
type-enumtypeが値に含まれているalways
type-casetypeがvalueの大文字小文字ケースalways, 'lower-case'
type-emptytypeが空never
type-max-lengthtypeがvalue以下の文字数always, Infinity
type-min-lengthtypeがvalue以上の文字数always, 0

件名ルール

ルール条件デフォルト適用性
subject-casesubjectがvalueの大文字小文字ケースalways
subject-emptysubjectが空never
subject-full-stopsubjectがvalueで終わるnever, '.'
subject-max-lengthsubjectがvalue以下の文字数always, Infinity
subject-min-lengthsubjectがvalue以上の文字数always, 0
subject-exclamation-marksubjectに:の前に感嘆符があるnever

スコープルール

ルール条件デフォルト適用性
scope-enumscopeが値に含まれているalways, []
scope-casescopeがvalueの大文字小文字ケースalways, 'lower-case'
scope-emptyscopeが空never
scope-max-lengthscopeがvalue以下の文字数always, Infinity
scope-min-lengthscopeがvalue以上の文字数always, 0

ヘッダールール

ルール条件デフォルト適用性
header-caseheaderがvalueの大文字小文字ケースalways, 'lower-case'
header-full-stopheaderがvalueで終わるnever, '.'
header-max-lengthheaderがvalue以下の文字数always, 72
header-min-lengthheaderがvalue以上の文字数always, 0
header-trimheaderに先頭/末尾の空白がないalways

ボディルール

ルール条件デフォルト適用性
body-leading-blankbodyが空白行で始まるalways
body-emptybodyが空never
body-max-lengthbodyがvalue以下の文字数always, Infinity
body-max-line-lengthbodyの行がvalue以下の文字数(URLを除く)always, Infinity
body-min-lengthbodyがvalue以上の文字数always, 0
body-casebodyがvalueの大文字小文字ケースalways, 'lower-case'
body-full-stopbodyがvalueで終わるnever, '.'

フッタールール

ルール条件デフォルト適用性
footer-leading-blankfooterが空白行で始まるalways
footer-emptyfooterが空never
footer-max-lengthfooterがvalue以下の文字数always, Infinity
footer-max-line-lengthfooterの行がvalue以下の文字数always, Infinity
footer-min-lengthfooterがvalue以上の文字数always, 0

大文字小文字の値

大文字小文字をチェックするルール (*-case) の場合:

[
  'lower-case',    // 小文字
  'upper-case',    // 大文字
  'camel-case',    // キャメルケース
  'kebab-case',    // ケバブケース
  'pascal-case',   // パスカルケース
  'sentence-case', // センテンスケース
  'snake-case',    // スネークケース
  'start-case',    // スタートケース
]

プログラムでの使用

設定の読み込み

import load from '@commitlint/load';

async function getCommitlintConfig() {
  const config = await load();
  console.log(config.rules);
  return config;
}

メッセージの検証

import load from '@commitlint/load';
import lint from '@commitlint/lint';

async function validateMessage(message) {
  const config = await load();
  const result = await lint(message, config.rules);

  return {
    valid: result.valid,
    errors: result.errors,
    warnings: result.warnings,
  };
}

LLM統合パターン

プロンプト生成のためのルール抽出

commitlint設定からLLMフレンドリーな制約を生成:

def extract_rules_for_prompt(config: dict) -> str:
    """commitlintルールをLLMフレンドリーな形式に抽出します。"""
    rules = config.get("rules", {})
    prompt_parts = []

    # type-enumが存在する場合
    if "type-enum" in rules:
        level, applicability, types = rules["type-enum"]
        if level > 0 and applicability == "always":
            prompt_parts.append(f"許可されるコミットタイプ: {', '.join(types)}")

    # scope-enumが存在する場合
    if "scope-enum" in rules:
        level, applicability, scopes = rules["scope-enum"]
        if level > 0 and applicability == "always":
            prompt_parts.append(f"許可されるスコープ: {', '.join(scopes)}")

    # header-max-lengthが存在する場合
    if "header-max-length" in rules:
        level, applicability, max_len = rules["header-max-length"]
        if level > 0 and applicability == "always":
            prompt_parts.append(f"コミットヘッダーの最大長: {max_len}文字")

    # subject-caseが存在する場合
    if "subject-case" in rules:
        level, applicability, cases = rules["subject-case"]
        if level > 0:
            if applicability == "always":
                prompt_parts.append(f"件名は次のいずれかのケースである必要があります: {', '.join(cases)}")
            elif applicability == "never":
                prompt_parts.append(f"件名は次のいずれのケースでもあってはいけません: {', '.join(cases)}")

    if not prompt_parts:
        return "このリポジトリでは、定義済みのコミットルール制約は見つかりませんでした。"

    return "\n".join(prompt_parts)

生成されたコミットメッセージの検証

import subprocess
import json

def validate_commit_message(message: str) -> dict:
    """commitlintを使用してコミットメッセージを検証します。"""
    result = subprocess.run(
        ["npx", "commitlint"],
        input=message,
        text=True,
        capture_output=True
    )
    return {
        "valid": result.returncode == 0,
        "errors": result.stdout.split("\n") if result.stdout else []
    }

ベストプラクティス

設定構成

  1. 継承から始める: @commitlint/config-conventionalをベースとして使用
  2. ルールを選択的に上書き: 特定の要件に合わせてルールをカスタマイズ
  3. 設定をバージョン管理する: チーム全体で一貫性を確保
  4. CI/CDで検証: 開発ワークフローの一部としてコミットlintを実行

チーム統合

# Huskyを使用したpre-commitフック
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

# またはnpm pkg setを使用(Husky 9+)
npm pkg set scripts.prepare="husky"
echo "npx --no -- commitlint --edit $1" > .husky/commit-msg

CI/CD設定

GitHub Actions:

name: Commitlint
on: [pull_request]

jobs:
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v3
      - run: npm install -D @commitlint/cli @commitlint/config-conventional
      - run: npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose

CircleCI:

version: 2.1
jobs:
  commitlint:
    docker:
      - image: cimg/node:lts
    steps:
      - checkout
      - run:
          name: Install dependencies
          command: npm install -D @commitlint/cli @commitlint/config-conventional
      - run:
          name: Validate commits
          command: npx commitlint --from HEAD~$CIRCLE_COMMIT_RANGE_COUNT --verbose

トラブルシューティング

問題解決策
設定が見つからない--print-configを使用して解決された設定を確認
ルールが無視される複数の設定ファイルをマージする extendsの動作を理解
予期しない検証結果ルールのlevel(重大度)が正しく設定されているか確認
フォーマットエラー設定ファイル構文(JSON vs YAML vs JS)を検証
スコープの問題scope-enumが[]に設定されていると、空のスコープまたはスコープなしのみ許可

参考リンク

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

Jamie-BitFlight/agentskill-kaizen-meta-docs

Agentskill kaizen plugin documentation index. Load when needing to read about cross-platform notes, improvement plans, or DuckDB integration.

Jamie-BitFlight/bash-51-features

Bash 5.1 release features and improvements with practical examples. Use when working with Bash 5.1 features, epoch time variables, redirection enhancements, or when user asks about Bash 5.1 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-52-features

Bash 5.2 release features and improvements with practical examples. Use when working with Bash 5.2 features, variable handling enhancements, readline improvements, or when user asks about Bash 5.2 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-53-features

Bash 5.3 release features and improvements with practical examples. Use when working with Bash 5.3 features, new command substitution, GLOBSORT, loadable builtins, or when user asks about Bash 5.3 changes, new features, or version-specific capabilities.

Jamie-BitFlight/bash-development

This skill should be used when the user asks to "write a bash script", "create a shell script", "implement bash function", "parse arguments in bash", "handle errors in bash", or mentions bash development, shell scripting, script templates, or modern bash patterns.

Jamie-BitFlight/bash-lint

This skill should be used when the user asks to "lint bash script", "run shellcheck", "format shell script", "use shfmt", "fix shellcheck errors", or mentions shell script linting, formatting, code quality, or pre-commit hooks for bash.

Jamie-BitFlight/bash-logging

This skill should be used when the user asks to "add logging to bash script", "colorize output", "implement log levels", "CI/CD sections", "terminal colors in bash", or mentions logging functions, emoji output, collapsible CI sections, or shlocksmith.

Jamie-BitFlight/bash-portability

This skill should be used when the user asks about "POSIX compatibility", "portable shell scripts", "cross-shell compatibility", "bashisms", "shebang selection", or mentions writing scripts that work on different shells (bash, sh, dash, zsh) or different systems.

Jamie-BitFlight/bash-testing

This skill should be used when the user asks to "test bash script", "write shell tests", "use shunit2", "use shellspec", "create test suite for bash", or mentions unit testing, test frameworks, mocking, or test-driven development for shell scripts.

Jamie-BitFlight/brainstorming-skill

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or when users request help with ideation, marketing, and strategic planning. Explores user intent, requirements, and design before implementation using research-validated prompt patterns.

Jamie-BitFlight/clang-format

Configure clang-format code formatting. Use when: user mentions clang-format or .clang-format, analyzing code style/patterns, creating/modifying formatting config, troubleshooting formatting, brace styles/indentation/spacing/alignment/pointer alignment, or codifying conventions.

Jamie-BitFlight/conventional-commits

When writing a git commit message. When task completes and changes need committing. When project uses semantic-release, commitizen, git-cliff. When choosing between feat/fix/chore/docs types. When indicating breaking changes. When generating changelogs from commit history.

Jamie-BitFlight/dasel-reference

Use when querying, modifying, or converting JSON, YAML, TOML, XML, CSV, HCL, or INI with dasel v3. Complete reference for selectors, functions, conditionals, variables, spread operator, type casting, and format-specific patterns.

Jamie-BitFlight/data-exploration

Use when exploring unknown structured data files with dasel v3 — discover schema, list keys, find nested values, sample arrays, identify data types across JSON, YAML, TOML, XML, CSV, HCL, INI formats

Jamie-BitFlight/data-transformation

Use when modifying, converting, or transforming structured data with dasel v3 — in-place mutations, format conversion, batch operations, array manipulation, object construction, and merge patterns across JSON, YAML, TOML, XML, CSV, HCL, INI

Jamie-BitFlight/delegate

Decompose substantive work into phases, dispatch each phase to a sub-agent, and adjudicate what comes back. Use whenever a request asks for implementation, investigation, a fix, a review, or any change to files — including small ones — and whenever you are about to read source or run a diagnostic yourself instead of handing it off. Also use when a report from a sub-agent needs judging, when a phase needs re-dispatching, or when a user names one instance of a pattern. Does not apply when your own prompt begins "Your ROLE_TYPE is sub-agent." — then follow references/sub-agent-contract.md instead.

Jamie-BitFlight/enterprise-hibernate-hbm

Dasel v3 query patterns for Hibernate .hbm.xml mapping files — entity-table binding, Java property-to-column extraction, one-to-many set/list/bag relationship tracing, many-to-one foreign key discovery, batch scanning across 60+ HBM files. Use when querying Hibernate ORM class mappings, extracting schema metadata from Java persistence layer, or auditing entity-column relationships in enterprise legacy codebases.

Jamie-BitFlight/enterprise-installanywhere

Dasel v3 query patterns for InstallAnywhere .iap_xml installer definitions — use when querying action sequences, discovering variables, resolving platform conditions, navigating panels, or comparing installer variants. Files are 2.5+ MB, 65,000+ lines — too large for context reads, requires structural dasel queries.

Jamie-BitFlight/enterprise-maven-pom

Dasel v3 selector patterns for Maven POM XML files — use when querying dependency versions, filtering by groupId or scope, extracting module hierarchy from parent POMs, or detecting version conflicts across enterprise multi-module Java projects. Load this skill when working with pom.xml files using dasel.

Jamie-BitFlight/enterprise-spring-xml

Dasel v3 selectors for Spring bean factory XML — use when querying any Spring ApplicationContext XML for bean discovery, dependency wiring, JMS destination mapping, property injection extraction, or cross-bean reference tracing. Load this skill before writing dasel selectors against Spring bean XML files (applicationContext.xml, *_beans.xml, spring-*.xml).

関連スキル