The Ambient Library Needed a Skill That Designs Skills

How one forked writing-team experiment became capability-architect, a reusable process for generating modular AI capabilities inside the global library.

This article belongs with the ambient intelligence foundation. If that concept is new, start with I Thought the Chat Was the Intelligence. Then the Folder Became the System.

The question here is what happens after you have a global library of reusable capabilities.

At first, I was adding capabilities manually. That worked for one or two skills, but it raised a deeper question: if ambient intelligence depends on reusable capabilities, shouldn’t there be a capability that helps design those capabilities?

The forked writing team supplied the concrete example. It worked. It kept the parent context clean. It separated coordination from execution. It moved large artifacts by path instead of dumping them into the conversation.

Then the broader question appeared:

Was this just a better writing pipeline, or was it a pattern for building any serious AI capability?

I asked for the pattern to be generalized:

generalize these ideas and formalize them into a meta agent or skill that creates other agents and skills that use these principles to optimize for modularity, composability, concurrency, context management, and high-signal and low noise context curation

That request became capability-architect.

The Move From Instance to System

The first version of the work was concrete:

writing-team-orchestrator
  scan-fork
  architect-fork
  draft-fork
  review-fork
  polish-fork

It solved a specific problem: writing.

But the more important thing it revealed was not the list of forks. It was the architecture underneath them.

The answer named five invariants every generated package should satisfy:

Modularity
Composability
Concurrency
Context management
High-signal curation

Those became the spine of capability-architect.

This is a move I try to watch for in any AI work. A successful one-off process often hides a reusable grammar. Once you can name the grammar, you can build a tool that generates new instances of it.

For knowledge entrepreneurs, this is especially important. Your business is full of repeated cognitive work: writing, teaching, diagnosing, reviewing, planning, onboarding, advising. If each workflow stays trapped as a one-off prompt, you keep rebuilding the same shape.

The higher-leverage move is to extract the architecture.

Concept #1: Extract the invariant before you package the skill.
A useful skill is not just a saved prompt. It is a reusable structure for producing a class of outcomes.

What capability-architect Had to Create

The meta-skill needed to take a workflow and produce a capability bundle.

Not one giant prompt.

Not one vague agent.

A bundle with:

The early description was:

capability-architect compiles any capability description or existing pipeline into a generated package: one orchestrator + N forked specialists + optional fresh-context spawns.

That word “compiles” mattered. The skill was not merely brainstorming a team. It was converting a workflow into an executable structure.

The compile procedure became:

intake -> DAG -> code/inference classification -> bundling -> execution modes -> model routing -> contracts -> generate -> evals

In nontechnical language:

  1. Understand the job.
  2. Map the dependent steps.
  3. Decide which steps need code and which need judgment.
  4. Bundle steps whose intermediate outputs do not need to return to the parent.
  5. Choose inline, fork, spawn, or parallel execution.
  6. Assign model and effort.
  7. Define what each child returns.
  8. Generate the skill bundle.
  9. Add tests for when the skill should and should not trigger.

That is a long way from “make me an agent.”

Forks and Spawns

One design decision became central: not every child worker should inherit the same context.

A fork receives the parent context. It is useful when the child benefits from knowing what the parent already decided.

A spawn starts fresh. It is useful when inherited context would bias the work.

The simple rule was:

Would the child do better seeing what the parent decided?
yes -> fork
no or worse -> spawn

That distinction is useful outside technical workflows.

If I want a writer to continue a draft in my voice, inherited context helps. Fork.

If I want an adversarial reviewer to judge whether the draft is actually good, inherited context may contaminate the review. Spawn.

If I want a research worker to gather sources without being nudged toward my preferred answer, spawn may be better.

If I want a revision worker to apply a specific review plan, fork is better.

Concept #2: Use forks when inherited context helps; use spawns when it contaminates.
The question is not whether a worker is separate. The question is whether it should inherit the parent’s assumptions.

The Skill-Bundle Correction

At one point, I made the wrong architectural assumption.

I treated a skill as if the unit was basically one SKILL.md file.

That was corrected:

the skill may have an entire folder of resources and assets within the skill folder, and access any other asset/resource in an .ailib sibling

That correction changed the packaging.

A skill is not merely a file. A skill is a folder with an entry point.

It can include local resources:

skills/capability-architect/
  SKILL.md
  references/
  assets/templates/
  evals/

It can also refer to shared sibling resources:

references/model-effort-routing.md
skills/inference-router/SKILL.md

This aligned with the ambient intelligence model from the first article. Local resources stay inside the capability. Shared resources live at sibling scope.

From writing-team instance to capability-architect

Installing It Into the Global Library

The final goal was not to leave capability-architect as a mockup.

The goal was to put it in the global library so any future folder could inherit it.

The target shape became:

.ailibrary/
  references/
    model-effort-routing.md
  skills/
    inference-router/
      SKILL.md
    capability-architect/
      SKILL.md
      references/
      assets/templates/
      evals/

This was the moment the architecture ate its own cooking.

capability-architect was itself built using the rules it would later apply:

That matters because reusable systems should follow their own principles. If capability-architect had kept everything buried inside itself, it would have violated the modularity it was supposed to teach.

Concept #3: Make every reusable pattern inheritable.
A capability becomes ambient only when other folders can inherit it without copying it by hand.

What This Unlocks

The immediate output was a skill builder.

The deeper unlock was a repeatable way to turn expertise workflows into structured AI capabilities.

Imagine a knowledge entrepreneur with a strong workshop design process. capability-architect could help decompose it into:

Or a consultant with a diagnostic framework could generate:

The point is not to create more agents for the sake of it. The point is to preserve the structure of expert work.

When the structure is explicit, it can be reused, improved, tested, and inherited.

Key Takeaways

How to Start

  1. Pick one workflow you already perform well.
  2. List the stages and the artifacts each stage produces.
  3. Mark which stages need inherited context and which need independence.
  4. Define what each child should return to the parent.
  5. Extract the repeating structure before trying to automate it.

Behind the Article

The highest teaching value was the correction that a skill is a bundle, not a single file. That one shift made the architecture fit the ambient library instead of fighting it.

I compressed the details of the generated templates and eval files because the article’s job is to teach the abstraction path from one pipeline to reusable builder.

The single most valuable thing to add before publishing would be a short worked example showing how a non-writing workflow, such as course design or client onboarding, would be compiled by capability-architect.