“This is different from ‘make me an agent.’ It is a disciplined design process for capability creation.” — Lou

Session context: 2026-06-11_Mastermind — once a folder can inherit and activate capabilities, the next question is how to create them repeatably. Lou’s answer is a compiler.

Core Idea

“Make me an agent” produces a prompt. Capability-Architect produces an inheritable skill bundle — a unit that drops into the ambient library and can be declared by any project. The difference is that it runs the workflow through a fixed compile path instead of improvising. The input can be a workflow, a problem, or an existing pipeline (“turn this client onboarding into a reusable AI workflow”); the output is a structured bundle, not a one-off answer.

The compile path is the substance — a checklist the architect follows, each stage answering one question:

  1. Intake — what job is this capability for? If you can’t state it clearly, the rest drifts.
  2. Dependency map (DAG) — which artifacts depend on which? A draft depends on a brief; a revision depends on a review; a polish depends on the revised draft.
  3. Classification — which steps are deterministic code, which require judgment, which are hybrid?
  4. Bundling — which steps belong together because their intermediate outputs are only used internally and never need to surface?
  5. Execution — should each step run inline, in a fork, in a spawn, or in parallel?
  6. Routing — which model and effort level does each component need?
  7. Contract — what must each child return to the parent? (The API contract — typically a JSON envelope plus an artifact path, so heavy outputs move by reference, never pasted into the parent.)
  8. Generation — create the actual skill bundle and its local assets.
  9. Evaluation — define the cases where the skill should fire and where it should not.
  10. Install — make it inheritable by folders.

What makes this powerful is that judgment itself becomes modular. The routing logic doesn’t live inside Capability-Architect — it’s delegated to a shared inference-router reading a shared model-effort-routing.md reference, so a writing orchestrator, a course-design workflow, and a client-delivery agent all reuse the same routing process. The architect composes specialized sub-processes rather than owning every decision. This is the through-line of the whole session made operational: ambient inheritance, activation, fork-vs-spawn, model altitude, and artifact-by-path contracts, assembled into one repeatable build discipline — all driven conversationally, with the harness (Claude/Codex) as the only interface. No TypeScript, no UI to scaffold.

Practical Application

Next time you’re tempted to ask an AI to “build me a writing team” (or any multi-step workflow), don’t accept a single mega-prompt. Walk the compile path instead:

State the job. Map the artifact dependencies. Classify each step as code / judgment / hybrid. Bundle the steps whose outputs stay internal. Decide inline / fork / spawn / parallel per step. Route model + effort per step. Define what each child returns to the parent. Then generate the bundle, the eval cases, and the install.

The result is auditable and reusable — when an output disappoints, you can point to the exact stage (classification, routing, contract) that failed, rather than rewriting the whole prompt.

Evolution Across Sessions

Synthesizes the session’s other threads into a single build discipline, and extends Insight - Skill Orchestration — Forking, Quality Gates, and Pipeline Mechanics Make Chains Actually Run (2026-02-26) from “how a pipeline runs” to “how a pipeline is compiled and installed.” Establishes the baseline for capability creation as a compiler step; the open thread is the capability-architect and inference-router skills themselves, queued as a PRD for design review.