sgc-skill-distiller

sgc-skill-distiller — Turn experience into a creatable Skill

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

Triggers

Activate when

• The user says "把这段经验蒸馏成 Skill", "把 Yoda 的做法沉淀下来", or "把这次复盘做成可复用能力".
• The user provides project history, incident retrospectives, continuous 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 certain Skill: hand to sgc-skill-creator。
• The user wants to optimize, revise, or upgrade an existing Skill: hand to sgc-skill-optimizer。
• The user only wants to save a project convention to the system prompt or project description: hand to sgc-distill-to-system。

Workflow (MANDATORY)

Step 0: Select the experience unit to be distilled

Use a complete "problem → judgment → action → verification" loop as the unit. Prioritize experience that has undergone real running, 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 names, customer information, project codenames, private paths, access credentials, and temporary chat details in the evidence layer, and by default do not include them in the blueprint's name, description, and examples.

Step 1: Collect raw evidence (auxiliary, not the main product)

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 user-provided retrospectives, acceptance records, failure logs, and behavior changes; judgments without evidence support must be marked as assumptions.

Step 2: Distill invariants

Use the distillation lensto extract from the raw materials:

1. The outcome the user truly wants to achieve, rather than the internal implementation actions;
2. A stable order of judgment: which steps always hold, and which are configurable variants;
3. Failure recovery and acceptance: how to know it "really succeeded", rather than only seeing prompts, compilation, or static checks;
4. Boundaries: which inputs do not apply, and which logic, data, or credentials need to be kept as private configuration;
5. 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 item by item; merge different channels, models, project paths, or tool implementations under the same user outcome.

Step 3: Write the Skill blueprint

According to the Skill blueprint template , deliver a Chinese blueprint. Each blueprint must include:

• A user-facing name and a one-sentence promise;
• Trigger phrases and at least one clear non-trigger scenario;
• Inputs, outputs, core process, and configurable items;
• Real acceptance signals, common failures, and recovery paths;
• Private-information boundaries;
• One or more traceable evidence summaries.

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

Step 4: Make an promotion decision

Give one conclusion for each blueprint:

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

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

Step 5: Hand off implementation

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

Dependencies

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

General feedback loop

When the user provides revision feedback during a Skill-driven task, before continuing with the current artifact, you must execute:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Only modify the current task, not the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the changes to the current task.
5. reusable Modifications will invalidate 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 do not automatically proceed to publishing, submission, or other external writes.