Paste a link to a GitHub repository or a URL that hosts an Anthropic-style Skill package, and your employee will import the whole thing directly instead of you rebuilding it by hand in the Create Skill drawer. This is on our roadmap and is not active yet: the option appears in the Skills toolbar and in the Create Skill drawer today, but importing does not run until we ship it.
Skills are the step-by-step playbooks an employee follows when a task matches, and today you build every one of them inside Sistava: type a name, write a "when to use" trigger, paste the instructions, pick a category. That works well for a skill you are writing yourself, but a lot of useful skill packages already exist as plain folders of Markdown and reference files sitting in public GitHub repositories, written for Claude's own Skills format or shared informally by other teams. Right now there is no way to point Sistava at one of those repos and have it become a skill on your employee.
Import a Skill from GitHub or a URL is the fix we are building for that gap. The plan is simple: you give an employee a repository link or a direct URL, Sistava fetches the package, reads its structure (name, description, instructions, and any bundled reference files), and turns it into a normal skill on that employee, ready to toggle on or off exactly like a skill you wrote from scratch or added from the catalog.
The difference from what already exists matters. Browse Skills gives you a curated catalog we maintain inside Sistava; Create Skill gives you a blank editor for writing your own. Neither lets you reach outside the platform and pull in a skill package someone else published on GitHub, or a Skill bundle they linked from a blog post or a shared drive. Import from Repo is meant to close that specific gap: it targets external, already-written packages, not skills that live inside Sistava's own catalog, so you stop retyping instructions that already exist somewhere else in a well-formed file.
Nothing about this changes how skills run once they are on an employee. An imported skill would load on demand the same way every other skill does: the employee sees its name and description at all times, and only reads the full instructions when the current task actually matches. Import only changes how the skill instructions get onto the employee in the first place; the loading, toggling, editing, and removal behavior stays identical to any skill you create by hand today.
The reason this is a real piece of work rather than a fetch is that outside packages arrive with baggage. A package written for a different platform tends to link to files it did not bring with it, tell the reader to run scripts, name tools your employee does not have, and carry the branding of wherever it came from. Handed straight to an employee, instructions like that make it worse at the job, not better, so the import has to clean them up rather than trust them.
Length is the other half of the same problem. A skill earns its place when it reads like a short playbook: what it is, when to use it, and how to approach it. The good ones run a page or two, not a whole repository poured into a text box.
Create Skill is for writing a playbook from scratch, one field at a time. Browse Skills is for picking from the catalog Sistava already curates and maintains inside the platform. Import from Repo is meant to be the third path: pulling in a package someone already wrote and published outside Sistava, whether that is a public GitHub repository built for Claude's own Skills format, or a URL hosting a shareable skill bundle.
The value is not having a third way to create a skill for its own sake, it is not having to manually retype instructions, when-to-use logic, and reference material that already exists in a well-formed external file. A team publishes a skill package for a workflow you already need, you would import it instead of reading it and rebuilding it by hand.
An imported skill is not a special or restricted type of skill. Once it lands on an employee, it behaves exactly like a skill you wrote in Create Skill or added from Browse Skills: it appears in its category with the rest, it can be toggled on or off, its instructions and "when to use" field remain editable, and it can be duplicated or removed the same way.
It also loads the same way at run time. The employee always knows the skill's name and short description, but only reads its full instructions when the current task actually matches that skill, the same on-demand behavior every other skill on the platform already follows.
Point at a repo or URL, get back a ready-to-use skill
The intended flow starts from the Skills tab toolbar or the Create Skill drawer, where an "Import from GitHub or URL" option is already visible even though it is inactive. You would paste a repository link (or a direct URL to a package) and submit it.
Sistava would then fetch the package, parse its skill definition and any linked reference files, and present it to you before anything is added, so you can confirm the name, the "when to use" trigger, and the instructions look right for your employee. Once confirmed, it becomes a normal skill: same toggle, same edit flow, same catalog behavior, same on-demand loading as every skill already on the platform.
Until this ships, use Create Skill to write the instructions yourself, or Browse Skills to pull from the catalog we already maintain. Both are fully active today and cover the same end result, just without the copy-paste step from an external source.
A team publishes a well-written playbook for a job you also do, such as screening inbound leads or preparing a weekly report. Once this ships, you would point an employee at the link instead of reading the package and rebuilding it field by field.
If your own internal procedures are already written as files in a repository, importing keeps that file the original and the employee's skill the copy, rather than starting a second version in the Create Skill drawer that immediately begins to drift.
The cost of trying somebody else's approach today is the transcription. Removing that step makes it reasonable to import a package, watch how an employee uses it on real work, and turn it off again if it does not suit how you operate.
Nothing is blocked while this is being built. Write the instructions yourself in Create Skill, or add one from the catalog Sistava maintains, and you get a fully working skill today with the same on-demand loading an imported one will have.
| Before | After |
|---|---|
| A useful playbook already exists in a public repository, and the only way to get it onto an employee is to open it and retype the instructions into the Create Skill form. | You will paste the link and let Sistava read the package into a skill for you. |
| Copying by hand means transcribing the name, the trigger, the instructions, and the reference material, and something always gets dropped on the way. | The whole package will come across together, and you confirm it before it is added to an employee. |
| An external package carries steps and file references that mean nothing here, so pasting it in as written can leave an employee worse off. | A review step will put the parsed skill in front of you first, so nothing reaches an employee unseen. |
| Adopting somebody else's published workflow is a small project, so most of the time you do not bother. | It will be a link and a confirmation, short enough that trying one is worth it. |
Not yet. The option is visible in the Skills tab toolbar and in the Create Skill drawer, but importing is not active. Selecting it currently tells you the feature is on the way rather than pulling in a package.
Use Create Skill to write the instructions yourself, or Browse Skills to add from the catalog Sistava already maintains. Both are live today and produce a normal, fully functional skill on your employee.
No. The plan keeps imported skills identical to hand-written ones once they land on an employee: same on-demand loading, same toggle, same editing, same categorization, and same removal behavior. Import only changes how the instructions first arrive on the employee, not how they run afterward.
The feature is scoped to a GitHub repository link or a direct URL hosting a skill package, formatted for Claude's own Skills structure or an equivalent shareable bundle. It is not a general-purpose web scraper for arbitrary pages.
No date has been announced. The option is already visible in the Skills toolbar and the Create Skill drawer so you can see where it will live, and it starts working when we ship it. Until then, Create Skill and Browse Skills produce the same finished result.
That is the plan. The intended flow reads the package, then shows you the name, the when-to-use trigger, and the instructions before anything is added, so you confirm what your employee is about to follow rather than finding out afterwards.
It can, which is exactly why import is a review step and not a paste. Packages written elsewhere often point at files they did not bring with them, tell the reader to run scripts, or name tools your employee does not have, and those instructions have to be cleaned up rather than followed literally.
No. A skill works best when it reads like a short, sharp playbook of a page or two: what it is, when to use it, and how to approach it. A long repository dump gives an employee more to wade through and less clarity about what to do.
Import a Skill from GitHub or a URL is part of Things they can do out of the box.
Every AI employee ships with built-in abilities that work out of the box. Search the live web for real-time information, scrape and crawl any website for structured data, and generate images directly in conversation. No plugins to install, no APIs to configure.