There is already a good technical guide to Copilot Cowork skills. It covers every built-in skill and walks through the SKILL.md file format, scores quality dimensions, and documents the plugin catalog. It is written for power users who want to build things.
It is not written for the IT administrator deciding, before any user touches the product, which skills should be on, which should wait, what governance needs to be in place first, and what happens when a custom skill does something nobody expected. That is the gap this article fills. The skills are the mechanism. Governance is the job.
TrustedTech works with organizations deploying Microsoft tools at scale as a CSP Direct Bill Partner and Solutions Partner. The patterns here reflect what actually causes problems in enterprise Cowork rollouts, not just what the documentation describes. If you have not yet decided whether Cowork belongs in your environment at all, our breakdown of whether Copilot Cowork is worth it is the place to start before you get into skills governance.
Start Here: Cowork Is Off by Default for a Reason
Every guide to Cowork skills eventually reaches the Customize panel in the M365 Copilot app, where users toggle individual skills on and off. That is the wrong starting point for enterprise IT. The right starting point is the Microsoft 365 Admin Center, where Cowork is disabled at the tenant level until an admin explicitly enables it.
Cowork is off by default because it sends emails, creates documents, schedules meetings, and posts to Teams on users’ behalf. Before any of that can happen, there are decisions to make: which users get access, what spending limits apply, and which actions need additional guardrails. The default-off state is not friction to eliminate quickly. It is the space for doing the governance work.
The correct sequence before any user sees a skill toggle: link an Azure subscription in MAC under Copilot > Cost Management and set a default spending policy; scope initial access to a pilot group rather than the full M365 Copilot population; configure per-user spending limits and threshold alerts; define which skills and plugins are available to the pilot. Only after that does the skill-level conversation become relevant.
For the billing setup and credit budget methodology, see our post on Copilot Cowork pricing and how to budget before you enable it. This article picks up after that infrastructure is in place.
What Skills Actually Are, and Why the Distinction Matters for Governance
A prompt tells Cowork what to do right now. A skill teaches Cowork how to do something whenever the conversation context matches its trigger, without the user needing to be re-prompted each time. That is a meaningful difference from a governance standpoint.
A skill that fires automatically based on context is not the same as a user consciously choosing an action. If the trigger phrases are too broad, the instructions are poorly scoped, or the guardrails are insufficient, it can activate in situations the author never intended. In a personal productivity tool that produces slightly incorrect output. In an enterprise tool that sends emails on behalf of a senior leader or schedules meetings with external attendees, it may produce something that requires an explanation.
Skills also chain. One can hand off to another, building multi-step workflows where the credit cost and the potential impact of an error both compound as the sequence lengthens. Skill governance is not about restricting what users can do. It is about being deliberate before autonomous actions run at scale.
The 13 Built-In Skills: A Risk and Value Map for Admins
Every tenant gets 13 built-in skills across five categories, with one enabled by default for users with Cowork access. Admins can disable individual built-in skills at the tenant level or within group policies. The useful frame is not “which skills should we turn on?” Most of them should be on. The useful framing is: “Which ones warrant a governance conversation before broad rollout, and what does that conversation look like?”
Documents: Word, Excel, PowerPoint, PDF, HTML
Five skills that create, read, and edit files. Lowest governance complexity in the built-in set: outputs go to OneDrive and SharePoint under the user’s existing permissions, and the actions are file-scoped. A Word document Cowork created that turns out to be wrong can be corrected before it is shared. An email Cowork sent that is wrong has left the building.
Start here. Enable the document skills broadly for the pilot group and use the outputs to build user trust in Cowork’s quality before extending access to communication and calendar-write skills. They produce tangible deliverables that can be reviewed before use, and the approval gate for file creation carries lower stakes than the approval gate for sending or posting.
Calendar: Scheduling, Calendar Management, Meetings, Daily Briefing
Meetings and Daily Briefing are read-and-synthesize skills: meeting intelligence from transcripts, a morning aggregation of calendar, email, and Teams signals. Enable these broadly for the pilot group.
Scheduling and Calendar Management are different. They can create, modify, and decline meetings on behalf of the user. A declined meeting invitation or a rescheduled recurring event on an executive’s calendar is visible and not trivially reversed. In TrustedTech’s experience deploying M365 tools with calendar integration, the organizations with the fewest problems are those that apply the same scrutiny to calendar-write actions as they do to email-send actions. For users who run back-to-back external meetings, enabling these skills warrants a specific conversation about how the approval gate will be used in practice before access opens, not after.
Communication: Email, Communications
The Email skill drafts, replies, forwards, and sends through Outlook. Communications handles broader stakeholder messaging. These two carry the highest governance weight of any built-in skill because a sent email is sent. There is no undo.
Cowork’s approval gate handles this by design: before sending, Cowork pauses, shows a preview, and requires explicit user approval. Medium- and high-risk actions include a risk-level indicator. Users can approve once, skip future prompts for similar actions in the same conversation, or cancel entirely. The problem TrustedTech sees in practice is not a technical failure of the approval gate. It is that users treat the approval screen as a speed bump and click through without reading the preview. An organization that enables the Email skill without explicit user training on that specific behavior is accepting an outcome it may not have anticipated.
Enable the Email skill for the pilot group, but treat the approval-gate training as a deployment requirement rather than a nice-to-have. Track early usage for any cases where an approved email required follow-up correction. That is the data the pilot period exists to collect.
Intelligence: Enterprise Search, Deep Research, Adaptive Cards
Enterprise Search retrieves information across the organization’s content. Deep Research synthesizes multiple sources into a structured brief. Adaptive Cards render interactive content in the conversation. All three are read-and-synthesize: an incorrect search result or a research brief with a wrong citation is a quality problem, not an irreversible-action problem.
Enable these broadly. The governance consideration for Enterprise Search is the same one that applies to M365 Copilot generally: Cowork surfaces content that the user already has permission to see. Whatever SharePoint permission sprawl or oversharing exists in the environment will show up in search results. That is a data hygiene problem to address before deployment, not a skill-level setting to adjust.
Automation: Goal, Skill Management
These two generate the most questions in IT forums. A goal sets a standing objective that Cowork keeps working toward until a defined condition is met or the effort limit is reached. Skill Management lets Cowork create and manage other skills on the user’s behalf.
The community anxiety about “infinite loops” and “runaway spend” traces directly to these two. A Goal skill without a well-defined stopping condition can accrue credits until it hits the user’s spending cap. Skill Management that creates a poorly-scoped skill can produce trigger phrases that fire in unintended contexts. Neither of these is a reason to disable the skills. Both are reasons to have spending limits and threshold alerts configured before any user interacts with them, and to include in the pilot training what a standing goal is and how to set an appropriate effort limit.
Plugin Governance: The Entra App Approval Framework Applies Here
Plugins extend Cowork beyond M365 into external systems. The nine GA partner plugins (Enosix, Harvey, LSEG, Miro, monday.com, Moody’s, Morningstar, S&P Global Energy, TeamsMaestro) plus Microsoft’s first-party Dynamics 365 and Fabric IQ plugins represent a meaningful expansion of capabilities. They also open new data access surfaces that need governance to match.
Tenant admins must approve plugins before users can install or use them. The mental model that works well in practice: evaluate a Cowork plugin the same way you evaluate an Entra ID app approval request. What data is it requesting access to? Are the data handling commitments compatible with the organization’s compliance requirements? Does it need read-only access or read-and-write access to external systems?
A few specific plugins warrant extra scrutiny before approval.
The financial data plugins, LSEG, Moody’s, Morningstar, and S&P Global Energy, provide access to market and research data. For organizations in regulated industries, confirm that using these through an enterprise AI system is consistent with the organization’s existing data usage agreements with those providers.
Harvey provides legal AI capabilities. Legal workflows involving client data carry confidentiality implications that go beyond standard enterprise data governance. Involve legal in the approval decision rather than treating it as a routine IT app review.
Monday.com, Miro, and TeamsMaestro are read-and-write integrations. Cowork can create and modify content in those external systems, not just pull from them. Verify that write-back permissions are appropriately scoped and that the external system’s audit logging meets the organization’s accountability requirements before approving.
The practical starting sequence for most enterprise IT teams: approve and enable Microsoft’s first-party plugins (Dynamics 365 suite, Fabric IQ) for the pilot group first, since those remain within the Microsoft security boundary. Evaluate third-party plugins individually using the Entra app approval framework, and enable them for the pilot group before any broader rollout.
Custom Skills: Answer the Governance Questions Before Users Start Building
Users can create up to 50 custom skills each by placing SKILL.md files in their OneDrive at Documents/Cowork/Skills/. Cowork discovers them automatically. Microsoft does not validate custom skills.
That last point matters more than it looks. A custom skill that sends emails or schedules meetings runs through the same approval mechanism as a built-in skill. The quality of the output depends entirely on how well the skill was written. Microsoft’s skill scoring system generates a quality report after creation covering trigger clarity, instruction specificity, scope boundaries, and robustness, but the score is advisory. A skill that scores 91/100 can still produce wrong outputs in edge cases that the author never anticipated. The pilot period exists precisely to find those cases before a skill runs at scale.
Four governance questions to answer before users start building:
Who owns the skill file? A SKILL.md in a user’s OneDrive leaves the organization when the user does. For skills representing institutional workflows rather than personal productivity, that is a retention and continuity problem. Skills meant to persist across the organization belong in a shared SharePoint location with proper access controls, or are published through Copilot Studio, where IT formally governs them.
Who reviews the quality score before a skill is shared? For personal skills, the creator reviews the report. For skills shared with a team or deployed org-wide, someone with the authority to approve or reject the deployment should review the score and the safety flags, particularly people-profiling scope warnings and irreversible-action flags. A lightweight checkpoint, not a compliance review, but it needs to be a named step.
What is the escalation path when a skill produces an unexpected output? Who does a user contact if a custom skill sends an email they did not intend to approve? Who can disable a skill that is causing problems? These questions have obvious answers in organizations with mature IT governance. The point is to answer them explicitly before Cowork goes live, not to work out the process during an incident.
What is the policy on sensitive-scope skills? Microsoft’s skill scoring flags “people-profiling” scope for skills that read and classify data about other employees, and “external-data-egress” for skills that write to systems outside the tenant. These flags do not block the skill from running. They are informational. Decide whether skills with those flags require an additional approval step before they run against real organizational data, and document that decision to ensure consistency across teams.
The three extensibility paths carry different governance implications. OneDrive SKILL.md files (no-code, personal) are the lightest-weight option with the least organizational control. Copilot Studio (low-code, admin-deployed) gives IT formal control over what gets published and to whom. The M365 Agents SDK (pro-code) is for developer-built integrations with line-of-business systems and is subject to the most rigorous governance requirements. Match the path to the use case’s governance maturity, not just its technical complexity.
The Runaway Spend Question: What Actually Happens and How to Stop It
The “infinite loop / $20,000 bill” concern that surfaces repeatedly in IT forums is not paranoia. It reflects a legitimate anxiety about handing users autonomous execution capabilities who have not internalized what “runs until the condition is met” means in a consumption-billed system. The fear is reasonable. The answer is three admin controls, all of which must be in place before users gain access.
Per-user monthly credit caps. The MAC Cost Management console supports user-level spending limits set within a group policy. A cap of $75–$100/user/month provides enough credit capacity for meaningful Cowork usage across light and medium tasks while preventing any single user from running up a surprise bill, even if a Goal skill runs longer than intended or a heavy task takes more compute than expected.
Threshold alerts before the cap is reached. Configure alerts at 50% and 80% of the monthly cap to notify a designated admin recipient. Two intervention points before a user hits their limit, not one discovery after the billing cycle closes.
The discoverability toggle. MAC includes a setting that controls whether users outside the pilot group can see or request access to Cowork. Disable it for the initial rollout. This closes the path where a non-pilot user finds Cowork through a colleague, enables it themselves, and runs tasks before governance is configured for their group.
When a user reaches their credit cap, the limit applies only to new tasks. Tasks already in progress run to completion. The user can submit a credit request within Cowork, which is routed to an admin for approval. The escalation path is auditable.
The spend scenario that is harder to catch through controls alone: a skill or scheduled prompt that runs correctly but more expensively than anyone estimated. A weekly Monday status briefing at 150 credits costs $0.60 per user per week, which is fine. A standing goal running a nightly deep research synthesis at 2,000 credits costs $80 per user per week, which is a workflow design problem. The spending cap will catch it, but only after the first week. Review the credit consumption of any scheduled or standing skill during its first week of operation before assuming it will run at a manageable cost indefinitely.
A Practical Day-One Enablement Sequence
For an enterprise IT team enabling Cowork for the first time, this sequence reflects both Microsoft’s partner guidance and what TrustedTech has seen work in practice.
Before enabling access for anyone: configure billing in MAC (Azure subscription linked, default policy active); define the pilot group (10–20 users across two or three personas likely to generate clear ROI); set per-user and per-group spending limits; configure threshold alerts at 50% and 80% of cap; disable Cowork discoverability for non-pilot users; decide whether any built-in skills should be scoped out for the pilot at the policy level.
Enable broadly for the pilot group: all five document skills (Word, Excel, PowerPoint, PDF, HTML); all three intelligence skills (Enterprise Search, Deep Research, Adaptive Cards); Meetings and Daily Briefing from the calendar set.
Enable with explicit training: Email and Communications, with users understanding that the approval preview is a genuine review step; Scheduling and Calendar Management, with users understanding the approval gate for calendar-write actions, particularly those with external attendee exposure.
Enable with active monitoring: Goal and Skill Management, with per-user credit caps in place and weekly review of consumption for any standing goals or scheduled skills in the first month.
Plugins: approve Microsoft’s first-party plugins (Dynamics 365 suite, Fabric IQ) for the pilot group if those systems are in use. Evaluate third-party plugins individually using the Entra app approval framework before enabling any of them for any users.
Custom skills: allow personal SKILL.md creation for pilot users from day one; it is an individual OneDrive action with individual-level credit exposure. Establish the review and approval process for any skill intended for team- or org-wide use before it begins. The first shared custom skill should not be the one that retroactively defines the governance policy.
After 30 days: review credit consumption by user, skill, and task type. Find the five workflows generating the most credit spend and confirm the time savings justify the cost. Identify any skills consuming more than modeled and decide whether a workflow redesign or scope adjustment is warranted. Use that data to make the expansion decision on additional users, personas, skills, and plugins.
The Data Environment Question That Comes Before All of This
Every skills decision in this article assumes that Cowork’s outputs are reliable enough to be worth the governance overhead. That assumption depends entirely on the quality of the M365 data environment Cowork grounds against, as measured through Work IQ.
Enterprise Search, meeting intelligence, email synthesis, and account prep briefings all draw from emails, files, calendar, and Teams content. Sprawling SharePoint permissions, years of outdated documents, and inconsistent sensitivity labeling all show up in the outputs. The Enterprise Search skill can retrieve files that should have been archived years ago. The Email skill can synthesize context from threads that include conversations the user forgot were in scope. The Deep Research skill can surface SharePoint content that was technically accessible but effectively invisible until an AI went looking for it.
In the M365 Copilot deployments TrustedTech has reviewed where IT teams were dissatisfied with output quality, the cause was almost never the AI capability. It was a data environment that was not ready to reliably ground AI outputs: permissions too broad, document libraries never governed, and sensitivity labels applied inconsistently. Cowork surfaces those problems faster and more visibly than standard Copilot because it acts on what it finds rather than just reporting on it.
Fixing data environment issues is outside the scope of a skills governance guide. But the skills enablement decision should not happen without an honest assessment of whether the environment is ready for it. TrustedTech’s Copilot Readiness Assessment evaluates SharePoint governance, permission structure, sensitivity labeling, and data hygiene before any Copilot or Cowork deployment, so the skills governance work and the data governance work happen in the right order.
Frequently Asked Questions
Q. Can admins disable specific built-in skills for certain user groups?
A. Yes. Built-in skills can be toggled off at the tenant level or within group policies in MAC Cost Management. A disabled skill will not activate for users covered by that policy, even if they ask for it by name. This lets admins make the document and intelligence skills available broadly while keeping communication or calendar-write skills off for groups that are not ready for them, without disabling Cowork entirely.
Q. How do users know which skills are running during a conversation?
A. The Cowork side panel updates in real time as skills load. A message appears in the conversation when a skill activates (“Preparing to compose emails”), and the skill name shows in the side panel. Users can also ask Cowork directly: typing “What built-in skills do you have available?” returns a grouped list of all active skills with one-line descriptions, including any custom skills the user has added.
Q. What is the custom skills limit per user?
A. 50 custom skills per user, stored as SKILL.md files under 1 MB each in OneDrive at Documents/Cowork/Skills/. Cowork discovers them automatically at the start of each conversation. Microsoft does not validate outputs from custom skills; review them carefully before acting on results, especially for skills that take communication or calendar actions.
Q. Should we wait for Cowork 1 before deploying skills that run heavy tasks?
A. If the cost of credit is the primary concern, waiting is reasonable. Microsoft’s Cowork 1 model, built for everyday tasks at substantially lower credit consumption than Opus 4.8, releases in the weeks after GA. Skills running frequently on heavy models will cost noticeably less once Cowork 1 is available. Starting a pilot now and expanding after Cowork 1 launches gives organizations real learning from the pilot, along with better ongoing economics for the broader rollout.
Q. When should a custom skill move to Copilot Studio instead?
A. When it needs to scale beyond a single user or small team, when it requires formal version control and publishing governance, or when it needs to run under an identity and access model that the SKILL.md format cannot provide. The practical sequence: build and validate in Cowork as a personal skill, confirm the workflow is worth scaling, then publish it through Copilot Studio with the governance infrastructure (audit logging, role-based access, versioning) that a shared organizational asset requires.
The Short Version
The job for enterprise IT with Copilot Cowork skills is not to unlock everything and let users discover what works. It is to make deliberate decisions about which capabilities go to which users, with what guardrails, in what sequence. Document and intelligence skills are low-risk starting points. Communication and calendar-write skills carry real governance weight because their actions cannot be undone. Automation skills require spending controls to be in place before anyone interacts with them. Plugins need the same scrutiny as Entra app approvals. Custom skills need an ownership, review, and escalation policy before the first one gets shared beyond a single user.
None of that is complicated. It is a standard enterprise IT deployment discipline applied to a new kind of tool. The organizations that run into problems with Cowork are mostly those that skipped the governance sequence because the product seemed straightforward and the pilot window felt urgent.
If you are preparing a Cowork deployment and want support structuring the admin enablement sequence, configuring spending controls, or assessing your M365 data environment before skills go live, TrustedTech’s team works through exactly this kind of pre-deployment planning as part of our Copilot practice.
