メニュー
Conventional Commitsに従ったアトミックなgitコミットを作成する。変更を論理単位に分割し、独立してrevert可能なコミットを生成する。コードの変更をコミットしたいとき、コミットメッセージを作りたいときに使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | commit-creator |
| description | Conventional Commitsに従ったアトミックなgitコミットを作成する。変更を論理単位に分割し、独立してrevert可能なコミットを生成する。コードの変更をコミットしたいとき、コミットメッセージを作りたいときに使用する。 |
独立してrevert可能なアトミックコミットを、Conventional Commits仕様に従って作成する。
git status と git diff で変更を確認するgit log --oneline -20 で既存のコミットパターン（構造、スコープ命名、メッセージスタイル、言語）を確認するgit diff <file> で対象hunkを確認するgit apply -v でパッチを適用するgit add <file> でステージするgit show HEAD で確認するgit add -p や git add --interactive は使用不可。 Claude Codeは対話的コマンドに対応していない。
# 適用前に必ず検証する
git apply --check patch.patch
# 適用（常に-vをつける）
git apply -v patch.patch
# ホワイトスペース問題がある場合
git apply --whitespace=fix -v patch.patch
# 部分的に失敗する場合
git apply --reject -v patch.patch
<type>(<scope>): <subject>
<body>
type: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
body: コミット前後の差分がわかるように書く。何が変わったか、なぜ変えたかを後から見返せる形で記述する。72文字で折り返す。
禁止: ユーザーの指示をそのままコミットメッセージに転記しない。「〜してください」「〜を修正して」などの依頼文をメッセージにしない。変更の事実と理由を客観的に記述する。
git log を確認し、直近のコミットが日本語なら日本語、そうでなければ英語で書く#123 形式で書くowner/repo#123 をコミットメッセージに書かない。GitHubがクロスリファレンス（被リンク）を相手リポジトリに残してしまうため。どうしても言及が必要な場合はバッククォートで囲み（例: `owner/repo#123`、URLもインラインコード化）オートリンクを無効化するcmuxターミナル内での操作スキル。CMUX_*環境変数が存在する場合、cmuxのCLIコマンドを使う前に必ずこのスキルを読む。ペイン分割、コマンド送信、ブラウザ自動化、通知、Markdown/diffのプレビュー、cmux設定の変更など、cmux操作全般で使用する。「別ペインで開いて」「横に表示して」「ブラウザで確認して」「プレビューして」「diffを見せて」などのときにも使用する。
Preview generated Markdown (plans, design notes, reviews, research reports) in the user's browser. Use when sharing long, structured output — documents with headings, tables, code blocks, or Mermaid diagrams — that is hard to read in the terminal.
バグを場当たり修正せず、根本原因を特定してから直すためのデバッグ手順。再現→切り分け→根本原因→検証の順で進める。バグ・デバッグ・原因不明・落ちる・再現しない・CIが赤・flakyなテスト・想定外の挙動に遭遇したときに使用する。「デバッグして」「なぜ落ちる」「原因を調べて」などのときにも使用する。
「完了」「直した」と報告する前に、実際に実行・テスト・観察して根拠を確かめるための検証ルール。修正・実装・リファクタが終わって成功を報告しようとするとき、変更が意図どおり動くと主張する前に使用する。「できた」「直した」「実装した」「修正完了」と言おうとしているときに使用する。
日本語の技術文書を書いた後・公開前にレビューし、重要度つきの指摘レポートを出すスキル（ファイルは変更しない）。日本語の文章品質・AI Slop・表記の慣習・整合性・独自性・語り口を点検する。媒体非依存の汎用版で、ブログMDXなどプロジェクト固有のレビュースキルがあればそちらを優先・併用する。
新しい k8o プロジェクト/リポジトリを立ち上げる一連の手順。@k8o/create で雛形生成 → GitHub リポジトリ作成 → ブランチ保護 ruleset とマージ設定 → リリース用 secret(fnox経由) → npm 初回 publish と Renovate 有効化まで。「新しい repo を作る」「プロジェクトを立ち上げる」「リポジトリの初期設定をする」ときに使用する。