Use skills for repeatable work
A skill packages instructions and supporting material for a recurring task. Use one to make a proven method easier to repeat—not to assume that the model has been trained, that a tool is installed, or that an action is authorized.
On this page
These controls describe the October 2026 development interface; availability can differ by release and account.
Start from a task you can evaluate
Choose a narrow job with a recognizable input and output. For example, a project-brief skill might require dated source notes, separate decisions from facts, and leave missing owners marked unknown.
Before importing or creating a skill, write down:
- when it should be used and when it should not;
- required input and the expected output;
- the checks that define a correct result;
- any permitted tools and actions needing separate approval.
A skill should not contain real credentials or assume access to private accounts merely because a procedure mentions them.
Find and inspect a skill
Open Skills and inspect the intended item before using it. Review its instructions and supporting files where available. Check the source and version, required tools, external destinations and any scripts it includes.
There are different creation paths:
- Zip import imports an existing package.
- Skill.md link imports from an accepted HTTPS or GitHub file link.
- Target description asks a skill-generation agent to develop a skill from your requirements.
Use a trusted source. Basic package validation does not establish that its instructions or scripts are safe, accurate or appropriate for your task.
Import or request a skill
Choose the relevant creation method in the Skills creation dialog. For a package or link, supply that source and inspect the result. If a personal skill already exists, review the overwrite confirmation; do not replace it casually.
For Target description, describe the recurring task, triggers, input, output and constraints. After submission, open the processing sub-session if provided and answer any clarification questions. “Request submitted” means the generation workflow was started, not that a working skill has been finished or validated.
Review the produced instructions before routine use. Do not publish or share a skill containing private examples, business data or credentials.
Load it for the intended session
Where you can manage the session, open Advanced settings → Runtime config. Use the Loaded skills selector, choose the intended available skill, confirm the selection and Save the settings.
Then give the task its actual inputs and acceptance checks. Loading a skill supplies working instructions; it does not prove that its required tools are connected or that an external action is permitted. Inspect the session result against the original material.
If the skill is unavailable, check the account, source and installed version rather than pasting its name repeatedly into the prompt. If settings fail to save, retain the error and verify the current selection before retrying.
Improve the method deliberately
When a result exposes a repeatable problem, update the instructions to address that problem and test them again with a small, non-sensitive example. Where the interface offers a draft and publication flow, review the draft before publishing it to your personal library. Submission to a shared/public library is a separate action requiring its own review.
This is improvement of reusable instructions. It is not evidence of training model weights, automatic self-improvement or guaranteed learning from every task. Keep changes understandable: what failed, what instruction changed, and what result would demonstrate the change helped?
Check tools and integrations when a skill needs external capabilities. Review approval boundaries before taking action.