SharePoint: Two Sites, One Copilot Skill

Key insights

• SHAREPOINT.md changed the result in a side-by-side demo: two nearly identical sites used the same Copilot Skill, but on one site Copilot created the project in the default Documents library while on the other it read SHAREPOINT.md to confirm names and place the project in the Projects library.
  
• Agent Assets/Skills is where site skills live; Copilot reads files there as site context so a simple Markdown file can change how and where work is created and when Copilot prompts for confirmation.
  
• SharePoint Skill files are Markdown-based reusable workflows (not one-off prompts). They capture multi-step actions, run in site context, and respect existing permissions and compliance rules.
  
• The platform now supports two scopes: a site-scoped SharePoint Skill stored in the site’s Agent Assets for team use, and a personal skill stored in OneDrive that follows an individual across Microsoft 365 apps and content.
  
• Use a SharePoint Skill for standardized team processes on a single site and a personal skill for repeatable individual workflows across apps; for broader cross-system automation, consider Copilot Studio as the orchestration option.
  
• SHAREPOINT.md does not replace permissions: the file guides Copilot’s behavior but does not override SharePoint security or governance, so Skills remain subject to organizational governance and access controls.
  

Overview: A concise look at the video

In a recent YouTube demonstration, Daniel Anderson [MVP] explores how a single Copilot workflow can behave differently across two similar SharePoint sites. He titles the piece Two SharePoint Sites, One Copilot Skill: What’s the Difference?, and then shows that the change hinge is surprisingly small: one file named SHAREPOINT.md. The video is practical and hands-on, and it highlights how site-specific context can steer Copilot’s actions in unexpected ways.

The demonstration: what viewers see

Anderson walks viewers through two almost identical SharePoint sites that share the same project template, the same Projects document library, the same Agent Assets library, and the same Copilot Skill. On the first site, the skill creates a project immediately in the default Documents library, while on the second site the presence of SHAREPOINT.md causes Copilot to confirm the project name and destination, check for duplicates, and then create the item in the Projects library.

Importantly, the video shows where SHAREPOINT.md lives and how Copilot reads it as site context. Anderson demonstrates how the file works alongside SharePoint Skills to influence where work is created and when Copilot should ask for confirmation, while also noting that the file does not replace SharePoint permissions. Thus the demonstration is a useful reminder that small configuration files can affect AI behavior without altering security controls.

Key technical distinction: site skill vs personal skill

The video and accompanying notes explain the difference between a site-scoped SharePoint Skill and a personal skill that travels with the user via OneDrive. A site skill lives in the site’s Agent Assets library and serves users who have view access to that site, whereas a personal skill is stored in the user’s Microsoft 365 surface, including SharePoint search, Outlook, Teams, and files.

Consequently, although the Markdown file format is similar for both types of skills, the scope and ownership change the governance and reach. In short, what looks like the same workflow can become a team asset or a personal tool depending on where it lives, and that distinction matters for control, visibility, and reuse.

Tradeoffs: governance, flexibility, and discoverability

There are clear tradeoffs between centralized, site-level skills and personal skills that follow a user. On the one hand, site skills promote consistency and standard processes for teams, which improves auditability and makes it easier for administrators to maintain a single source of truth. On the other hand, personal skills give individual users rapid flexibility and productivity gains across applications, but they can create fragmentation and make it harder for IT to ensure compliance.

Moreover, organizations must weigh discoverability against control: shared skills are easier for a team to find and run, while personal skills can be invisible to others and harder to govern. Therefore, choosing between the two approaches involves balancing trust, policy, and the need for local custom behavior versus global standardization.

Challenges and operational considerations

Anderson’s video also highlights practical challenges, such as maintaining the accuracy of the contextual file and keeping workflows up to date as site structure changes. For example, if SHAREPOINT.md contains outdated instructions about where to place files or how to name projects, Copilot may prompt unnecessary confirmations or place work in the wrong library, which adds friction rather than saving time.

Additionally, teams should consider versioning, testing, and permissions: while the file informs Copilot how to act, it does not override SharePoint permissions, and administrators must ensure that skills live in the right location with the right access. As a result, governance processes and documentation remain necessary to manage lifecycle, handoffs, and audit trails.

Practical takeaways for IT and teams

For teams seeking to adopt Copilot in SharePoint, the video offers clear guidance: use site skills when you want repeatable, team-wide workflows and prefer personal skills when you want portable, user-specific automation. Also, include a well-constructed SHAREPOINT.md if you need Copilot to behave in site-specific ways, and test the behavior in a controlled site before wide deployment.

Finally, Anderson suggests that organizations think about maintenance and training, since skills require upkeep and users need to trust AI-generated actions. In conclusion, this demonstration shows that small files can have outsized effects on AI behavior, and that teams should plan governance and operational processes accordingly before scaling Copilot workflows.

Keywords

SharePoint sites differences, Copilot for SharePoint, SharePoint Copilot skills comparison, SharePoint site vs hub differences, Manage multiple SharePoint sites with Copilot, SharePoint Copilot integration guide, SharePoint site permissions Copilot, Deploy Copilot skill across SharePoint sites