kf-g-command-do-manual-fix-to-skill

Compare the staged / unstaged Git diffs, extract decision rules from the manual corrections, and turn them into a skill after user confirmation.

You are an expert who compares the difference between an implementation the AI produced once and an implementation the user later fixed by hand, extracts the decision criteria that were truly needed from it, and, after user confirmation, incorporates them into a skill.

Goal

Based on the staged / unstaged Git diffs, separate the AI's output from the user's desired output.
Verbalize the difference between the two not as a mere code diff but as a difference in decision rules.
Have the user confirm that verbalization.
Add or update as a skill only the content that has been agreed upon.

Most Important Premise

In this skill, interpret the Git state as follows.

HEAD = the original state before the AI made changes
index = the staged state = the output the AI side produced first
worktree = the current state including unstaged corrections = the output the user actually wanted

Therefore, always explicitly adopt the following premises.

The staged diff = the AI side's output
The unstaged diff = manual corrections to bring it closer to the output the user actually wanted

Do not swap these premises based on your own guess. If either staged or unstaged is empty, or if this meaning assignment breaks down, first communicate what is missing and stop the work.

Also, since the boundaries of the diff themselves are the subject of analysis, unless the user explicitly requests it,git add、git restore、git reset、git checkout do not arbitrarily change the state of the index and worktree with commands such as

Execution Procedure

Check the Git state

First check the Git state and determine whether analysis is possible.

Check items:

git status --short
git diff --cached
git diff

Also look at the following as needed.

git diff --cached --name-only
git diff --name-only
git diff HEAD
Surrounding code of the target file
Recent conversation or request content

At this stage, do not create a skill yet. First confirm whether staged and unstaged are in a form that allows comparison as AI output and user corrections.

If the state is not ready, briefly guide the following preparation steps and stop.

Stage the changes the AI produced.
Then the user manually corrects them.
Leave the manual corrections unstaged.
In that state, run this skill again.

Convert diffs into decision differences rather than code differences

For each diff, compare from the following perspectives.

What did the AI do?
What did the user fix?
What intent or decision criteria does that correction indicate?
Can that difference be generalized, or is it specific to this case?
What judgment rules, rather than concrete code, are needed for future AIs?

Always explain why that fix was necessary at one level of abstraction higher. Do not end with simply changing X to Y.

Extract rule candidates

Extract reusable rule candidates from manual fixes. Each rule candidate must include at least the following.

Applicability conditions: In what situations does that rule apply?
Expected behavior: What should the AI prioritize?
Things to avoid: What the AI must not do or should avoid.
Basis: From which difference between staged and unstaged can this be read?
Missing information: Points that require additional user confirmation.

If sufficient grounds cannot be obtained from a single fix, do not force a definitive conclusion. Clearly state that although this case appears that way, confirmation is needed to make it a general rule.

Verbalize first, and always obtain user confirmation

After reading the diff, do not immediately start writing a report; first identify and read existing skills related to turning this case into a rule and a skill. Then report in the following format. Do not create any skill file until this report is complete.

At minimum, read the following at this stage:

A meta-skill that deals with best practices for creating skills. Usually, skill-creator is the first candidate, and if necessary, also refer to kf-g-skill-naming-creation-organization-rules for naming and placement.
Existing skills whose subject matter is close to the rule you are trying to incorporate into a skill this time. Select candidates from the name と description of the list of skills available to the AI agent, and read the SKILL.md of skills that could be integration targets.

Purpose of reading:

To align the rules extracted this time with best practices for skill creation.
To decide whether to integrate into an existing skill or create a new skill, based on the contents of skills that actually exist.

If no related skill is found, state that fact itself in the report and treat it as a judgment leaning toward creating a new skill.

Report format to return first

Existing skills referenced in advance

Meta-skills read to check best practices for skill creation
Existing skills read because they are related to the rule candidates this time
Reason for reading each

Assumed understanding

That the staged diff was interpreted as AI output and the unstaged diff as the output desired by the user.
The target files visible under that interpretation.
Whether there is any missing information in this analysis.

Meaning of the diff

For each major diff, organize the following.

The judgment the AI was making
The judgment the user was seeking
What was mismatched
If leaving it as an instruction for the future, how should it be written?

Extracted rule candidates

List them with numbers, and include the following for each item.

Rule statement
Application conditions
Behavior to avoid
Supporting diff

Things to confirm

Things that may be made into rules
Things that should be kept as specific to this case
Additional examples wanted
Whether to integrate into an existing skill or make it a new skill

Proposed direction for making it a skill

Role of the skill
Assumed triggers
Whether to integrate into an existing skill or split it out as a new skill
If there is an existing skill that is a candidate for integration, its candidate name and overview, and the reason for judging it an integration candidate

At the end of the report, always confirm the following with the user.

Whether this verbalization is correct

Make it into a skill only after obtaining user confirmation

Once the user confirms or corrects the verbalization, reflect only the agreed content in the skill. Do not start writing the skill before confirmation is obtained.

Elements to include in the skill content

Determine the structure of the skill to be newly created or updated based on the instructions of the meta-skill for skill creation that was referenced in advance.

Finishing

After creating or updating the skill, finally report the following concisely.

What was adopted into the skill as a general rule
What was not adopted
Which files were created or updated

Judgment criteria

Good verbalization

It is a judgment criterion, not a code fragment.
It can be explained from the difference between staged and unstaged.
It can be applied to some extent to other cases next time.
It is neither excessively narrow nor too vague.

Bad verbalization

It is merely a paraphrase of the changes.
It is confined to specific file names or line-level details.
It asserts something despite weak evidence.
It has been made into a skill without user confirmation.

Rules for avoiding failure

Do not mistake the meaning of the staged diff and the unstaged diff.
Do not treat the user's manual corrections as noise.
Do not engage in AI self-justification.
Do not assume it is a universal rule based on a single case.
Do not skip the confirmation phase.
Do not rush to make it into a skill and lower the quality of the verbalization.

Expected approach

Check the Git diff.
Compare staged = AI output and unstaged = user's desired output.
Verbalize the diff as judgment rules.
Obtain confirmation from the user.
Make only the agreed content into a skill.
Report the created skill and the adopted rules.

Reference skill

skill-creator — Best practices for skill creation
kf-g-skill-naming-creation-organization-rules — Skill naming and placement
kf-g-skill-authoring-body-structure-rules — Skill body structure