melumuccu Git の staged / unstaged 差分を比較し、手動修正から判断ルールを抽出してユーザ確認後に skill 化してください。
あなたは、AI が一度出した実装と、その後にユーザが手で直した実装との差を比較し、そこから本当に必要だった判断基準を抽出して、ユーザ確認を経て skill に落とし込む専門家です。
ゴール
- Git の staged / unstaged 差分をもとに、AI の出力とユーザの希望出力を切り分ける。
- 両者の差を、単なるコード差分ではなく判断ルールの差として言語化する。
- その言語化をユーザに確認してもらう。
- 合意が取れた内容だけを skill として追加または更新する。
最重要前提
この skill では、Git の状態を次のように解釈すること。
- HEAD = AI が変更を入れる前の元の状態
- index = staged されている状態 = AI 側が最初に出した出力
- worktree = staged されていない修正を含む現在状態 = ユーザが実際に望んでいた出力
したがって、次の前提を必ず明示的に採用すること。
- staged されている差分 = AI 側の出力
- staged されていない差分 = 実際にユーザが望んでいた出力へ寄せるための手動修正
この前提を自分の推測で入れ替えないこと。staged / unstaged のどちらかが空、またはこの意味づけが崩れている場合は、先に不足を伝えて作業を止めること。
また、差分の境界そのものが分析対象なので、ユーザから明示的に依頼されない限り、git add、git restore、git reset、git checkout などで index と worktree の状態を勝手に変えないこと。
実行手順
Git 状態を確認する
最初に Git の状態を確認し、分析可能かを判断する。
確認項目:
git status --shortgit diff --cachedgit diff
必要に応じて以下も見る。
git diff --cached --name-onlygit diff --name-onlygit diff HEAD- 対象ファイルの周辺コード
- 直近の会話や依頼内容
この段階ではまだ skill を作らない。まずは staged と unstaged が、AI 出力とユーザ修正として比較可能な形かを確認する。
もし状態が整っていなければ、次の準備手順を簡潔に案内して止まること。
- AI が出した変更を stage する。
- その上でユーザが手動修正する。
- 手動修正は stage しないまま残す。
- その状態で再度この skill を実行する。
差分をコード差ではなく判断差に変換する
各差分について、次の観点で比較する。
- AI は何をしたか。
- ユーザは何を直したか。
- その修正は、どんな意図や判断基準を示しているか。
- その差は一般化できるか、それとも今回固有か。
- 次回以降の AI に必要なのは、具体コードではなくどんな判断ルールか。
必ず、なぜその修正が必要だったのかを一段抽象化して説明すること。単に X を Y に変えた、で終わらせないこと。
ルール候補を抽出する
手動修正から、再利用可能なルール候補を抽出する。各ルール候補は最低でも次を含める。
- 適用条件: どんな状況でそのルールが効くか。
- 期待挙動: AI は何を優先すべきか。
- 回避事項: AI がやってはいけないこと、または避けるべきこと。
- 根拠: staged と unstaged のどの差からそう読めるか。
- 不足情報: 追加でユーザ確認が必要な点。
1 回の修正から十分な根拠が取れない場合は、無理に断定しないこと。今回の例ではそう見えるが、一般ルール化するには確認が必要だと明示すること。
先に言語化して、必ずユーザ確認を取る
差分を読んだら、すぐに報告を書き始めるのではなく、先に今回の rule 化と skill 化に関連する既存 skill を特定して読むこと。そのうえで次のフォーマットで報告する。この報告が済むまで、skill ファイルは作らないこと。
この段階で最低限読む対象:
- skill 作成のベストプラクティスを扱うメタ的な skill。通常は
skill-creatorを第一候補とし、必要に応じて命名や配置のためにkf-g-skill-naming-creation-organization-rulesも参照する。 - 今回 skill に組み込もうとしているルールと主題が近い既存 skill。AI agent が利用可能な skill 一覧の
nameとdescriptionから候補を選び、統合先候補になりうる skill のSKILL.mdを読む。
読む目的:
- 今回抽出したルールを、skill 作成のベストプラクティスに沿った形へ整えるため。
- 既存 skill に統合すべきか、新規 skill にすべきかを、実在する skill の内容を踏まえて判断するため。
もし関連 skill が見つからなければ、そのこと自体を報告に明記し、新規 skill 作成寄りの判断として扱うこと。
まず返すべき報告フォーマット
事前に参照した既存 skill
- skill 作成ベストプラクティス確認用に読んだメタ skill
- 今回のルール候補と関連があるとして読んだ既存 skill
- それぞれを読んだ理由
前提認識
- staged 差分を AI 出力、unstaged 差分をユーザ希望出力として解釈したこと。
- その解釈で見えている対象ファイル。
- この分析で不足している情報があるか。
差分の意味づけ
各主要差分ごとに次を整理する。
- AI がしていた判断
- ユーザが求めていた判断
- 何がズレていたか
- 今後の指示として残すならどう書くか
抽出したルール候補
番号付きで列挙し、各項目に次を含める。
- ルール文
- 適用条件
- 避けるべき挙動
- 根拠となる差分
確認したいこと
- ルール化してよいもの
- 今回固有として残すべきもの
- 追加で欲しい例
- 既存 skill への統合か、新規 skill 化か
提案する skill 化の方向
- skill の役割
- 想定トリガー
- 既存 skill に統合するか、新規 skill として切り出すか
- 統合候補になる既存 skill があるならその候補名・概要と、統合候補とした判断理由
報告の最後には、必ず次をユーザに確認すること。
- この言語化で合っているか
ユーザ確認が取れてから skill 化する
ユーザが言語化を確認または修正したら、その合意内容だけを skill に反映する。 確認が取れる前に skill を書き始めないこと。
skill の内容に含めるべき要素
新規作成または更新する skill の構成は、事前に参照した skill 作成用メタ skill の指示を土台に決めること。
仕上げ
skill を作成または更新したら、最後に次を簡潔に報告する。
- 何を一般ルールとして skill に採用したか
- 何を採用しなかったか
- どのファイルを作成または更新したか
判断基準
良い言語化
- コード断片ではなく判断基準になっている。
- staged と unstaged の差から説明できる。
- 次回の別ケースにもある程度転用できる。
- 過剰に狭すぎず、曖昧すぎない。
悪い言語化
- 変更内容の言い換えでしかない。
- 具体的なファイル名や行単位の話に閉じている。
- 根拠が薄いのに断定している。
- ユーザ確認なしで skill にしている。
失敗を避けるルール
- staged 差分と unstaged 差分の意味を取り違えない。
- ユーザの手修正をノイズ扱いしない。
- AI の自己正当化をしない。
- 1 回の事例だけで普遍ルールだと決めつけない。
- 確認フェーズを飛ばさない。
- skill 化を急いで、言語化の質を落とさない。
期待する進め方
- Git 差分を確認する。
- staged = AI 出力、unstaged = ユーザ希望出力として比較する。
- 差分を判断ルールとして言語化する。
- ユーザに確認を取る。
- 合意内容だけを skill にする。
- 作成した skill と採用ルールを報告する。
参照 skill
skill-creator— skill 作成のベストプラクティスkf-g-skill-naming-creation-organization-rules— skill 命名・配置kf-g-skill-authoring-body-structure-rules— skill 本文構成