sgc-skill-distiller

Skill Alchemist · Skill Alchemist

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 off to sgc-skill-creator for implementation, without leaking 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, 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 off to sgc-skill-creator。
• The user wants to optimize, revise, or upgrade an existing Skill: hand off to sgc-skill-optimizer。
• The user only wants to save a project convention into the system prompt or project description: hand off to sgc-distill-to-system。

Workflow (MANDATORY)

Step 0: Choose the experience unit to distill

Use a complete "problem → judgment → action → verification" loop as the unit. Prioritize experience that has gone through real execution, release, installation, or user acceptance; one-off inspiration, pure technical interest, or content containing only internal context should not yet be 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 let them enter the blueprint's name, description, or examples.

Step 1: Collect raw evidence (supporting, 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 supporting evidence should 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 internal implementation actions;
2. Stable judgment order: which steps always hold, and which are configurable variants;
3. Failure recovery and acceptance: how to know that 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. Minimum 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 one-sentence promise;
• Trigger phrases and at least one explicit 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 promotion decisions

Give one conclusion for each blueprint:

• Create: user results, boundaries, acceptance, and evidence are all clear;
• Continue distilling: 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; 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 a blueprint to "Create", hand it off to sgc-skill-creator: it is responsible for implementation, validation, and local installation. When the user requests publishing, hand it off to sgc-skill-publisher。

Dependencies

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

General feedback loop

When the user raises modification suggestions during a Skill-driven task, before continuing with the current artifact you must execute:

1. First determine whether the suggestion 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 applicable to all Skills, first update the shared specification.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the modifications to the current task.
5. reusable The modification will invalidate previous "confirm", "continue", and "send it" instructions; 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, submission, or other external writes.