Three skills, one tracking list, one source folder — and the brief comes back fully cited. Here's exactly what happens at each step, and how to drive the model when you want to.
Step one is provisioning the SharePoint list the rest of the pipeline writes into. The List Creator skill spins up a list with three columns: the assertion itself, the citation, and which source file the citation came from.
The list is a contract. Once it exists, the other two skills know exactly where to put their output. Without it, the extractor would have nowhere to drop records, and the citation finder would have nothing to process.
With the list ready, the Assertion Extractor skill takes the brief file as input. It walks the document, identifies each standalone factual claim, and creates one list record per assertion. The citation column is left blank on purpose — that's what the next step looks for.
Open the list in a second tab while the extractor runs and hit refresh. Records appear one by one as the model works through the document.
The third skill — Citation Finder — gets pointed at the source folder and told to process every record in the list with an empty citation. For each blank row, it searches the folder, picks the best-matching passage, and writes both the citation and the source file back into the row.
This is the only step that touches the evidence library. It's also the slowest, because the model has to actually read the source documents. When it finishes, it prints a short report summarizing what it cited and what it couldn't.
The finished list pairs each assertion with the specific passage that supports it. Not just a file name — the actual sentence or paragraph quoted out, so the user can verify the match without opening the source.
From there the table becomes raw material. Export it, paste it into a footnotes section, feed it into a new document. The structured shape — one row per claim, one citation per row — is what makes those downstream uses easy.
The AI in SharePoint can usually figure out which skill to use from context alone. In this workflow, the user names them anyway — "use the assertion extractor skill," "use the citation finder skill" — because they're driving a very specific process and want zero ambiguity.
Explicit invocation is also good for teaching. New teammates watching the demo learn the skill names by hearing them used. Once the skills are familiar, the verbal step can drop away and the model picks them up from context.