Apply your first skill

Goal

One skill installed, active, and visibly guiding a run. Done means you can point at a run and say what the skill changed — and remove or replace it without losing data or history.

Image: Skills Home with installed skills on one side and the discovery catalog on the other.

Steps

1. Open Skills Home. It holds three things: skills already installed in your workspace, the discovery catalog, and the ways to create a new one. Start with installed versus catalog — know what is guiding your runs today before adding more.
2. Browse the catalog for a job you already do by hand. Catalog entries show what each skill covers and whether it is recommended for your setup. Pick one task, not a bundle — a skill earns trust one job at a time.
3. Selecting a catalog entry does not install it silently. It opens a draft tab with a starter package: the skill's instructions beside a derived summary. Read both. If the instructions would not guide your process correctly, say so in plain language and let the draft update — or walk away before anything is saved.
4. Save to install. Saving commits the package as a workspace asset with version history. From here it can be compared across versions, rolled back by activating an older one, or deleted — deletion removes guidance, never your data or run history.

Image: editor tab with skill instructions, summary beside it, and version history showing the first save.

5. Run the covered task: describe the need as usual and let the workflow move through proposal, dry-run, and commit. In Pipeline Studio you can also attach skills explicitly — to a whole workflow or to a single node — where guidance should apply narrowly.
6. Compare against the unskilled baseline. What did the skill add: better generation, sharper validation hints, fewer corrections at review? If you cannot name the difference, it has not earned its place.
7. Prune on a schedule. Active skills stay few and named — each with a job you can state. Guidance rots as processes change; version history and compare exist so updates stay reviewable.

Image: run history entry with the applied skill named beside the outputs it guided.

When skills misbehave

• Guidance feels generic: the skill does not know your process. Edit the instructions in the editor tab and save a new version — skills are documents, and documents improve with editing.
• Wrong runs affected: the skill is attached too broadly. Narrow it to the workflows or nodes where it belongs.
• Regret after saving: activate the previous version. That is what the history is for.

What good looks like

• Every active skill maps to a real recurring job.
• Differences between versions are reviewable, with reasons.
• Removing any skill is safe and leaves history intact.

Next

• Build your own when the catalog falls short: Developers.
• Sharpen review and feedback: Operators.