Your standard operating procedures live in SharePoint. So why does everyone still do the task their own way? SharePoint Skills, generally available as of this month (July 2026) as part of Copilot in SharePoint, let anyone capture a procedure once and have Copilot run it the same way every time, no code, no Power Automate flow, no developer.
Your business users can now build these, whether you’ve briefed them or not. Here’s what Skills are, how they work on a real SOP, and why it’s your job as an IT lead to spearhead the rollout rather than tidy up after it.
The SOP problem every SharePoint admin knows
Every organization has a folder of procedures. The new-hire checklist. The contract review steps. The month-end report format. They’re written down, they’re stored in SharePoint, and they’re followed inconsistently, because a document that describes a process still relies on a human to read it, remember it, and apply it correctly under time pressure.
A SharePoint Skill closes that gap. It takes the procedure out of the static document and turns it into something Copilot in SharePoint can execute on demand. One person writes the SOP as a Skill. Everyone with access to the site can run it and gets the same result.
Here’s the catch for IT leaders: the people feeling this pain, the team managers watching three people run month-end three different ways, don’t know it’s now solvable. Nobody in finance or HR reads the Microsoft 365 Message Center, and nobody is going to discover Skills on their own. The awareness sits with you in IT, which makes this your conversation to start.
What a SharePoint Skill actually is
A Skill is a reusable, multi-step workflow that runs inside Copilot in SharePoint (the feature Microsoft previously called AI in SharePoint). You author it from a chat prompt in plain language, review the draft, and save it. Under the hood, each Skill is a Markdown file — SKILL.md — stored in a new Agent Assets library on the site, using the same open skill format Anthropic defined for Claude.
You describe the procedure in English, and SharePoint stores it as a governable file with permissions, versioning, and retention, exactly like any other document. No custom connectors. No scripts. When someone asks a matching question, Copilot loads the relevant Skill automatically, or a user can invoke it by name.
You’ll need a Microsoft 365 Copilot license to use Copilot in SharePoint. Skills come at no extra cost on top of that.
Building a Skill for a real SOP
Take contract review, a procedure most legal and operations teams have written down and few run consistently. It’s the scenario Microsoft uses in its own documentation, and it’s a good one.
In the Copilot chat panel on your contracts library, you describe the SOP the way you’d brief a new hire: “Create a skill to review contracts and check that each one includes a valid lawyer ID in the format xxx-xxx. If a contract doesn’t, add its name to an Invalid Contracts list, with the review date and the reason. Create the list if it doesn’t exist.”
SharePoint drafts the Skill, tells you the steps it will take, and asks you to confirm. To run it, you select the contracts, open the chat, and type “review those contracts.” Copilot recognizes the intent, loads the Skill, tells you which Skill it’s using, and returns a structured summary: valid contracts, flagged contracts, and a populated list you can act on.
Nobody wrote a line of logic. The procedure now runs identically whether it’s the person who authored it or someone who joined last week. The same pattern covers the SOPs that cost teams hours: a new-hire packet check that confirms every folder has the offer letter, the I-9, and the signed handbook; a proposal review that flags discounts above policy; a knowledge base audit that lists articles untouched in twelve months.
Where Skills stop and why that’s the point
Skills inherit SharePoint’s security model, which draws hard boundaries you should understand before you brief the business. A Skill runs only as the person invoking it. It can’t do anything that user couldn’t already do. It can’t call external APIs or webhooks. It can’t run PowerShell, Graph calls, or custom code. It only chains the built-in actions available in Copilot in SharePoint.
You control who builds and who runs. By default, anyone with Edit permissions on the site can create a Skill and anyone with View permissions can use it. If that’s too open, break permission inheritance on the Agent Assets library and restrict Skill creation to the people who own the process.
For SOP work, those constraints are a feature. A procedure that respects existing permissions and can’t reach outside the tenant is exactly what you want business users building without IT reviewing every line. When a workflow needs external systems or custom logic, that’s the signal to reach for Copilot Studio or Power Automate instead, not to force a Skill to do a job it wasn’t designed for.
Running Skills at scale: descriptions, size limits, and governance
Enabling one skill to be built is simple. Running two hundred of them across a tenant, reliably and safely, is a different discipline, and it’s where most organizations will need help.
Start with the uncomfortable fact: Skills are on by default. There’s no opt-in, no feature to activate. Anyone with Edit permissions and a Copilot license can build one today, briefed or not. So, the choice facing you isn’t whether to introduce Skills, it’s whether to lead the rollout now or discover in eighteen months that marketing has forty ungoverned Skills nobody owns.
Then there are the harder craft problems worth noting. Skills auto-trigger on their description, so a vague description means a Skill that fires unpredictably or not at all; writing descriptions that discover reliably is a craft in itself. Anthropic’s authoring guidance for the skill format recommends keeping a Skill under 500 lines, so anything substantial has to be architected: split into foundation Skills that reference each other, or backed by a references folder the Skill loads only when needed.
There’s also SHAREPOINT.md, a site context file Microsoft shipped alongside Skills. It acts as persistent memory for the whole site, encoding your terminology, tone, and rules into every Skill and prompt automatically, and almost nobody is using it yet.
And Skills are scoped to the site they’re built on, with no tenant-wide catalog, so governance and lifecycle, versioning, ownership, stopping sprawl, fall to you.
There’s also a content-quality trap. A Skill built on a library full of duplicated policies, stale documents, and over-broad permissions will faithfully amplify every one of those weaknesses. Getting the business’s SOPs to run well is downstream of getting your SharePoint content in order first.
Read our interview with knowledge management specialist Susan Hanley for best practice advice.
Start with one team, one procedure
Don’t announce Skills to the whole organization. Pick one team with a painful, well-documented SOP and sit down with the process owner. They bring the procedure; you bring the guardrails.
Co-build the first Skill on a single site, restrict who can create Skills via the Agent Assets library, and test on a small selection of documents before the team runs it for real.
That pilot does double duty: the process owner learns the authoring loop, and you get the before-and-after that sells Skills to every other department, on your operating model rather than by accident.
Then the question becomes architectural: how do you take one working Skill and turn it into a governed library of them, built by the business, on content that’s ready for AI to read? That’s the work Cloudwell does. Reach out and ask us for help.
FAQs
Who should create SharePoint Skills IT or business users?
Business users, with IT setting the operating model. Skills are authored in plain language and Microsoft’s default permissions let anyone with Edit rights build one, so the person who owns the procedure is the right author. IT’s role is awareness, enablement, and governance: naming standards, description quality, ownership, and permissions on the Agent Assets library.
What deserves to be a Skill and how do we help teams pick?
Give teams a three-part filter. The procedure is written down (or could be), it runs on content that lives in SharePoint, and it produces inconsistent results depending on who does it. Contract checks, new-hire packet reviews, library audits, report formatting — all strong candidates. What doesn’t qualify: one-off tasks (just prompt Copilot directly), judgment calls with no defined steps, and anything touching external systems. The best first Skill is the SOP a team most often gets wrong, not the one that’s most impressive.
How do we teach the business to build Skills well?
Run a short workshop before the pilot spreads, not after. Two things separate Skills that work from Skills that misfire, and neither is obvious to a first-time author: the description (which controls when a Skill auto-triggers, so vague descriptions mean unpredictable firing) and scope (one procedure per Skill, kept well under the format’s 500-line guidance). A 90-minute session covering those two rules, your naming conventions, and a live build of a real SOP is enough to set the standard. Pair it with a one-page authoring guide stored on the site — or better, encode your rules into SHAREPOINT.md so every Skill built there inherits them automatically.
How do we govern Skills and when should one be updated, archived, or deleted?
Treat Skills like the documents they are, with one extra rule: a stale Skill is worse than a stale document. A stale document sits there; a stale Skill auto-triggers and executes an outdated process with full confidence. Every Skill needs a named owner, normally the process owner, not IT, and a standing rule that when the SOP changes, the Skill changes the same day. Version history, retention labels, and audit logs apply like any other file. When a process is retired, don’t leave the Skill live to fire on a matching prompt: there’s no native archive state yet, so removing or relocating the file is the current approach, with the recycle bin and version history as your safety net. A quarterly review of each site’s Agent Assets library, what exists, who owns it, when it last changed, keeps sprawl visible before it becomes a problem.
Can we control who builds Skills without blocking the whole business?
Yes, and per site. The default is that Edit permissions on a site grant Skill creation, which is right for most team sites. Where the stakes are higher, a contracts library, a compliance site, break permission inheritance on the Agent Assets library and limit creation to the process owners, while everyone keeps the ability to run them. That’s the middle path between locking Skills down to IT and letting anyone build anything anywhere.
What’s the risk if a business user builds a bad Skill?
Contained, by design. A Skill runs entirely as the person invoking it and inherits their existing permissions. It can’t expand access, reach data the user couldn’t already see, call external systems, or run custom code. The realistic failure modes are quality problems, not security ones: a Skill that fires unpredictably, encodes an outdated process, or amplifies messy content. That’s why governance effort belongs on descriptions, ownership, and content hygiene rather than on reviewing every Skill before it ships.
Where do Skills stop and IT takes over?
When a workflow needs external systems, custom code, or actions outside Copilot in SharePoint. Skills only chain built-in SharePoint actions, so teach teams to recognize the signal: if the process needs to email someone, update another system, or apply logic Copilot can’t express, that’s a handoff to IT for Copilot Studio or Power Automate, not a reason to force a Skill to do a job it wasn’t designed for.
Brief your business before they find this themselves.
Cloudwell helps Microsoft 365 teams roll out governed, reliable SharePoint Skills starting with a scoped pilot alongside one process owner and a plan for running them at scale. Talk to us about a Skills pilot. .