mcpField
C
commit-messages

commit-messages

github.com/athola開発34397 回インストール1 日前に更新
リポジトリ

commit-messages について

commit-messagesは、ステージ済みの変更からConventional Commitメッセージを作成するワークフロースキルです。変更の分類、件名と本文の作成、書式と言葉遣いの確認を行い、草案をcommit_msg.txtに保存します。

主な機能

  1. 01ステージ済み変更と最近のコミットの確認
  2. 02コミット種別とスコープによる変更分類
  3. 03件名、本文、フッターの草案作成
  4. 04該当時のディスカッション解決トレーラー追加
  5. 05表現と書式ルールの確認

活用シーン

  1. 01ステージ済み変更のConventional Commit作成
  2. 02課題参照や解決済み議論の記録
  3. 03コミットメッセージの長さとスタイル確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athola/claude-night-market --skill commit-messages

インストール後、Claude Code で/commit-messagesを入力して読み込まれたか確認します。

詳細

Conventional Commit ワークフロー

使用する場面

  • ステージ済みの変更から Conventional Commit 形式のコミットメッセージを生成する場合

使用しない場面

  • PR の準備全般：sanctum:pr-prep を使用してください
  • 既存のコミットの修正：git を直接使用してください

手順

  1. コンテキストを収集する（並行して実行）：

    • git status -sb
    • git diff --cached --stat
    • git diff --cached
    • git log --oneline -5
    • sem が利用可能な場合（leyline:sem-integration を参照）： エンティティ単位の変更を確認するため、sem diff --staged --json

    ステージ済みの変更がない場合は、ユーザーに伝えて終了してください。

    sem の出力を利用できる場合は、生の diff のハンクを解析する代わりに、 コミットの件名と本文にエンティティ名 （関数、クラス、メソッド）を使用してください。たとえば、 「notify.py に検証ロジックを追加」ではなく、 「関数 validate_webhook_url を追加」とします。

  2. 分類する：種別（feat、fix、docs、refactor、 test、chore、style、perf、ci）と任意のスコープを選びます。

  3. メッセージの草案を作成する：

    • 件名：<type>(<scope>): <命令形の要約>（最大50文字）
    • 本文：変更内容と理由を72文字で折り返して記載
    • フッター：BREAKING CHANGE、課題への参照、以下のディスカッション用トレーラー

3a. ディスカッション用トレーラー：変更によって Discussions ボードの指摘を解決する場合は、 独立した行にトレーラーを追加します：

Addresses-Discussion: #654
Addresses-Discussion: #604, #610

これは、指摘の対応完了を示す証拠として scripts/reconcile_discussions.py が受け付ける唯一のシグナルです。 解決コメントを投稿してディスカッションを閉じるため、すでに完了した作業が ボードに残り続けることを防げます。

このコミットで指摘を解決する場合に限り追加してください。 ディスカッションに 言及するだけの文章は単なる参照として扱われ、 書き戻されることはありません。この違いは重要です。 6b28aa1a には「13件のインサイトをディスカッション #424-#436 に投稿」とあります。これは、それらのディスカッションを 開始した コミットです。そこにトレーラーを付けると、 まだ誰も確認していない指摘に「対応済み」と通知することになります。

文脈として役立つ場合は、本文でディスカッションを自由に引用してください。 トレーラーは解決を示すために使います。

  1. 冗長表現のチェック：以下の語句を避け、平易な表現に置き換えます。

    避ける語句代わりに使う語句
    leverage, utilizeuse
    seamlesssmooth
    comprehensivecomplete
    robustsolid
    facilitateenable
    streamlinesimplify
    optimizeimprove
    delveexplore
    multifacetedvaried
    pivotalkey
    intricatedetailed

    また、次の表現も避けます：「it's worth noting」、「at its core」、 「in essence」、「a testament to」

4a. 文字単位の冗長表現チェック：shared/output-hygiene.md （Contract A）を読み込み、以下の記号を取り除きます。そのモジュールが ない場合は、以下を代替ルールとして使います：

記号置き換え
文章内で接続詞として使う "+"and（バージョンやコード内の + は維持）
em ダッシュ —コロン、ピリオド、コンマ、または書き換え
文章の句読点として使う --コロンまたは書き換え
矢印 -> / → を接続表現として使う場合to / into
スマートクォート “ ” ‘ ’半角の " と '
事実を並べた後に続く , so読者が推測できる結果なら削除し、それ以外は独立した文にする

4b. 変更内容のチェック（Contract B）：読者にとっての変更の効果を説明します。 AI が作成したことにも、取り除いた特定の記号にも言及しないでください。 remove AI slop、de-slop、AI-generated content、 AI phrasing、replace em-dashes、remove smart quotes は 書かないでください。テスト方法：件名が「AI の出力を整えた」という意味でしか 成り立たない場合は書き直します。たとえば、 style: replace em-dashes with colons ではなく、 docs: clarify the setup section とします。

  1. ./commit_msg.txt に書き込み、プレビューします。

ルール

  • git commit --no-verify または -n は絶対に使用しないでください
  • 感心させるためではなく、人に伝えるために書いてください
  • pre-commit フックが失敗した場合は、問題を修正してください
  • このスキルはメッセージを下書きするものであり、コミットは行いません。コミットする人は、コミットが取り込まれたと報告する前に、git rev-parse HEAD の実行結果を前後で確認し、HEAD が進んでいることを確かめてください。自動修正を行うフックは、成功したように読める末尾の出力を表示してコミットを中止するため、フックの出力は証拠になりません。ディスカッション #614 を参照してください。

完了条件

  • 下書きした conventional commit メッセージを含む commit_msg.txt が作業ディレクトリに作成されている
  • 件名が <type>(<scope>): <summary> 形式に従い、50 文字以内である
  • くどい表現のチェックに合格している。禁止語（leverage、utilize、seamless、comprehensive、robust など）がメッセージに含まれていない
  • 文字レベルのチェックに合格している。em ダッシュ、文章中の接続詞としての +、スマート引用符、文章中の接続表現としての -> が含まれていない
  • 本文に含められる「, so」で始まる結果の補足は最大 1 つである（scripts/slop_score.py --audit で、それぞれが so_connective として表示されます）
  • ステージング済みのものが何もない場合、スキルはただちに停止し、コミットメッセージを作成せずに「nothing staged」と報告する

コメント

Markdown 対応