Codex ユーザーが日常でぶつかる悩み
日々の開発現場で、コミットメッセージ作成は意外とストレスの種になりがちです。特にCodexを使ったAI coding workflowでは、contextやrepository understandingが重要視される一方で、コミットメッセージの「お堅さ」や「マンネリ感」に悩む声も少なくありません。ジョーク・パロディ系Skillが求められる背景には、こうした日常のちょっとした息抜きニーズがあります。
- コミットメッセージが毎回ワンパターンで、開発の楽しさが減っている
- プロジェクトやdirectoryごとに雰囲気が違うのに、無機質なメッセージばかり並ぶ
- onboardingしたてのメンバーが「何を書けばいいかわからず」形式的な一文だけを書く
- 長時間のAI coding workflowで、気分転換や話題づくりになるネタがほしい
- Codexのcontextやrepo構造を意識しすぎて、文学的な遊び心が入り込む余地がない
この Skill が一言でいうと何を解決するか
一言サマリ: コミットメッセージを自動で俳句形式に変換するSkillですSkill。
もう少し具体化すると、このSkillを入れることで以下のような状態になる:
- AI coding workflow中のコミットメッセージが五・七・五の俳句になり、開発現場に文学的な和みが生まれる
- repositoryやdirectoryごとの作業記録が、単調なログではなく“和の心”で彩られる
- onboarding時にもジョークを交えたコミュニケーションが生まれ、チームの雰囲気が柔らかくなる
- monorepo環境でもSkillがパッと動き、どのpackageでも俳句コミットが自動生成される
- マンネリ化しがちなcontext管理やmemory消費の合間に、ちょっとした癒しや話題提供ができる
GitHub から degit でコマンド1行、Codex の Skill ディレクトリに展開できます。Node.js があれば即時に動きます。
npx degit aazutaku/ai-note/codex/commit-haiku-generator .agents/skills/commit-haiku-generator実行したらこうなる (3つの利用シーン)
使う側がイメージしやすいよう、擬似 terminal で出力例を3パターン示す。Skill が返す出力は推測だが、現実的なフォーマット・現実的な長さで書く。
シーン1: session 開始時 (プロジェクト初動で)
# /skills menu or commit-haiku-generator mention
> コミットメッセージ: "Initialize project structure and add README"
[haiku]
始まりの
ディレクトリに
README置く
# コミットメッセージが自動で五・七・五に変換されて表示
シーン2: monorepo / package 跨ぎ作業時
> コミットメッセージ: "Update packages/core/utils with new date parser"
[haiku]
コア超えて
日付パーサー
新たなる
# packages/core/utils ディレクトリでの作業も、俳句化してコミット
シーン3: お遊び的な使い方
> コミットメッセージ: "Fix typo in function name"
[haiku]
名を正す
小さきミスも
春の風
# 些細な修正も、なぜか文学的な一句に
before / after の違い
| 場面 | Skill 無し | Skill 有り |
|---|---|---|
| session 再開時 | repo 構造から毎回説明、path も指定し直し | Codex が自動で context を復元、最小プロンプトで再開 |
| monorepo 移動 | 違う package のコードを参照しがち | directory boundary を意識して必要な範囲だけ見る |
| 長時間 workflow | long context で重要箇所が薄まる | コミットのたびに俳句が生まれ、気分転換や集中力リセットに |
発動方式
明示呼び出し (/skills menu or $skill-name mention) と暗黙発動 (description マッチ) の両方に対応。
Skill の中身を全部見せる
.agents/skills/commit-haiku-generator/ に配置するファイル一覧です。GitHub に push 済みなので、上記の degit コマンドで一発取得できます。
.agents/skills/commit-haiku-generator/
├── SKILL.md
├── scripts/
│ └── commit_haiku_generator.py
└── references/
└── design_notes.md
各ファイルの役割
| ファイル | 役割 |
|---|---|
SKILL.md |
Skill本体。frontmatter (name/description) と指示本文。Codex がこの内容をエージェント指示として読み込み、ユーザーのプロンプトに応じて発動します |
scripts/commit_haiku_generator.py |
コミットメッセージを俳句(五・七・五)に変換します。 |
references/design_notes.md |
概要 をまとめた参考資料 |
SKILL.md
---
name: commit-haiku-generator
description: コミットメッセージ生成や git commit 操作時に、"haiku" "俳句" "五七五" "poem" などのキーワードや明示的なSkill呼び出しが検出された場合に発動します。コミット内容を和風の五・七・五俳句形式へ自動変換したい時に最適です。
---
# 機能概要
このSkillは、通常のコミットメッセージを日本の伝統的な五・七・五の俳句形式に自動変換します。エンジニアの作業ログや修正内容が、文学的な一句として表現されることで、開発現場にユーモアと癒しをもたらします。真面目な修正も、なぜか和の心満載の一句に。コミット履歴がカオスな俳句集になることで、チームの雰囲気が和らぎ、日々の開発が少し楽しくなります。
# 使い方
- 明示呼び出し例: `/skills commit-haiku-generator "バグ修正とリファクタリング"`
- 暗黙発動キーワード: "haiku", "俳句", "五七五", "poem", "和風コミット"
- コミット直前に本Skillを呼び出すことで、直近の差分や入力文から俳句形式のメッセージを自動生成します。
# 出力例
```
$ python commit_haiku_generator.py --message "APIのバグ修正とテスト追加"
API直し
テストも増やす
春の午後
```
または
```
$ /skills commit-haiku-generator "README更新"
ドキュメント
春風に乗り
新しく
```
# 注意点
- 生成される俳句は五・七・五のリズムを優先しますが、意味がやや破綻する場合もあります。
- 重大なリリースや履歴管理が厳密なプロジェクトでは利用を控えてください。
- ローカルでのみ実行され、リモートには自動送信されません。
- 除外パス: バイナリファイルや巨大なdiffは対象外です。
# 参考資料
- [参考: 俳句の基本](https://ja.wikipedia.org/wiki/%E4%BF%B3%E5%8F%A5)
- references/design_notes.md に設計方針や利用例を記載
scripts/commit_haiku_generator.py
import argparse
import sys
import re
import random
import unicodedata
from typing import List, Tuple
SEASON_WORDS = [
"春の午後", "夏の夜", "秋の風", "冬の朝", "桜咲く", "雪降る", "月明かり", "新緑", "紅葉", "梅雨空", "涼しさ", "落ち葉", "夕焼け", "朝露", "蝉しぐれ"
]
DEFAULT_HAIKU = [
("コード直し", "テストも書いて", "春の午後"),
("新機能", "追加の喜び", "夏が来る"),
("README", "静かに更新", "秋の風")
]
# ひらがな・カタカナ・漢字を一文字ずつカウント(音節数近似)
def count_on(text: str) -> int:
# 句読点や空白を除去
text = re.sub(r'[\s。、,.]', '', text)
count = 0
for ch in text:
if unicodedata.name(ch).startswith(('HIRAGANA', 'KATAKANA')):
count += 1
elif unicodedata.east_asian_width(ch) in ('F', 'W', 'A'):
count += 1
else:
# 英数字は1単語=1音とみなす
if ch.isalnum():
count += 1
return count
def split_to_haiku_lines(text: str) -> Tuple[str, str, str]:
# まず句読点・改行で分割
phrases = re.split(r'[。、,.\n]', text)
phrases = [p.strip() for p in phrases if p.strip()]
# 句が足りなければランダム補完
while len(phrases) < 3:
phrases.append(random.choice(SEASON_WORDS))
# 各句を五・七・五に調整
lines = []
targets = [5, 7, 5]
for i, t in enumerate(targets):
if i < len(phrases):
phrase = phrases[i]
on = count_on(phrase)
if on == t:
lines.append(phrase)
elif on < t:
# 季語で補完
lines.append(phrase + random.choice(SEASON_WORDS)[:t-on])
else:
# 長すぎる場合は切り詰め
lines.append(phrase[:t])
else:
lines.append(random.choice(SEASON_WORDS))
return tuple(lines)
def generate_haiku_from_message(message: str) -> Tuple[str, str, str]:
# 何も入力がなければデフォルト俳句
if not message or len(message.strip()) == 0:
return random.choice(DEFAULT_HAIKU)
return split_to_haiku_lines(message)
def print_haiku(haiku: Tuple[str, str, str]):
for line in haiku:
print(line)
def parse_args():
parser = argparse.ArgumentParser(description='コミットメッセージを俳句(五・七・五)に変換します。')
parser.add_argument('--message', '-m', type=str, help='変換したいコミットメッセージ')
parser.add_argument('--file', '-f', type=str, help='コミットメッセージを含むファイルパス')
parser.add_argument('--random', action='store_true', help='完全ランダムな俳句を生成')
parser.add_argument('--list-season', action='store_true', help='利用可能な季語一覧を表示')
parser.add_argument('--test', action='store_true', help='テストモード(例文で出力)')
return parser.parse_args()
def main():
args = parse_args()
if args.list_season:
print("\n".join(SEASON_WORDS))
sys.exit(0)
if args.random:
haiku = (
random.choice(SEASON_WORDS),
random.choice(SEASON_WORDS),
random.choice(SEASON_WORDS)
)
print_haiku(haiku)
sys.exit(0)
if args.test:
samples = [
"バグ修正とテスト追加",
"READMEを更新しました",
"仕様変更に対応",
"ドキュメント整備"
]
for msg in samples:
print(f"\n[元メッセージ] {msg}")
haiku = generate_haiku_from_message(msg)
print_haiku(haiku)
sys.exit(0)
message = None
if args.message:
message = args.message
elif args.file:
try:
with open(args.file, encoding='utf-8') as f:
message = f.read()
except Exception as e:
print(f"ファイル読み込みエラー: {e}")
sys.exit(1)
else:
print("--message または --file を指定してください。--help で使い方を確認できます。")
sys.exit(1)
haiku = generate_haiku_from_message(message)
print_haiku(haiku)
if __name__ == '__main__':
main()
references/design_notes.md
# 概要
commit-haiku-generatorは、コミットメッセージを五・七・五の俳句形式に変換するためのジョークSkillです。開発現場に文学的な遊び心を持ち込み、コミット履歴をユニークなものにします。
# 公式ドキュメント抜粋
- [Wikipedia: 俳句](https://ja.wikipedia.org/wiki/%E4%BF%B3%E5%8F%A5)
- Python標準ライブラリ: argparse, re, random, unicodedata
# 利用例
- 通常のコミット前に `python commit_haiku_generator.py --message "バグ修正"` で一句生成
- チームの朝会やリリースノート用にランダム俳句を出力
# 注意点
- 生成される俳句の意味や文法は保証されません
- 重大なリリースや厳密な履歴管理には不向きです
- 巨大なdiffやバイナリファイルには適用しません
# 設計方針
- ひらがな・カタカナ・漢字の音節数を近似的にカウントし、五・七・五に分割
- 季語リストで不足分を補完し、和風の雰囲気を強調
- CLIツールとして汎用的に利用可能な設計
導入手順
このSkillは GitHub で管理されているので、degit を使えば必要なフォルダだけを1コマンドで取得できます。Codex はファイル配置後に再起動するだけで自動認識します。
1. 前提
- Node.js v16 以上 (
degit実行に必要) - Codex がローカルで動いていること
2. degit でフォルダ取得
プロジェクトのルートで以下のコマンドを実行します。
npx degit aazutaku/ai-note/codex/commit-haiku-generator .agents/skills/commit-haiku-generator
.agents/skills/commit-haiku-generator の中に SKILL.md / scripts/ / references/ / README.md が展開されます。
3. ファイル配置確認
ls .agents/skills/commit-haiku-generator
# SKILL.md, scripts/, references/, README.md があればOK
4. Codex を再起動 (or Skill 自動検出を待つ)
新しいSkillが自動で認識されます。リスト確認したい場合は /skills menu or $skill-name mention と Skill 名で出てきます。
5. 動作確認
/skills menu or $skill-name mention で呼び出すか、自然言語で発動条件にマッチする指示を出すと Skill が動きます。期待される出力イメージは「実行したらこうなる」セクションを参照してください。
こんな瞬間に便利
- session 開始時: 前回までの repo 把握を Codex に一発で復元させたい
- monorepo 移動時: packages を跨いだ瞬間に context を切り替えたい
- onboarding 時: 新しい repo を Codex に把握させ、こちらが path を全部指定する手間を省きたい
- session 再開時: long context が切れた後でも、必要な path と directory 構造だけ素早く戻したい
- package 跨ぎ作業時: directory boundary を Skill 側で管理して、irrelevant な path 混入を防ぎたい
- long-running workflow 前: long context で重要箇所が薄まる前に snapshot を取りたい
気になるポイント (壊れそうな箇所)
実運用に乗せる前に頭に入れておきたい懸念。後で検証する観点でもある:
- stale context 問題: 長時間 workflow で Skill 出力が古くなり、現状と乖離する可能性
- directory 増えすぎ問題: 大規模 repo で全 directory を網羅すると出力が肥大化して context window を圧迫
- monorepo 肥大化: packages が多い構成では出力が雑になり、結局 path 指定し直しになる懸念
- irrelevant path 混入: node_modules / build 成果物 / generated コードを拾ってしまう可能性
- Codex 固有の引っかかり: description のセマンティックマッチ精度が要件次第
- 発動しないケース: description が漠然 / 他の Skill が優先 / git管理外 directory
試す前に確かめたいこと
この Skill を実運用に投入する前に確かめたい問いを並べる:
- 実 repo での token 消費は許容範囲か?
- monorepo (packages 多数) で安定して動くか?
- stale context にならず、長時間 workflow でも有効か?
- AGENTS.md との連携設計はどうあるべきか?
- 五・七・五のリズムになっているか、変換の破綻やエラーが出ないか、コミット作業の邪魔にならないか
実際に Codex で試した検証ログは Codexでコミットメッセージを俳句に変換してみた!和の心で癒される開発体験 にまとめる予定 (公開準備中の場合あり)。
あわせて Codex 公式ドキュメント と、本シリーズ「Codexを使いこなすSkillアイデア」の他記事も参照のこと。
関連タグで他のSkill記事を探す
本記事に付いているタグから、気になるテーマの記事を探せます。タグページで関連記事をまとめて読めるので、ぜひチェックしてみてください!
