Microsoft frames Copilot in SharePoint around three capabilities, and the framing is more useful than most product taxonomies. Each capability solves a different job, uses a different artefact, and combines with the other two to produce real workflows. Get the framing right and your team builds the right thing the first time. Get it wrong and you spend three weeks rewriting Skills that should have been context, or context that should have been Skills.
This is the practitioner explainer of all three with worked examples drawn from client builds running since the September 2025 preview opened. What each capability is, where the artefacts live, and the most common mistakes I see when teams pick the wrong one for the job.
The three capabilities, in 60 words
What to Know. Site-level context files that load automatically into every chat. Plain Markdown. How to Act. Reusable multi-step workflows defined in SKILL.md files; anyone on the site can invoke them. What to Produce. On-demand generation of Word, Excel, PowerPoint files plus interactive HTML reports and dashboards. All three are built on the same open Markdown standard. All three are included with the Microsoft 365 Copilot licence.
The architecture: separating know, act, produce
Microsoft published the three-capabilities framing in the April 2026 Tech Community blog introducing AI Skills public preview. The framing reflects an architectural pattern that has emerged across AI tools: separate what AI needs to know about a system from how it should act within that system from what it needs to produce for the user.
The three live as separate Markdown files in a special site library called Agent Assets:
/Agent Assets/
SHAREPOINT.md ← What to Know (site context)
Skills/
contract-review/
SKILL.md ← How to Act (one Skill)
weekly-status/
SKILL.md ← How to Act (another Skill)
Plans/
SitePlan.md ← Site build plan (if AI-built)
What to Produce is not a file. It is the act of generating output (a Word document, an Excel sheet, an HTML dashboard) using context from SHAREPOINT.md and the workflow defined in a SKILL.md.
The reason this architecture matters for teams: each artefact has one job. The site context file does not know how to run a contract review; it just knows the site's standards. The contract review Skill does not need to re-state the site's standards every time it runs; it inherits them. The Word document the Skill produces is not its own configuration; it is just the output.
This separation makes the assets reusable and maintainable. Change the site's house style once in SHAREPOINT.md; every Skill respects the new style on the next run. Change a Skill's logic once in its SKILL.md; every future invocation uses the new logic.
What to Know: site-level context files
What it is. A single Markdown file (SHAREPOINT.md, uppercase, at the root of the Agent Assets library) that captures everything AI in SharePoint should know about a specific site. The file loads automatically into every chat on the site.
What goes in it. Site purpose, library map, naming conventions, document standards, voice rules, the glossary of org-specific terminology, rules for AI to follow, sensitive content flags. Written for AI, not for humans, though it stays readable for both.
What it changes. Without it, every chat starts from zero. The user has to re-explain the site's standards every prompt. The output is generic. With it, every chat starts with full context. The same prompt run by different team members returns output that respects the site's standards consistently.
The template is at copilotinsharepoint.com/sharepoint-md-template.md. Fill in the placeholders, upload to /Agent Assets/SHAREPOINT.md, and every chat on that site inherits the context.
Worked example: the people and culture site
A people and culture site uses What to Know to capture the team's working standards. The SHAREPOINT.md file lists every library (policies, procedures, templates, forms, workforce data, engagement surveys), the naming convention for each (POL-NNN for policies, PRO-NNN for procedures), the document standards (Australian English, plain language, no jargon), and the sensitive content flags (personnel records, exit interviews, board papers).
Once the file is in place, a request like "rename these eight policies according to our standards" loads the naming convention automatically. The renames apply the correct prefix and pattern without the user re-specifying. The full demo runs in this video walkthrough: AI in SharePoint Finally Makes Sense With This File.
What to use it for. Any site where the team has consistent standards that AI keeps forgetting. Naming conventions, voice rules, library structure, glossary terms, what counts as sensitive content. If you find yourself typing the same context into Copilot more than twice a week, it belongs in SHAREPOINT.md.
What not to use it for. Multi-step processes (those are Skills). Document templates (those are content-generation inputs). Per-user preferences (the file is site-wide; everyone inherits it).
Deep dive: the SharePoint AI Skills article covers the SHAREPOINT.md and Skills relationship in detail.
How to Act: Skills
What it is. A reusable multi-step workflow defined in a Markdown file (SKILL.md) stored at /Agent Assets/Skills/<skill-name>/SKILL.md on the site. The file captures the inputs the Skill expects, the steps it follows, the rules it applies, and the output format it produces.
What it changes. Without Skills, a multi-step process lives in one person's head. The senior reviewer knows how to run a contract gaps analysis; nobody else does, exactly. With a Skill, that process is in a file. One person writes it. The whole site runs it. The output is consistent across team members.
What it cannot do. Skills cannot call external APIs, cannot execute custom code, cannot exceed the running user's existing permissions. The boundary is intentional and makes Skills safe to publish broadly.
Worked example: the contract review Skill
A financial services legal team uses a contract review Skill to standardise returned-contract reviews. The SKILL.md file is about 60 lines. It loads a base contract from the documents library, compares it against any selected returned versions, applies an impact analysis (low/medium/high business impact per change), and outputs a priority-ordered table.
The first time the Skill runs, it flags 24 changes in seconds, ordered by impact. Same output every time, regardless of which legal team member invokes it. The senior reviewer's standard is now in the file, not locked to her availability. The full demo runs in SharePoint AI Skills That Replace Hours of Work.
What to use it for. Repeatable multi-step workflows. Contract reviews, status reports, library audits, board pack preparation, structured document generation. Anything your team does at least monthly that follows the same pattern.
What not to use it for. One-off prompts (just write the prompt). Single-step actions like "summarise this document" (the built-in capability handles it). Cross-system integrations (use Copilot Studio agents).
Deep dive: SharePoint AI Skills, the practitioner deep-dive covers anatomy, authoring, and the comparison to Copilot Studio agents.
What to Produce: content generation
What it is. The capability to generate finished documents and structured outputs from Copilot in SharePoint chat. Word documents, Excel spreadsheets, PowerPoint presentations, and interactive HTML reports and dashboards.
What it changes. Without content generation, AI in SharePoint summarises, analyses, and drafts text in chat. With content generation, the output is a Word, Excel, or PowerPoint file saved to your document library, or an interactive HTML dashboard. The deliverable is finished; the chat is the path to it, not the end product.
How it works. Content generation uses context from SHAREPOINT.md (if present) and workflow logic from a SKILL.md (if invoked through one), then produces the finished file. You can ask for a one-off output ("draft this letter as a Word document") or wrap the generation in a Skill so the same output regenerates the same way every time you invoke it.
Worked example: the ticketing dashboard
An IT support team needs a monthly performance dashboard from its ticketing system. Twenty-two files land in a SharePoint library each month (Excel exports, call transcripts, sentiment data). Without content generation, this report takes the team lead a day to assemble manually each month.
With content generation wrapped in a Skill, the team lead points Copilot in SharePoint at the library, the Skill loads, and the output is a self-contained interactive HTML dashboard with SLA charts, agent performance heat maps, sentiment analysis, and on-brand styling pulled from a Design MD file. After the report is built, the same Skill archives the source files into a dated folder. Total runtime: under five minutes. The full demo runs in Stop Reformatting Reports. Let Copilot Cowork Build the Dashboard..
What to use it for. Any output your team produces manually from existing data. Monthly reports, quarterly board packs, project status decks, contract drafts from templates, status update emails.
What not to use it for. Documents that need to be created entirely from scratch with no input data (better suited to one-off prompts). Real-time data dashboards that need live API connections (use Power BI or Copilot Studio with the right connector).
How the three combine in a real workflow
The cleanest example of all three in one workflow is the weekly project status report.
Before the three capabilities are in place. The project manager opens Microsoft Word every Friday afternoon. Pulls together updates from team channels, document libraries, and the project tracker list. Writes the status update. Formats it. Emails it to the steering committee. The whole task takes 90 minutes most weeks, longer when there is more to summarise.
With all three in place. The site has a SHAREPOINT.md (What to Know) that captures the project's structure, the libraries that hold each kind of update, the voice rules for executive comms, and the steering committee distribution list. A Weekly Status Skill (How to Act) defines the inputs (the project tracker, the document libraries from the last week, the team channel for the last week), the steps (extract material updates, flag risks, summarise progress), and the output format. The Skill invokes content generation (What to Produce) to produce the finished Word document.
The project manager opens chat on Friday. Types "run the weekly status skill". The Skill loads, reads the SHAREPOINT.md for context, executes its steps, produces the Word document, saves it to the right library, and surfaces a one-line summary in chat. Total time: under a minute.
The three capabilities working together are more than the sum of their parts. The context file makes the Skill simpler (no need to re-specify the libraries or voice rules). The Skill makes the content generation repeatable (same shape of output every Friday). Content generation makes the Skill produce something useful (a finished Word document, not a chat summary).
Common mistakes
Three patterns I see when teams pick the wrong capability for the job.
Treating context as a Skill. A team writes a Skill called "site rules" that just describes the site's naming conventions and voice. AI in SharePoint loads it on every prompt regardless of whether the user needs the rules for that prompt. The Skill clutters the workflow and slows responses. This information belongs in SHAREPOINT.md, which loads automatically. A Skill is for active multi-step work, not for passive site knowledge.
Treating a Skill as a one-off prompt. A user writes a Skill for something they will run twice. The Skill takes an hour to build and gets used twice. The same outcome was a 30-second one-off prompt. Skills earn their existence when the workflow runs at least weekly. If you are not sure whether something will repeat, run it as a prompt the first few times, build the Skill once the pattern is clear.
Building Skills without a SHAREPOINT.md. A team writes five Skills before writing the context file. Every Skill ends up re-stating the same site context (the library paths, the naming conventions, the voice rules). When the standards change, the team has to update every Skill. The fix is to write SHAREPOINT.md first, then write Skills that inherit from it.
A fourth, less common but worth flagging: expecting content generation to invent data. Content generation produces output from input data plus context. It does not make up content that does not exist somewhere in the source. If you ask for a status report and the underlying libraries have no recent updates, the output reflects that. The capability surfaces what is there; it does not generate the work.
What to do this week
If you have a site where Copilot in SharePoint is opted in, three actions in order.
-
Write the SharePoint.md file for that site. Use the template, fill in the placeholders, upload to
/Agent Assets/SHAREPOINT.md. One hour of work for the team lead. This is What to Know in place. -
Build one Skill. Pick a process the team runs at least monthly. Open Copilot in SharePoint chat, describe the Skill in natural language, let it generate the SKILL.md, iterate over the first two or three runs. This is How to Act in place.
-
Use content generation for the next time you would have produced that output manually. Invoke the Skill, let it produce the Word, Excel, or HTML file, save the time you would have spent assembling it. This is What to Produce in place.
The three capabilities give your team a foundation that compounds. Every Skill you write after the first one is faster because the SharePoint.md context is already in place. Every report you generate is more useful because the Skill structures it consistently. The investment pays back the first time a team member who is not the author runs the Skill and gets the right output.
If you want help running this sequence in your tenant with your team, the Copilot in SharePoint Immersive is a one-day session where we put all three capabilities in place for one of your most active sites. SharePoint.md written together, three Skills built, content generation invoked. By the end of the day your team has working assets, not slides about working assets.
For the deep dive on each capability separately:
- The admin guide for the opt-out rollout — the prerequisite to any of this
- SharePoint AI Skills, the practitioner deep-dive — How to Act, in detail
- Does Microsoft Copilot use Anthropic Claude in SharePoint? — the model question (coming soon)
- The 2026 practitioner guide — the parent pillar
