Why seven skills, not one.
Why one monolithic skill became seven focused ones, and why conditional reference loading keeps context lean.
The monolith that didn't work
The first version was a single skill file. It covered everything: template extraction, deck building, auditing, critique, polishing, and editing. 2000+ lines. It didn't work well.
The problems fed into each other. Loading 2000 lines of instructions to perform a text edit meant the agent's context was dominated by irrelevant content. It would sometimes follow build instructions when it should have been editing, because the build section was longer and more detailed. Context length doesn't just cost tokens, it creates interference between unrelated instructions.
The reference material was tangled too. The build workflow needs storytelling principles and layout patterns. The audit workflow needs font contracts and overlap thresholds. The critique workflow needs MECE (mutually exclusive, collectively exhaustive) guidelines. When all of these lived in one skill, it was unclear which reference material applied to which step. The agent would sometimes apply critique standards during the build phase, producing over-cautious output.
And users don't always want the full pipeline. Sometimes they have a deck and just want to run QA. Sometimes they want to extract a template without building anything. A monolithic skill forced the agent through the entire sequence regardless.
The split into seven skills mirrors how consulting teams actually work. The strategist who writes the narrative isn't the same person who checks font sizes. The designer who reviews visual hierarchy isn't the same person who adds speaker notes. Seven skills, seven roles.
Conditional reference loading
The build skill has eight reference files: storytelling, content density, layout patterns, chart best practices, framework patterns, process diagram patterns, operations reference, and common mistakes. About 1500 lines total.
Loading all of them for every deck is wasteful. A text-heavy strategy deck doesn't need chart patterns. A simple status update doesn't need framework patterns. Context tokens spent on irrelevant references are tokens unavailable for the actual content of the deck.
So four references load every time (storytelling, content density, layout patterns, operations) because they apply to every deck. The rest load conditionally based on what the plan contains. If the plan includes chart slides, chart-patterns.md loads. If not, those 400 lines stay out of context.
It's lazy loading for agent instructions. The cost of loading an unnecessary reference file isn't a speed penalty, it's a quality penalty. More irrelevant context means more interference and more mistakes. Build quality improved noticeably once this was in place.