一键导入
git-commit
Claudeがgitコミットを実行するためのスキル。「コミットして」「git commitして」「変更を記録して」などの指示があった場合、または作業の区切りでコミットが必要な場面で必ずこのスキルを使う。コミットメッセージの生成・stagingの選択・gitコマンドの実行まで一貫して担う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Claudeがgitコミットを実行するためのスキル。「コミットして」「git commitして」「変更を記録して」などの指示があった場合、または作業の区切りでコミットが必要な場面で必ずこのスキルを使う。コミットメッセージの生成・stagingの選択・gitコマンドの実行まで一貫して担う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
完成した記事の下書きを推敲・校正し、公開できる状態に仕上げる。 ユーザーが「推敲して」「校正して」「読み直して」「チェックして」「仕上げて」と言ったとき、 またはidea-pipeline:writeの出力を受け取って最終確認するときに使う。 これはidea-pipelineの第4工程(推敲)であり、最終工程。
校正済みの完成記事(note/Zenn)をもとに、その告知・要約となるThreads投稿用の文章を作成する。 ユーザーが「Threadsの投稿文を考えて」「スレッズ用に書いて」「Threadsに投稿したい」と言ったとき、 またはidea-pipeline:reviewで記事が完成した後にSNS投稿にしたい場面で使う。 idea-pipelineの4工程(extract→structure→write→review)が完了した後に実行する追加工程。
校正済みの完成記事(note/Zenn)をもとに、その告知・要約となるX(旧Twitter)投稿用の文章を作成する。 ユーザーが「Xの投稿文を考えて」「ツイート案を作って」「Xに投稿したい」と言ったとき、 またはidea-pipeline:reviewで記事が完成した後にSNS投稿にしたい場面で使う。 idea-pipelineの4工程(extract→structure→write→review)が完了した後に実行する追加工程。
AIとの会話ログから、記事として発信する価値のある核心的なアイデア・気づき・主張を抽出・整理する。 ユーザーが会話ログを貼り付けたとき、「記事にしたい」「まとめたい」「要点を出して」と言ったとき、 またはアイデアを記事化したいと示唆する発言があったときは、必ずこのスキルを使え。 他のidea-pipelineスキルより先に実行する第1工程。
抽出済みのアイデア・要点をもとに、note/Zenn記事の構成(見出し・骨格)を作る。 ユーザーが「構成を作って」「アウトラインを作って」「記事の骨格を考えて」と言ったとき、 またはidea-pipeline:extractの出力を受け取って次に進む場面では必ずこのスキルを使え。 これはidea-pipelineの第2工程。第1工程(extract)の後に実行する。
確定した記事構成をもとに、note/Zennの本文を見出しごとに執筆する。 ユーザーが「本文を書いて」「記事を書いて」「執筆して」「この構成で書いて」と言ったとき、 またはidea-pipeline:structureの出力を受け取って次に進む場面では必ずこのスキルを使え。 これはidea-pipelineの第3工程。第2工程(structure)の後に実行する。
| name | git-commit |
| description | Claudeがgitコミットを実行するためのスキル。「コミットして」「git commitして」「変更を記録して」などの指示があった場合、または作業の区切りでコミットが必要な場面で必ずこのスキルを使う。コミットメッセージの生成・stagingの選択・gitコマンドの実行まで一貫して担う。 |
type: 何をしたか(体言止め)
なぜそうしたか。ユーザーから得た文脈をそのまま使う。
typeはConventional Commitsに従う:feat / fix / docs / style / refactor / test / chore / perf / revert
理由がない・自明な場合は1行目だけでよい。
良い例:
feat: ユーザー認証画面を追加
ログイン機能の実装に必要なため。
style: コードフォーマットを適用
悪い例: fix bug(内容不明)、いろいろ修正(粒度大きすぎ)、WIP(意味なし)
git status && git diff
git add . は使わない。意味のあるまとまりを意識してファイル単位またはハンク単位で選ぶ。
git add <file> # ファイル単位
git add -p <file> # ハンク単位(1ファイルに複数の意図が混在する場合)
バイナリ(画像等)はテキストと別コミットにする。Gitはバイナリの差分管理が苦手なため。
git commit -m "style: フォーマットを適用"
git commit -m $'feat: 〇〇を追加\n\n△△のため。' # 複数行の場合
git log --oneline -5
typoや修正忘れなど「直前のコミットの続き」に見える変更は、新しいコミットを作らず吸収させる。独立した意図があるかどうかで判断する。
直前のコミットに吸収(push前のみ):
git add <file>
git commit --amend --no-edit
数コミット前に吸収(push前のみ):
# 1. 対象コミットのハッシュを確認
git log --oneline -5
# 2. fixupコミットを作成(対象ハッシュを指定)
git commit --fixup=<commit-hash>
# 3. 非インタラクティブでautosquash
GIT_SEQUENCE_EDITOR=true git rebase --autosquash HEAD~N
push済みのコミットには使わない。履歴の書き換えは他の人の環境と衝突するため。
自動判断せず、ユーザーに確認してから進む場面: