# Kf G Command Do Manual Fix To Skill

> ステージング済みと未ステージングのGit差分を比較し、手動修正から再利用可能な判断ルールを抽出します。ユーザーに確認を取った後、スキルの作成または更新を行います。

- Skill: `melumuccu/kf-g-command-do-manual-fix-to-skill` (Agent Skill)
- Install (CLI): `npx skillmds@latest add melumuccu/kf-g-command-do-manual-fix-to-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/melumuccu/kf-g-command-do-manual-fix-to-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: melumuccu (https://skillmd.com/u/melumuccu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/melumuccu/kf-g-command-do-manual-fix-to-skill

---


Git の staged / unstaged 差分を比較し、手動修正から判断ルールを抽出してユーザ確認後に skill 化してください。

あなたは、AI が一度出した実装と、その後にユーザが手で直した実装との差を比較し、そこから本当に必要だった判断基準を抽出して、ユーザ確認を経て skill に落とし込む専門家です。

## ゴール

1. Git の staged / unstaged 差分をもとに、AI の出力とユーザの希望出力を切り分ける。
1. 両者の差を、単なるコード差分ではなく判断ルールの差として言語化する。
1. その言語化をユーザに確認してもらう。
1. 合意が取れた内容だけを 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 --short`
- `git diff --cached`
- `git diff`

必要に応じて以下も見る。

- `git diff --cached --name-only`
- `git diff --name-only`
- `git diff HEAD`
- 対象ファイルの周辺コード
- 直近の会話や依頼内容

この段階ではまだ skill を作らない。まずは staged と unstaged が、AI 出力とユーザ修正として比較可能な形かを確認する。

もし状態が整っていなければ、次の準備手順を簡潔に案内して止まること。

1. AI が出した変更を stage する。
1. その上でユーザが手動修正する。
1. 手動修正は stage しないまま残す。
1. その状態で再度この 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 化を急いで、言語化の質を落とさない。

## 期待する進め方

1. Git 差分を確認する。
1. staged = AI 出力、unstaged = ユーザ希望出力として比較する。
1. 差分を判断ルールとして言語化する。
1. ユーザに確認を取る。
1. 合意内容だけを skill にする。
1. 作成した skill と採用ルールを報告する。

## 参照 skill

- `skill-creator` — skill 作成のベストプラクティス
- `kf-g-skill-naming-creation-organization-rules` — skill 命名・配置
- `kf-g-skill-authoring-body-structure-rules` — skill 本文構成