lov-skill-distiller

Skill Alchemist · Skill 炼金师

This is not about broadly searching for opportunities, but about distilling work that has already happened into a stable, portable, and acceptable capability contract. The final artifact is a Skill blueprint: it is sufficient to hand over to lov-skill-creator to implement, yet does not leak personal names, project codenames, private paths, keys, or chat context.

Triggers

Activate when

The user says "distill this experience into a Skill", "capture Yoda's approach", or "turn this retrospective into a reusable capability".
The user provides project history, incident retrospectives, consecutive requirements, or real deliveries, and wants to extract a reusable Skill from them.
Use this when the user says “distill experience into a skill”, “turn this workflow into a reusable skill”, or “skill distillation”.

Do not activate when

The user has clearly decided to implement a particular Skill: hand over to lov-skill-creator。
The user wants to optimize, revise, or upgrade an existing Skill: hand over to lov-skill-optimizer。
The user only wants to save a project convention into the system prompt or project documentation: hand over to lov-distill-to-system。

Workflow (MANDATORY)

Step 0: Select the experience unit to distill

Use a complete "problem → judgment → action → verification" loop as the unit. Prefer experience that has gone through real execution, release, installation, or user acceptance; single flashes of inspiration, purely technical interests, or content containing only internal context are not yet promoted to a Skill.

Keep personal names, customer information, project codenames, private paths, access credentials, and temporary chat details in the evidence layer; by default they do not enter the blueprint's name, description, or examples.

Step 1: Collect raw evidence (supporting, not the main artifact)

Create a reviewable evidence summary for the repository or materials:

python3 "$SKILL_DIR/scripts/collect-source-evidence.py" PROJECT_PATH \
  --output skill-distillation-evidence.md

Git history is only a clue. Supplement it with retrospectives, acceptance records, failure logs, and behavior changes provided by the user; judgments without evidence support must be marked as assumptions.

Step 2: Distill invariants

Use the distillation lensto extract from the raw materials:

the outcome the user truly wants to achieve, rather than internal implementation actions;
the stable judgment order: which steps always hold, and which are configurable variants;
failure recovery and acceptance: how to know it "really succeeded", rather than only seeing a prompt, compilation, or static check;
boundaries: which inputs do not apply, and which logic, data, or credentials need to be kept as private configuration;
the minimal reusable unit: whether it should be a Single Skill, a Skill with deterministic scripts, or a Skill Kit composed of independent stages.

Do not copy one-off actions verbatim into a Skill; merge different channels, models, project paths, or tool implementations under the same user outcome.

Step 3: Write the Skill blueprint

Deliver a Chinese blueprint according to the Skill blueprint template . Each blueprint must include:

a user-facing name and a one-sentence promise;
trigger phrases and at least one explicit non-trigger scenario;
inputs, outputs, core flow, and configurable items;
real acceptance signals, common failures, and recovery paths;
the private-information boundary;
one or more traceable evidence summaries.

If there are multiple experience units, decide whether to merge or split based on "whether the same result shares context and acceptance"; recommend at most 3–7 blueprints.

Step 4: Make the promotion decision

Give each blueprint one conclusion:

Create: user result, boundary, acceptance, and evidence are all clear;
Continue distilling: lacks real acceptance, core judgment, or portable boundaries;
Merge: it is merely another channel/parameter/stage and should not become an independent Skill;
Archive: it can only serve a one-off project context; keep it as project documentation.

Use promotion check to explain the reason. Scores are only used to assist ranking; the conclusion is based on deliverability.

Step 5: Hand off for implementation

After the user selects the blueprints to "create", hand them to lov-skill-creator: it is responsible for implementation, validation, and local installation. When the user requests publishing, hand them to lov-skill-publisher。

Dependencies

Python 3.8+ (standard library only)
Git (optional, used for repository history evidence)

Runtime context

Before running, read the same-directory skill.yaml, injected by the host's skill-runtime in the order of "current request, project context, personal configuration, brand Profile, security defaults", using only the fields declared in the manifest.

When the required: true field is missing, follow questions to ask the user one focused question; the answer is used only for this run unless the user explicitly requests it to be saved.
Profile is used only for public brand facts; personal configuration is used only for decisions and is not automatically written to artifacts or source code.
For debugging errors, provide a copyable context_id, field path, and source; do not output secrets, full private paths, or raw content.

Runtime context (shared)

Before running, read this Skill package's skill.yaml, and the host provides the skill-runtime/v1 context. The field resolution order is: current request, project context, personal Preferences, brand Profile, general defaults.

Use only the fields declared in the Manifest; Profile stores public brand facts, and Preferences stores personal work preferences.
required: true When the field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
For errors, provide a copyable context_id, field path, and source; diagnostic content must avoid secrets, full private paths, and raw configuration.

General feedback loop

When the user raises change requests during a Skill-driven task, the following must be executed before continuing with the current artifact:

First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
task-specific Modify only the current task, not the Skill.
reusable First determine the scope: for domain rules, update the corresponding canonical Skill first; for rules that apply to all Skills, update the shared specification first.
After completing rule updates, versioning, lint, and distribution verification, then apply the changes to the current task.
reusable A modification invalidates previous "confirm", "continue", and "send it" responses; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, committing, or other external writes.