SHAREPOINT.md is a markdown file in the root of a site’s Agent Assets library that Copilot in SharePoint loads at the start of every conversation on that site. It tells Copilot what the site is for, which library holds what, how files are named and which rules to follow, so every person who opens the chat gets an assistant that already knows how the site works.
I call it the brain of your SharePoint site. If you’ve used CLAUDE.md or AGENTS.md in a codebase, it’s the same idea, except the file sits in a library the site’s own team can open and edit, and when they update it every user gets the new behaviour. When I recorded the video above in April it was still called AI in SharePoint and you had to place the file yourself. Copilot in SharePoint can now draft it for you.
How does SHAREPOINT.md work?
The file sits at the top level of the Agent Assets library, the same library that holds your site skills, and I name it SHAREPOINT.md in capitals. Whenever anyone starts a new chat with Copilot in SharePoint on that site, the file is read before Copilot answers. You write it in markdown with headings and lists, there’s no schema to fill in, and it changes as the site does. Add a library, add it to the map.
The quickest way to see what it does is to take it away. I set up two nearly identical sites with the same project template, the same Projects library and the same skill for creating a new project. On the site without SHAREPOINT.md, the skill built the folder structure straight into the default Documents library without a question. On the site with the file, Copilot confirmed the project name and destination, checked no project with that name already existed, and created it in the Projects library.
What’s the difference between SHAREPOINT.md and a skill?
A skill carries the steps for one task, and SHAREPOINT.md carries how this particular site works, so a skill can lean on the file for things like which library its output goes in.
| SHAREPOINT.md | Skill | |
|---|---|---|
| What it holds | Context and rules for the whole site | The steps for one repeatable task |
| Where it lives | Root of the Agent Assets library | Agent Assets/Skills/<skill name>/SKILL.md, or your OneDrive for a personal skill |
| When it loads | At the start of every conversation on the site | When a request matches its description, or you name it |
| How many | One per site | As many as the site needs |
| Example | “Projects are stored in the Projects library. Confirm the name and destination before creating one.” | “Create a new project from the template folder structure.” |
What SharePoint skills are and how to build one covers skills properly.
What goes in a SHAREPOINT.md file?
Anything every conversation on the site needs to know. Across my demo sites I’ve used:
- Purpose and ownership. My People and Culture site file opens by saying what kind of site it is and gives the site URL.
- A library map. Each library with its path, what it contains and any rules for it. This is the section that does the most work.
- Lists, content types and metadata. What each list or register is for, which content type a document should get and which columns to fill in.
- Naming conventions. The pattern for each kind of file, with an example.
- Filing help. A quick reference table for the confusions people actually have, like whether a strategy document goes in client work or reference.
- Behaviour rules. Where generated content is saved and when Copilot should ask before acting.
Zach Rosenfield from the SharePoint product team gave me a good test when I interviewed him: put something in SharePoint.md only if every response needs to know it. The rest of that conversation is in the real purpose of Copilot in SharePoint, and the save rule I use for dashboards is in building live dashboards from a Microsoft List.
What does it do in practice?
A naming convention in the file is enough for Copilot to tidy a library. Asked in the April video to rename every policy to the site’s convention, Copilot found the policies library and its eight files from the library map and checked two things first: sequential policy numbers, and whether to keep the Word format when the convention specified PDF. It then renamed all eight starting from P01, with a before and after summary.
A filing map turns the file into a guide for people saving documents. Asked where a strategy document should go, Copilot named the client work library, the strategy document content type and the topic, matter and strategy type to set, then opened the library.
How do I create a SHAREPOINT.md file?
You don’t have to write it from scratch. This is the route I used on a financial advice operations site in July:
- Ask Copilot in SharePoint to initialise the site. My prompt was “Can you please help initialise this site.” Copilot called a built-in initialisation skill that looked at the site’s libraries and content.
- Answer its questions. Its draft covered purpose, audience, naming conventions and libraries, plus a couple of open questions, which I answered with who owns the site and what its key document types are for.
- Review the draft and tell it to proceed. Nothing was written until I confirmed. Copilot then created the Agent Assets library, with its Skills folder, and saved SHAREPOINT.md in the root.
- Test it with a question the file answers. I asked for the naming convention for statements of advice and got the numbered pattern with topic slugs, with the example taken from the file.
You can still write the file yourself and save it in the root of the Agent Assets library, which is how I did it in April. You no longer need to activate Agent Assets under Site collection features first.
Give the file an owner and lock down who can edit it
Whoever can edit SHAREPOINT.md can change how Copilot behaves for every person on the site. A single line telling Copilot to save reports to Shared Documents would send every generated report somewhere the whole site can open it. I treat the file like site configuration, with one named owner and edit rights on the Agent Assets library restricted to that person and a backup. Breaking permission inheritance on the library does it, and covers the site skills in the same move.
The file guides Copilot and enforces nothing. Writing “don’t share HR files” into SHAREPOINT.md won’t stop someone with access sharing one, and nobody can see a document through Copilot that their permissions don’t already allow. If a rule has to hold, put it in permissions, retention or a sensitivity label, and use the file to explain it.
Keep task steps out of it. Every line loads into every conversation, so a long procedure here is noise for everyone asking about something else. Put the procedure in a skill, let SHAREPOINT.md carry the context that skill needs, and keep each rule in one place so nobody has to update it twice.
The library map can only describe the site you’ve got. If three libraries hold the same kind of document, the file either picks one and leaves the others orphaned, or writes the confusion down for Copilot to repeat. Fix the structure first, with SharePoint folders vs metadata and the free Copilot-ready library checklist, then map it.
Frequently asked questions
How do I know Copilot has loaded SHAREPOINT.md? In my tests a note in the chat says the experience has been customised for the site by SHAREPOINT.md. To check the content is being used, ask something only the file answers, such as a naming convention, and see whether the example comes back.
Can I have one SHAREPOINT.md for every site? In everything I’ve tested, the file is per site: it lives in that site’s Agent Assets library and loads only for conversations on that site. If several sites share rules, you’ll need to put them in each site’s file, so keep the shared part short and consistent.
Can I edit SHAREPOINT.md after Copilot creates it? Yes. It’s a file in a document library, so you can open and edit it directly or ask Copilot to update it. Version history keeps earlier versions, which is useful when a change makes Copilot behave differently and you need to see what moved.
