Framing

This is the composition sub-insight of skill chaining — the architectural case for modularity layer. The orchestration sub-insight covers the operational mechanics; the scoping sub-insight covers the discipline of when to chain. This sub-insight names the underlying claim: a chain of small, single-responsibility skills sharing common modes outperforms one large skill that tries to do everything — for the same reasons modular software outperforms monoliths anywhere else.

Core Idea

The monolithic approach is the natural first iteration of anything sophisticated. You build it all in one place because you’re not sure what the parts are yet, because modularity requires clarity about boundaries, and because when you’re exploring something new, forcing premature structure is more costly than just getting the thing to work. The monolith is fine as scaffolding. It becomes a problem when it needs to evolve.

A monolith skill has several characteristic failure modes. It uses the entire context window every time it runs, even when only a fraction of its functionality is needed. It’s difficult to update one part without risking breaking another. It’s opaque — when something goes wrong, diagnosing the problem is hard because everything is in one undifferentiated mass. And it’s not composable: you can’t combine it with other skills, because it doesn’t have a clean interface.

The composition principles that make modularity work:

The concrete pattern Lou demonstrated with GEARS: one monolithic skill became three skills (initialization, onboarding, content generation) sharing common modes (specialized sub-functions stored at the same directory level, loaded only when their parent skill needs them). Progressive disclosure at the operational layer: load what you need, when you need it.

Practical Application

For one current AI workflow that has grown into a monolith:

  1. Identify the distinct stages. What clearly different jobs is this single skill doing? Initialization vs ongoing work? Discovery vs synthesis? Drafting vs review? Name the jobs.
  2. Extract one stage into its own skill. Pick the most independent one — the stage with the cleanest input/output and the least dependence on the rest. Move it to its own skill file.
  3. Identify shared resources. What did the original monolith use that multiple stages need access to? Frameworks, brand voice, client data, templates. Move these to a shared modes/ or references/ folder at the same level as the skills.
  4. Connect via a structured object. The skills don’t call each other — they read and write to a shared object (a file, a database record, a structured frontmatter document). Composition through state, not through coupling.
  5. Iterate. Once one extraction works, do the next. The progression from monolith to fully-modular usually takes 2–4 passes — that’s normal.

Sibling Sub-Insights

This is one of three sub-insights from splitting Insight - Skill Chaining — Build Modular AI Pipelines Instead of Monolithic Prompts on 2026-05-22:

Evolution Across Sessions

The composition principle assembled across multiple sessions: separation of concerns surfaced as a recurring engineering discipline, the structured-object communication pattern named the handoff mechanism, the functional agent organization scaled the pattern to whole businesses, and the ambient architecture sub-insight (from the 2026-05-22 Ambient Intelligence split) named the environment in which composition operates. Skill Chaining was the synthesis that pulled them together. Future sessions should test what happens when composition is taken too far — at what point does a skill set become so granular that orchestration overhead exceeds the modularity benefit?

Source