Rather than rewriting the same instructions for every project, you write a skill once and attach it wherever it is needed. There are three types of skill in Researcher. Personal skills are created by individual users and are only visible to them. Org skills are created by org admins and are available to everyone in the organisation. System skills are created by P-admins, tied to a product ID, and available across every organisation with that product enabled.
Skills vs Instructions vs Templates
These three things are easy to confuse. They sit on a scale of how much they carry and where they live.
| Where it lives | What it carries | When to use |
Instructions | One specific project | A standing brief in that project's Instructions tab | Per-project tweaks; one-off projects |
Skill | Org-wide library | A reusable instruction block any user can attach to any project | The same way-of-working you'd want across many projects |
Template | Org-wide library | Instructions, uploads, connectors, actions, collaborators — a whole project blueprint | Recurring workflows where the uploads and connectors also stay the same |
The progression usually goes: paste it into Instructions on one project → realise you're pasting it everywhere → publish it as a Skill → if the workflow also needs the same uploads and connectors, fold it into a Template.
What a Skill is, technically
A Skill is a small bundle of content stored in the org's library:
A name and a short description
A body of instructions (Markdown)
Optionally, files the AI can read on demand via the
read_skill_filetool
When a user attaches a Skill to a project, the runtime loads the instructions into the prompt for that project's chats. If the Skill bundles files, the AI can call read_skill_file to fetch them in the same way it'd search uploads.
Skills live at the org level. They aren't user-private — anyone in the org with access to Researcher can see and use the published Skills.
When to make a Skill
Publish a Skill when two or more of these are true:
The instructions you'd paste are stable enough that you'd reuse them across many projects.
More than one person on the team would benefit from using them.
You want everyone using them to get a consistent shape of output.
They aren't tied to a specific set of uploads — if they are, you want a Template.
Skip Skills when the instructions only make sense alongside a specific knowledge base — that's a Template's job.
Publish a Skill
The general shape:
Open the Skills area from the org admin menu.
Click + New skill.
Fill in:
Name — what users see when they pick a Skill (e.g. CSM account-health playbook).
Description — one sentence explaining what attaching this Skill does to a project.
Instructions — the Markdown body. This is the prompt addition that gets merged into projects that attach the Skill.
Files (optional) — supporting documents the AI may read on demand.
Publish.
Once published, any user in the org sees the Skill in the Attach skill list when configuring a project.
System skills follow the same authoring flow as org skills but require P-admin access. When publishing, assign the skill to a product ID — it will then appear in the skill library of every organisation with that product enabled. Edit with care, as changes affect all organisations using the skill, not just your own. Org admins can hide system skills from their users but cannot edit them.
Attach a Skill to a project
For users — once an admin has published Skills, you attach them per project:
Open the project.
Open the Instructions tab.
Click Attach skill (the exact label may vary).
Pick from the list. You can attach more than one.
Save.
The attached Skill's instructions are merged into the prompt for every chat in this project. Start a new chat to feel the effect — existing chats keep their history but will pick up the Skill's instructions on the next message.
Detaching a Skill removes those instructions from future messages in the project. It doesn't rewrite chat history.
Tips for Skill authors
Treat the Skill body like a brief, not a template. Skills get merged with whatever a user has in the project's own Instructions tab. Write them assuming they'll sit alongside other context, not replace it.
Keep them focused. A Skill that does QBR follow-ups, escalation summaries and renewals at the same time will do all three badly. Split them.
Name them after the work, not the team. "Renewal-risk assessment" tells a user what attaching this Skill does. "CS Team Skill 4" doesn't.
Test with a real project. Attach the Skill to a project that has your typical uploads and a representative chat. Does the output land the way you expected? Iterate before you announce it.
Version in the description. If you tweak the body, bump the description (v2 — tightened wording) so users know what changed.