Every team has repeatable work they want done the right way, not just once, but every time. Copilot can learn the way your team already works, follow the processes you trust, and help people repeat high-quality outcomes without starting from scratch every time.

That is the idea behind skills in Copilot in SharePoint. Skills are reusable instructions that teach Copilot how to perform a specific task, whether that is summarizing meetings, analyzing a SharePoint site, generating reports, reviewing documents, or preparing project briefs. Once saved to a SharePoint site, skills become a shared team asset that anyone with access to the site can invoke from chat.

For organizations, that means less repetitive prompting, more consistent results, and a growing library of expertise that can be reused across projects and teams. If you are new to skills, learn more at Teaching AI in SharePoint What to Know and How to Act and the Copilot in SharePoint adoption page. To help you get started, here are ten skills that show what is possible today and can help you turn proven processes into reusable capabilities for your team.

10 custom AI skills to try

Here are ten examples that show how skills can support common site owner, content owner, and business team scenarios. Use them as starting points, then adapt the pattern for your own team’s work.

1. Site Analyzer: Performs a comprehensive analysis of a SharePoint project site by reading lists and documents, then producing a tailored site audit, project health review, scorecard, or meeting briefing.
2. Knowledge Base Admin Report: Generates a knowledge base health report covering corpus overview, decay status, gaps, ingestion activity, expert coverage, and recommended next actions.
3. SharePoint List Styling:Transform SharePoint lists and document libraries into fully art-directed views using column formatting, view formatting, row templates, and tile layouts. Works with any style token file in this collection to produce "I can't believe that's SharePoint" results.
4. Scorecard Matrix: Creates a weighted heatmap scoring matrix for evaluations such as vendor selection, tool comparison, site-readiness grading, or competitive analysis.
5. Quarterly Expense Report: Reads vendor, date, and spend data from an Expenses library and generates an interactive HTML expense report for a specified fiscal quarter.
6.  Executive Report: Generates a polished executive report from SharePoint lists, CSVs, or a description, using narrative blocks such as KPIs, charts, tables, status grids, and highlights.
7. Project Brief: Turns a rough idea or stakeholder request into a structured project brief by clarifying the problem, goals, success criteria, scope, stakeholders, risks, and decisions needed.
8. RFP Response Generator: Drafts a complete proposal Word document section by section using the approved Strategy Brief as its blueprint, grounding every section in source documents before writing and inserting structured placeholders rather than inventing content where gaps exist.
9. Brand Style Guide Template: Provides a fill-in-the-blank template for turning an organization’s brand guide into an AI skill that can guide colors, typography, spacing, and component style.
10. Gap Analysis: Compares two documents and identifies what is missing, conflicting, changed, or new, with findings organized by severity and recommended action.

Two ways to get started

There are two simple ways to begin building a skill library. 

Option 1: Create a skill from your own instructions

If you already have a workflow your team repeats, start there. Tell Copilot in SharePoint the instructions you want it to follow, refine the output, and ask Copilot to save those instructions as a skill. A strong first skill usually has a narrow job: for example, “summarize this transcript into decisions and action items,” or “review this page draft against our editorial checklist.”

Option 2: Download and install an existing skill

You can also start from a skill someone else has already created – either one from the list linked above or others posted online.

The Agent Assets library is where a SharePoint site stores reusable assets for Copilot, including skills. If the library does not already exist, Copilot in SharePoint can create it for you. You can draft or download a skill anywhere, but to make it discoverable as a reusable skill for that site, the full skill folder — including its SKILL.md file and any supporting files — should be saved in the site’s Agent Assets library under Skills. If a SKILL.md file lives outside that location, Copilot may still use it as ordinary content when referenced, but it will not be treated as a reusable site skill in the same way.

Install a downloaded skill folder

1. Download the skill folder, such as writing/copy-editing/.
2. In your SharePoint site, open the Agent Assets library. If one does not exist, ask Copilot in SharePoint to create one.
3. Navigate into the Skills folder and upload your skill.
4. Ask Copilot in SharePoint to perform the skill. Copilot discovers the skill by the name field in SKILL.md and then follows the instructions in the skill.

What makes a good skill?

Every organization has workflows that a few people know by heart. Skills let you capture that knowledge once, store it where work already happens, and make it available to everyone else through Copilot in SharePoint.

The best skills are intentionally small. They focus on one job, contain the context needed to perform that job, and are documented clearly enough that Copilot can select the right skill at the right time.

As you build your own, keep four principles in mind:

• Focused: one capability per skill, not a grab bag of loosely related tasks.
• Self-contained: include the instructions, inputs, output format, and quality bar the skill needs.
• Clearly documented: use clear frontmatter, especially the name and description fields, so the agent can self-select the skill.
• Easy to maintain write it so another site owner can understand what it does and update it as the workflow changes.

A simple first project: turn one repeatable workflow into a skill

If you are wondering where to begin, pick one workflow your team already does repeatedly. A monthly report. A meeting summary. A content review. A project brief. A site audit. Then write down the steps your ideal teammate would follow and turn that into a skill.

Start small, test it with real content, and refine the instructions until the output is useful without a long back-and-forth. Once it works, save it to the SharePoint site where the work happens and let the team use it from Copilot in SharePoint.

That is the bigger opportunity with skills: not just faster prompts, but reusable team know-how. SharePoint becomes the place where the content lives, the work happens, and the instructions for doing that work well can be shared.

Availability note

Skills in Copilot in SharePoint are available in expanded public preview for users with a Microsoft 365 Copilot license.

Learn more

• SharePoint Showcase landing page
• Copilot in SharePoint adoption page
• Get started with Copilot in SharePoint
• SharePoint skills blog
• SharePoint skills library
• Watch more videos about skills in SharePoint

Be sure to check out our new monthly What's New in Copilot in SharePoint blog!

Product drops

Here's what's new in SharePoint this month, all now generally available:

SharePoint: Agent Access Insights heatmap for SharePoint and OneDrive sites: Provides a visual heatmap of agent activity to help admins quickly detect patterns, hotspots, and unusual access behavior. Roadmap 565027

AI-generated audio summary of SharePoint News: Users will be able access an AI generated audio summary of SharePoint News posts in the SharePoint app for Teams. Roadmap 562018

Generating documents using forms in SharePoint with Power Automate: This capability supports scenarios such as creating contracts, invoices, letters, or reports using structured templates and form-driven inputs. The action works by mapping input data to template fields and returns the generated document along with file metadata such as location and status. Roadmap 561026

Stay tuned every month for the SharePoint Showcase, where we share updates, best practices, and real-world examples of how SharePoint helps teams move faster, work smarter, and stay in control as AI reshapes work.

Apple is teaming up with Klarna to launch a lease-to-own program for its devices. Apple loses a bid to overturn Masino patent verdict. Apple is facing a lawsuit by customers who lost money through a fake Bitcoin wallet app in the App Store. And Apple is gearing up for a big smart home push.

• Apple's new hardware subscription sounds great, except for one limitation
• Apple loses bid to overturn $634 million Masimo patent verdict, new trial also denied.
• Judge approves Apple's $250 million settlement offer over Siri lawsuit.
• Apple just improved TestFlight for users with a lot of beta apps.
• Apple sued by customers who lost combined $1.8 million through fake Bitcoin wallet in App Store.
• Update Now: iOS 26.6 and macOS Tahoe 26.6 patch hundreds of security flaws.
• iOS 27 public beta 2 is here with Siri AI, iPhone speed upgrades, and more.
• watchOS 27 adds new feature to improve your Apple Watch battery life.
• Here's everything new for CarPlay in iOS 27.
• Here's everything new for Messages in iOS 27.
• Gurman's Mac roadmap.
• Apple set to make big smart home push with Siri AI at center.
• A.R. Rahman brings his immersive music experiences to Apple Vision Pro.
• Always choose the good soap.
• Apple promotes 'Nido de Villanas,' a Mexican microdrama shot on iPhone 17 Pro.
• Apple TV announces streaming date for its epic Neuromancer adaptation, new Dark Matter and Matchbox trailers.

Picks of the Week

• Leo's Pick: Twelve South PowerBug
• Christina's Pick: BookPlayer
• Andy's Picks: Casio WS-1600H
• Jason's Pick: Apple II Mini Replay

Hosts: Leo Laporte, Andy Ihnatko, Jason Snell, and Christina Warren

Download or subscribe to MacBreak Weekly at https://twit.tv/shows/macbreak-weekly.

Join Club TWiT for Ad-Free Podcasts!
Support what you love and get ad-free audio and video feeds, a members-only Discord, and exclusive content. Join today: https://twit.tv/clubtwit

Sponsors:

• cirasync.com/MacBreak
• zocdoc.com/macbreak
• cachefly.com/twit

More ways to use Azure Virtual Desktop! Richard chats with Travis Roberts about how Azure Virtual Desktop continues to evolve and provides more options for remote users. Travis talks about how AVD grew out of Terminal Services and so is still very much an IaaS offering - as opposed to Windows 365, which is more PaaS, with less flexibility, but easier deployment. But when you need control, AVD is the way to go, and today will operate in Azure, on-premises via Azure Local. And if you've got an existing virtual desktop infrastructure, AVD Hybrid opens the door to running in a hybrid environment across on-prem and cloud, or to providing a smooth migration path. Lots of choices!

Links

• Terminal Services
• Windows 365
• Windows 365 Flex
• Azure Virtual Desktop
• Windows Enterprise Multi-Session
• FSLogix
• Azure Local
• Azure Virtual Desktop on Azure Local
• Azure Virtual Desktop Hybrid
• AVD Personal Desktop Assignment

Recorded June 22, 2026

For the past six months my team has worked inside some of the largest API programs anywhere, the companies that both produce and consume the most APIs in the world. We got a close look at how they’re building for agents, and one thing became obvious fast. The audience for an API used to be engineers. Now the biggest consumer is a coding agent, and most programs haven’t caught up to that.

These teams spent years making their APIs easy for people to adopt, with real documentation, SDKs, developer portals, and specs. A new kind of consumer is now showing up at that same front door and reading everything differently. A coding agent doesn’t read docs the way a person does. It won’t email support when it gets stuck, it gives you no benefit of the doubt, and it only reads what’s machine-readable. When it can’t get your API working, it drops you and tries one it can.

So we built AI-Ready APIs, an assessment that measures how ready an API is for the agents that will consume it. It came out of what we saw in the field, what we learned inside Postman, and research on how agents actually read an API. You can point it at your own API and follow along as you read.

How developers used to choose an API, and how agents choose now

Think about how a developer used to bring an API into a product. They heard about it from a colleague, a talk, a search result, or a reputation built over years. They weighed it with judgment: past experience with the vendor, how good the support had been, a general sense of trust. Then they signed up, worked through onboarding, set up auth, and pushed on the integration until it ran cleanly in production. When a doc was wrong or an edge case wasn’t covered, they did what people do. They opened a ticket, asked a colleague, guessed at the undocumented field, or worked through examples until it made sense. A developer is a resilient reader. They work around the gaps you leave.

That same decision looks very different now. A developer describes the goal to a coding agent and the agent does the work. It researches which APIs fit, reads the specs and docs, forms a view, recommends one, and wires up the integration, often without the developer ever landing on your website. The discovery, evaluation, and integration a person used to do by hand now happen inside the agent.

If you own an API program, the consequence is direct. A developer who gets stuck files a ticket or emails someone. An agent that gets stuck picks a competitor, and you never find out. There’s no ticket and no abandoned signup to win back. It hit something it couldn’t get past (auth it couldn’t infer from the docs, an error it couldn’t parse, an endpoint whose behavior it couldn’t confirm) and moved on to the next option that worked. You lose inside a decision you were never part of, and it never shows up in a meeting.

And every gap a human used to absorb becomes a hard stop for a machine: a missing description, an ambiguous parameter, an undocumented edge case, a surprise rate limit, a 500 that returns an HTML error page instead of JSON. It stops at the same wall every time, for every developer whose agent hits it.

The best teams we work with don’t treat this as a threat. They think it’s the most interesting change to API programs in a decade, and they’re reorganizing around it instead of bracing against it. Agent traffic through their APIs is climbing fast, and those agents are making integration choices that turn into revenue. The programs that lean into that early are the ones that will set the norms everyone else follows.

What we kept seeing in the field

We built a real assessment because of a pattern we couldn’t stop running into.

The programs we sat inside had strong developer experience. Not a spec file and good intentions, but mature docs, SDKs in several languages, quickstarts that actually worked. And a lot of them were still hard for an agent to use. The APIs were fine. Agents and people just need different things, and nobody had been building for the difference.

A developer can open a rendered docs page, read a few paragraphs, guess what an error means, and keep moving. An agent needs the same information in a form it can actually consume: a machine-readable entry point that tells it where to look, docs it can pull as clean text instead of a JavaScript-rendered page, an error it can read as a code and a reason instead of a wall of HTML. A beautiful portal does nothing for an agent if the one thing it needed was never published where the agent looks, or in a format it can parse.

That gap is what the assessment measures. Good developer experience is the ground floor. On top of it sits a second layer that exists only for agents, and most teams haven’t built it yet, including very good ones. That’s the opening. The work is real and doable, and most of your competitors are still sitting in the same gap you are.

The two tiers of agent-readiness

Once the pattern was clear, we split it into two tiers. The score is organized around them, and so is the way we think a team should approach the work.

The first tier is API Product Foundations, the API design and developer experience most programs have already invested in: a well-designed, versioned contract, complete typed schemas, docs, quickstarts, code samples, and SDKs. None of it is agent-specific, and that’s the point. It serves both audiences. It’s what lets a developer onboard fast, and it’s the ground every agent interaction stands on. If you’ve done this work, you’re not starting over. Most of it carries straight forward, and it stays in the score because everything an agent does depends on it.

The second tier is Agent Journey Optimizations, the parts that exist only for agents. This is where the new work lives. An agent moves through many of the same stages a developer does (find the API, understand what it does, operate it), but the things it needs at each stage are invisible to a person. A machine-readable front door in llms.txt. Markdown versions of the docs it can fetch cheaply. RFC 9457 problem-detail errors it can parse instead of guess at. Discoverable auth metadata, schemas complete enough to drive a function call, an AGENTS.md that spells out how to work with the API. A human never sees any of it. It’s the whole difference between an agent using your product on its own and giving up.

So there are two layers. Developer experience underneath, agent experience on top. The assessment grades both, grouped this way, so you can see where you’re already strong and where the new work sits.

The assessment we built

AI-Ready APIs turns all of this into a score you can act on.

Point it at a domain. It finds the public API surfaces an agent would find, the same way an agent would starting from nothing: the spec, the docs, the SDKs, a CLI, an MCP server, the well-known files. Then it runs a set of concrete checks across them and hands back a graded report, with an overall grade, a breakdown across five categories, and the exact places an agent is going to get stuck.

It’s a new standard, but it builds on the developer experience you already have. An AI-ready API is one an agent can discover, interpret, and operate on its own, with no human in the loop. A developer fills in whatever you leave out. An agent only has what’s machine-readable, so the whole thing comes down to one question. How much of your API can an agent use without help? Every other design choice follows from that.

How the score works

The assessment uses only public sources. No inside access, no telemetry, nothing to install or grant. That’s deliberate. It puts the assessment where an agent actually stands, outside your domain, seeing only what’s publicly reachable. It probes the paths an agent would check, follows what it finds, and confirms each surface is real, reachable, and genuinely published by you before it counts for anything. If an agent can’t see it, neither can we.

The design choice that matters most is simple. The score rewards the best evidence across all your surfaces, not any single one. An early version docked any API that didn’t have a pristine OpenAPI spec. That was the wrong instinct. Plenty of strong programs prove what they can do somewhere other than a spec. Anthropic is the example I keep coming back to: excellent docs, a mature SDK, a real CLI, and no public spec. A spec-first grader would call that a weak API, which is obviously wrong. So the model doesn’t favor any single surface. A capability counts if any surface shows it, and we take the strongest evidence an agent could find, not the weakest. A team that’s strong on SDKs doesn’t get punished for skipping a spec, because an agent wouldn’t punish them either.

The rubric itself is static. We built it from Postman’s internal research and the field work our forward deployed team has done. Once the tool has pulled all your public surfaces, it runs a set of deterministic checks against them.

Altogether that’s 25 checks across five categories and seven surfaces, rolled into one grade on a ladder that runs from Agent-Optimized at the top, down through AI-Ready, Advancing, Building, and Emerging, to Not AI-Ready at the bottom. It’s a gradient, not a pass/fail line, so even a bare-bones API gets a real score and something to climb toward.

Two limits are worth stating up front. The score covers the surface area agents touch, not the overall quality of your product. It measures whether a capability is present, discoverable, and consistent across surfaces, not whether every operation behaves perfectly under every input. A genuinely strong product can still score low because it’s hard for an agent to read, and that low score is your map to fixing it. And being listed in Postman’s own catalog earns no credit. That’s a flag for whether your company is already in our API network as a discovery and GTM channel.

The five things an agent needs from you

The five categories follow the order an agent moves through a product: the foundation it stands on, then discovery, understanding, and operation.

API Design is about whether the contract is well built. An agent can’t call a function it has no schema for, and it can’t survive a breaking change to an API that never declared a version. This category grades whether the contract is machine-readable and versioned, how complete and typed the schemas are, and whether auth is declared in a way an agent can find. Complete, typed schemas are what make agent function-calling possible at all.

Developer Experience is about how fast a newcomer can onboard. People still choose and maintain these integrations, so the portal, the quickstart, and the code samples all matter, and they double as the agent’s route to its first successful call. The bar good teams hold is a useful one. Someone with no prior knowledge should be able to find the API, try it, and be making real calls within minutes. An agent holds you to the same clock, minus the patience.

Agent Discovery is whether an agent can find the API at all. This is where the agent-specific work starts. Before anything else happens the agent has to locate the API, and it doesn’t browse your marketing site. It crawls machine-readable entry points. This category grades llms.txt as the front door, whether you show up in the MCP and package registries agent tooling checks, and whether the docs are reachable instead of stuck behind a login. Think of it as the new SEO. The ranking signal isn’t your spot on a results page anymore, it’s whether an agent can integrate without getting stuck.

Agent Understanding is whether an agent can correctly interpret what it finds. Finding an API and understanding it are two different things. This category grades what decides whether an agent reasons about your API correctly or hallucinates against it: RFC 9457 errors it can parse without burning a retry, operation descriptions clear enough to pick the right endpoint, docs it can fetch as efficient text, and consistency across surfaces. When the spec, the docs, and the SDK each describe the same thing a little differently, a person shrugs and moves on. An agent choosing between endpoints is left guessing.

Agent Usability is whether an agent can operate the API safely, and it carries the most weight, because it’s where integrations actually break. Documented idempotency lets an agent retry a write without double-charging someone. Rate-limit headers let it back off instead of hammering you until it’s blocked. Consistent pagination lets it walk a collection without losing its place. A sandbox lets it try a destructive call with no consequences. Everything upstream gets the agent to the point of making real calls. This category decides whether those calls succeed.

How Postman helps you close the gap

Seeing the gap is only half the job. The other half is closing it, and that’s more straightforward than it looks, because agent-readiness breaks down surface by surface and so do the fixes.

It starts with the spec. Every surface an agent reads (the docs, the SDKs, the CLI, the MCP tools) is only as good as the definition behind it, and the problem we see almost everywhere is a dozen slightly different sources of truth all drifting away from the live API. Postman’s governance tooling pulls them back together. It lints and standardizes the spec as it’s written, enforces the same rules in CI, and keeps a live catalog of every API you have. Fix the spec and consistency, complete schemas, and clean errors all improve across every surface at once, including the specs AI is increasingly writing, which governance keeps honest.

From a clean API spec, Fern from Postman, generates surface areas for agents to integrate with your platform. It generates Docs that serve llms.txt by default so agents discover your product over your competitors. Its SDKs cover nine languages, handle retries/pagination/auth and are written to be idiomatic so agents can integrate with your platform. And finally, it’s CLI adds a JSON output mode built for agents so your customers can build workflows that leverage your business logic. Fern is the platform to enable additional agentic surfaces for your APIs all with one spec.

Postman itself becomes the place agents and teams build from. Public workspaces and the API Network are discovery surfaces an agent can reach. Mock servers and sandboxes give it a safe, production-like place to try things. And the workspace acts as a context layer for coding agents directly: Claude Code, Cursor, and Codex pull specs, examples, tests, and auth patterns straight from it, so the same context that makes a developer productive makes their agent productive. Most of the work that makes an API great for agents is the same work that makes it great for the developers driving them, so you’re extending the product you already have rather than building a new one.

Where this goes next

None of this needs a new standard. The ones agents need already exist: OpenAPI for contracts, MCP for tools, OAuth for auth, RFC 9457 for errors, and llms.txt as the emerging front door. What’s left is adoption. Take what’s already here and use it consistently across every surface an agent can reach. That’s a much more tractable problem than it sounds, and you can start this week.

For years your API’s reader was a person who would fill in whatever you left out. Now it’s an agent that won’t, and it’s already making integration calls for your customers whether you’re ready or not. The teams pulling ahead are the ones treating this as part of the product they already own instead of a side project labeled “AI.” Agents are going to keep picking APIs. I’d rather we be one they pick.

Scan your ecosystem. It takes a few minutes and gives you a concrete map of where an agent gets stuck, and a clear sense of what to fix first.

The post AI-Ready APIs: Agents Are the New Audience appeared first on Postman Blog.

Learn what's new in Visual Studio Code 1.132 (Insiders)

Read the full article