Codex ユーザーが日常でぶつかる悩み
開発現場でPull Requestを作るたび、タイトルを考えるのがちょっとしたストレスになることは珍しくありません。特にチームで使う場合、CodexのAI coding workflowの中で「PRタイトルどうする?」問題は地味に面倒なタスクです。ジョーク・パロディ枠のSkillを活用したい人に向けて、以下のような「あるある」な困りごとが挙げられます。
- 毎回PRタイトルに悩み、結局「fix: typo」や「update: refactor」など味気ない表現になりがち
- 真面目なタイトルばかりだと、repoのonboardingやレビュー時に空気が重くなりやすい
- monorepoで複数directoryを管理していると、どのpackageのPRかタイトルでわかりづらくなる
- 長時間のAI coding workflowでcontextが膨らみすぎ、タイトル付けのテンションが下がる
- たまにはエンタメ要素でチームに祭り感や話題を持ち込みたいのに、仕組みがない
この Skill が一言でいうと何を解決するか
一言サマリ: PRのタイトルSkill。
このSkillは、Pull Request作成時にタイトルを“おみくじ”風に自動変換し、開発現場にユーモアと一体感をもたらします。具体的なメリットは以下の通りです。
- PR提出時、タイトルを考える手間がゼロになり、AI coding workflowがテンポよく進む
- 毎回異なる運勢ワードで、repoやdirectory単位の作業にも話題性をプラス
- onboarding時や長時間セッションでも、Skillが自動でタイトルを盛り上げてくれる
- monorepo環境でも、packageを跨いだ作業が楽しくなり、contextの切り替えも印象的に
- チームのmemoryに残るユニークなPRタイトルで、開発体験がエンタメ化する
GitHub から degit でコマンド1行、Codex の Skill ディレクトリに展開できます。Node.js があれば即時に動きます。
npx degit aazutaku/ai-note/codex/pr-title-omikuji .agents/skills/pr-title-omikuji実行したらこうなる (3つの利用シーン)
Skillを導入すると、PRタイトルが自動で“おみくじ”風に変換され、開発体験が一変します。以下、3つの典型的な利用シーンを擬似terminal出力で紹介します。
シーン1: session 開始時(プロジェクト初動で)
# /skills menu
> PR作成: src/utils/arrayHelpers.js のリファクタ
[pr-title-omikuji] PRタイトルをおみくじ風に変換します…
→ 大吉:運命のリファクタリング
(元タイトル: src/utils/arrayHelpers.js のリファクタ)
Pull Request が作成されました。
シーン2: monorepo / package 跨ぎ作業時
> PR作成: packages/user-service/validator.js のバグ修正
[pr-title-omikuji] PRタイトルをおみくじ風に変換します…
→ 小吉:軽い修正だけど運は微妙
(元タイトル: packages/user-service/validator.js のバグ修正)
Pull Request が作成されました。
シーン3: お遊び的な使い方
> PR作成: README.md のリンク修正
[pr-title-omikuji] PRタイトルをおみくじ風に変換します…
→ 末吉:ひとまずリンクは繋がる予感
(元タイトル: README.md のリンク修正)
Pull Request が作成されました。
before / after の違い
| 場面 | Skill 無し | Skill 有り |
|---|---|---|
| session 再開時 | repo 構造から毎回説明、path も指定し直し | Codex が自動で context を復元、最小プロンプトで再開 |
| monorepo 移動 | 違う package のコードを参照しがち | directory boundary を意識して必要な範囲だけ見る |
| 長時間 workflow | long context で重要箇所が薄まる | タイトルに遊び要素を加えて、重要なPRがチームの記憶に残りやすくなる |
発動方式
明示呼び出し (/skills menu or $skill-name mention) と暗黙発動 (descriptionマッチ) の両方に対応。
Skill の中身を全部見せる
.agents/skills/pr-title-omikuji/ に配置するファイル一覧です。GitHub に push 済みなので、上記の degit コマンドで一発取得できます。
.agents/skills/pr-title-omikuji/
├── SKILL.md
├── scripts/
│ └── pr_title_omikuji.py
└── references/
└── design_notes.md
各ファイルの役割
| ファイル | 役割 |
|---|---|
SKILL.md |
Skill本体。frontmatter (name/description) と指示本文。Codex がこの内容をエージェント指示として読み込み、ユーザーのプロンプトに応じて発動します |
scripts/pr_title_omikuji.py |
PRタイトルをおみくじ風に変換するツール |
references/design_notes.md |
概要 をまとめた参考資料 |
SKILL.md
---
name: pr-title-omikuji
description: CodexがPR作成やタイトル編集時、または/skills menuやpr-title-omikujiの明示呼び出し時に発動。PRタイトルを“おみくじ”風に自動変換し、運勢ワードを付与します。
---
# 機能概要
pr-title-omikujiは、Pull Request(PR)作成時やタイトル編集時に、PRタイトルを“おみくじ”形式へ自動変換するジョーク系Skillです。運勢(大吉・中吉・小吉・末吉・凶など)と、ユニークなコメントをタイトル先頭に付与し、開発現場の空気を一変させます。タイトル内容と運勢は無関係で、作業の真面目さに“運ゲー”要素を加え、レビューやマージの儀式をエンタメ化します。
# 使い方
- PR作成時やタイトル編集時に自動発動(always/semantic trigger)
- 明示的に `/skills menu` から選択、または `$pr-title-omikuji` で呼び出しも可能
- 暗黙発動キーワード例: "PR", "pull request", "タイトル", "title", "merge"
# 出力例
```
[大吉] 運命のリファクタリング: Fix typo in README
[小吉] 軽い修正だけど運は微妙: Update dependencies
[中吉] ちょっと良い感じ: Add new API endpoint
[末吉] まあまあの変更: Refactor user model
[凶] 波乱の予感: Hotfix for production bug
```
# 注意点
- タイトル内容はランダム運勢で上書きされます(元タイトルは末尾に残る)
- ローカル保存や履歴管理は行いません
- 機密情報のタイトルには注意
- 除外パスや特定ブランチは設定できません(要カスタマイズ)
# 参考資料
- references/design_notes.md に設計意図や運勢バリエーションの根拠を記載
- 公式GitHub API: https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28
scripts/pr_title_omikuji.py
import argparse
import random
import sys
import requests
import os
from typing import List, Dict, Optional
OMIKUJI_RESULTS = [
("大吉", "運命のリファクタリング"),
("中吉", "ちょっと良い感じ"),
("小吉", "軽い修正だけど運は微妙"),
("末吉", "まあまあの変更"),
("凶", "波乱の予感"),
("大凶", "全てを巻き込む混沌"),
("吉", "普通のアップデート"),
("半吉", "やや良し"),
("末小吉", "微妙な運勢"),
("平", "何も起きないかも"),
]
GITHUB_API_URL = "https://api.github.com"
def omikuji_title(original_title: str) -> str:
fortune, comment = random.choice(OMIKUJI_RESULTS)
return f"[{fortune}] {comment}: {original_title}"
def get_pr_info(owner: str, repo: str, pr_number: int, token: str) -> Dict:
url = f"{GITHUB_API_URL}/repos/{owner}/{repo}/pulls/{pr_number}"
headers = {"Authorization": f"token {token}", "Accept": "application/vnd.github+json"}
resp = requests.get(url, headers=headers)
resp.raise_for_status()
return resp.json()
def update_pr_title(owner: str, repo: str, pr_number: int, new_title: str, token: str) -> None:
url = f"{GITHUB_API_URL}/repos/{owner}/{repo}/pulls/{pr_number}"
headers = {"Authorization": f"token {token}", "Accept": "application/vnd.github+json"}
data = {"title": new_title}
resp = requests.patch(url, headers=headers, json=data)
resp.raise_for_status()
def list_omikuji_samples(n: int = 10, sample_title: str = "サンプルPRタイトル") -> List[str]:
results = []
for _ in range(n):
results.append(omikuji_title(sample_title))
return results
def parse_args():
parser = argparse.ArgumentParser(description="PRタイトルをおみくじ風に変換するツール")
subparsers = parser.add_subparsers(dest="command", required=True)
parser_run = subparsers.add_parser("run", help="指定のPRタイトルをおみくじ化してGitHubに反映")
parser_run.add_argument("--owner", required=True, help="GitHubリポジトリのオーナー名")
parser_run.add_argument("--repo", required=True, help="リポジトリ名")
parser_run.add_argument("--pr", type=int, required=True, help="PR番号")
parser_run.add_argument("--token", required=False, help="GitHubトークン(環境変数GITHUB_TOKENでも可)")
parser_run.add_argument("--dry-run", action="store_true", help="タイトル変更せず出力のみ")
parser_sample = subparsers.add_parser("sample", help="おみくじタイトルのサンプルを表示")
parser_sample.add_argument("--n", type=int, default=10, help="サンプル数")
parser_sample.add_argument("--title", default="サンプルPRタイトル", help="元タイトル")
return parser.parse_args()
def main():
args = parse_args()
if args.command == "sample":
samples = list_omikuji_samples(args.n, args.title)
for s in samples:
print(s)
return
elif args.command == "run":
token = args.token or os.environ.get("GITHUB_TOKEN")
if not token:
print("GitHubトークンが指定されていません。--token または GITHUB_TOKEN 環境変数を設定してください。", file=sys.stderr)
sys.exit(1)
try:
pr_info = get_pr_info(args.owner, args.repo, args.pr, token)
original_title = pr_info.get("title", "")
new_title = omikuji_title(original_title)
if args.dry_run:
print(f"新タイトル: {new_title}")
return
update_pr_title(args.owner, args.repo, args.pr, new_title, token)
print(f"PR #{args.pr} のタイトルを変更しました: {new_title}")
except requests.HTTPError as e:
print(f"APIエラー: {e}", file=sys.stderr)
sys.exit(1)
except Exception as ex:
print(f"エラー: {ex}", file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
main()
references/design_notes.md
# 概要
pr-title-omikujiは、開発現場に遊び心を持ち込むためのジョーク系Skillです。PRタイトルに“おみくじ”運勢とコメントを自動付与し、作業の雰囲気を和らげます。
# 公式ドキュメント抜粋
GitHub REST API v3のpullsエンドポイント(GET/PATCH)を利用し、タイトル取得・更新を安全に行います。
# 利用例
- PR作成時に自動でタイトルが「[大吉] 運命のリファクタリング: ...」などに変換される
- /skills menuや明示コマンドで任意タイミングで発動
- dry-runでタイトル変更前の確認も可能
# 注意点
- タイトルの運勢は完全ランダムで内容とは無関係です
- 機密情報や重要なPRには利用を控えることを推奨します
- トークン管理・APIレート制限に注意
# 設計方針
- ユーザー体験を損なわないよう、元タイトルは必ず末尾に残す
- 運勢ワードは10種以上を用意し、バリエーションを確保
- APIエラーやトークン未設定時は明確なエラーメッセージを返す
導入手順
このSkillは GitHub で管理されているので、degit を使えば必要なフォルダだけを1コマンドで取得できます。Codex はファイル配置後に再起動するだけで自動認識します。
1. 前提
- Node.js v16 以上 (
degit実行に必要) - Codex がローカルで動いていること
2. degit でフォルダ取得
プロジェクトのルートで以下のコマンドを実行します。
npx degit aazutaku/ai-note/codex/pr-title-omikuji .agents/skills/pr-title-omikuji
.agents/skills/pr-title-omikuji の中に SKILL.md / scripts/ / references/ / README.md が展開されます。
3. ファイル配置確認
ls .agents/skills/pr-title-omikuji
# 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 との連携設計はどうあるべきか?
- PR作成時に確実にタイトルが変換されるか
- 運勢ワードのバリエーションが十分あるか
- タイトル編集に支障が出ないか
実際に Codex で試した検証ログは CodexでPRタイトルをおみくじ風に変換してみた! にまとめる予定 (公開準備中の場合あり)。
あわせて Codex 公式ドキュメント と、本シリーズ「Codexを使いこなすSkillアイデア」の他記事も参照のこと。
関連タグで他のSkill記事を探す
本記事に付いているタグから、気になるテーマの記事を探せます。タグページで関連記事をまとめて読めるので、ぜひチェックしてみてください!
