Sales teams produce a weekly review every Monday. Pull the numbers, format them, present them, ship them. Same shape every week, same questions answered. Half the work is the analysis. The other half is making the output look the way the executive team expects.
I built a SharePoint AI Skill that handles the analysis. I built another that holds the design system. Both load when a sales rep selects a spreadsheet and types "weekly review". The output is a branded HTML report saved to the documents library, on brand, interactive, ready to present.
This walks through the chained-Skills pattern using the weekly sales review as the example. The same structure applies to any recurring report your team produces from data in SharePoint.
For the basics of Skills, see what SharePoint AI Skills are. For where Skills sit in the wider Microsoft AI stack, see the pillar on extending SharePoint AI with Skills.
What chaining means in practice
Chaining means more than one Skill is loaded and applied in a single prompt. The prompt does not need to name both. AI in SharePoint resolves which Skills are relevant on the site, loads them, and applies them together.
In this example two Skills run in the same prompt:
- A weekly narrative review Skill that reads the sales spreadsheet and produces the structured analysis.
- A design system Skill that defines how the output should look. Brand colours, fonts, layout rules, component patterns.
The first one knows what to write. The second one knows how it should look. Neither needs to know about the other directly. The user prompts "weekly review" and gets the combined output.
The setup
Both Skills live in the same site's Agent Assets library, in their own folders.
/Agent Assets/Skills/
├─ Weekly Narrative Review/
│ └─ SKILL.md
└─ Design System/
└─ SKILL.md
The weekly narrative review Skill defines the analysis: which columns to read, how to summarise performance, what categories and regions to break down by, what areas of concern to flag. It also references the design system Skill for output formatting.
The design system Skill carries brand-level rules. Colour palette, typography, spacing, layout for the performance snapshot, chart styling, table styling, dropdown components, the lot. It is written for HTML output and stays focused on look and feel.
Running the chained Skills
The trigger is short. A sales rep:
- Opens the documents library on the site.
- Selects the sales spreadsheet for the week.
- Opens AI in SharePoint chat and types "weekly review".
That is the whole user-facing interaction. AI in SharePoint loads the weekly narrative review Skill (matched on the trigger). The narrative Skill calls the design system Skill (referenced from inside its SKILL.md). Both load. Both run.
The agent reads the spreadsheet. It runs the analysis according to the narrative Skill. It generates the output as branded HTML according to the design Skill. It saves the file back to the documents library where the source data lives.
What the output looks like
The HTML report opens in the browser. Top to bottom:
- A performance snapshot at the top. Headline numbers in branded cards.
- Charts for trend, mix, and category performance. Branded colours, branded fonts.
- Category, region, and channel breakdowns as tables and visualisations.
- Areas of concern flagged with the design system's warning treatment.
- A top-10 dropdown of products, interactive, expandable.
- Recommended actions at the bottom, framed in the team's voice.
Same shape every week. Same look. Same interactive components. The data changes; the format does not.
Why split it into two Skills
The temptation is to put everything in one Skill. One file, one set of rules, one trigger. It works. It also locks you in.
Splitting earns its keep at the second report. The design system Skill is reusable. Pair it with a finance Skill and you get a branded financial summary. Pair it with a project status Skill and you get a branded project report. The look stays consistent across every report on the site because every report runs through the same design Skill.
If the brand changes (new colour palette, new chart treatment), one file updates and every chained report picks up the change. If the analysis changes, only the analysis Skill is touched.
This is the same separation-of-concerns logic as reference files in SharePoint Skills, one level higher. Reference files share content within a Skill family. Chained Skills share whole Skills across reports.
Where to take this next
Pick a report your team produces every week or every month. The data lives somewhere in SharePoint. The format is consistent (or should be). The work currently sits in a person's head or a half-maintained template.
Write the analysis Skill first. Get the structure right and ship it. Then write the design system Skill, applied to the same report. When you are happy, point another report at the design Skill and confirm it produces the same look.
You have the start of a reusable reporting layer for your site. Anyone on the team can run it. The output lands the same way every time.