The two builders and how to summon them

The two builders

The workspace carries two builder specialists — domain expert agents I bring in on your word, the same way I bring in any deep specialist.

Each is encoded with its own craft, so summoning one by name loads everything it knows about building its kind of thing.

The Knowledge Builder — what the company knows

The first is the Knowledge Builder, and it owns knowledge production: meeting notes that should become a reference, a method worth curating, the dictionaries and definitions a domain answers from.

This is the IP that stays with the company — captured once, owned by a domain, loaded by every future session instead of living in one person’s head.

It knows where each domain’s knowledge lives, how files are named and owned, and how to turn raw material into a reference a domain can answer from.

"Bring in the Knowledge Builder — turn Mike’s training notes into a reference the sales domain can answer from."

The System Builder — the machinery

The second is the System Builder, and it owns system extension: new domains, skills, rules, hooks, commands, and connectors to outside tools.

That’s the machinery — the parts that make a piece of work repeatable instead of re-described every time.

It carries the recipe for each kind of part and builds to the bar from the last module — spec first, the five done questions — so you never have to police the mechanics.

"Bring in the System Builder — I want a skill that turns a claim transcript into a one-page brief with the handler, the estimate, and the next action."

You describe the what; the builder owns the how

You bring the outcome — what the thing should produce, who it’s for, what good looks like — and the builder owns everything between that description and a working part.

You don’t have to name the artifact kind: describe the behavior you want, and the builder tells you whether that’s a skill, a rule, a hook, or a rule-hook pair.

Bring a real example when you have one — a skill built from an exemplar you like lands far closer on the first pass than one built from a description.

Before writing a word, the builder checks what already exists: if the need is covered it says so and stops, and if the new part would conflict with an existing one it surfaces both and resolves the conflict first.

Then it narrates the steps live as it works — what it’s checking, what it’s writing, where each file lands — so every step is one you watched and can question before the next begins.

If the build is new ground for you, the ask-how move from the Operate modules applies here too: "give me the rundown first, before we start."

And the workspace underneath stays recoverable — the logbook records every change, so a build that goes wrong rolls back.

The distinctions worth carrying

The builders carry the full recipes; what’s worth carrying yourself is one sharp line per kind of part.

• A rule is read by me; a hook is run by the system. I honor a rule because I loaded it at the start of the session; a hook fires on the event itself whether or not I remembered — so for a behavior that must never slip, the rule declares it and the hook makes it unskippable.

• A constraint is a rule; a process is a skill. A line that must never be crossed — email is draft-only — is a rule; a sequence of steps that produces an output is a skill, so if you catch yourself describing steps, you’re asking for a skill.

• A skill and a command are the same job from two directions. A skill answers when I match a request to it; a command answers when a person types its name — and the command stays thin, a handle pointing at the skill that holds the work.

• A new domain begins with a blueprint, never with a skill. Naming the skills before any are built is what sets the boundary on purpose — a domain grown skill-by-skill grows by accident, and six weeks later nobody can say what it’s for.

• Every skill has a spec before a line of it is written. The spec is the contract for what correct output looks like, and every gap between the result and the spec is a bug to close, not a quirk to accept.

• One hook per concern, not one per idea. All the filename checks belong in one hook; a new script for every passing thought leaves a dozen near-duplicates firing on the same event, each its own thing to maintain.

• Before connecting anything new, check what already exists. The workspace keeps a registry of every connection that’s wired in, and a second path to a system that already has one is debt — duplicate paths drift apart and confuse me about which to call.

The full bar these answer to — spec first, the five done questions — lives in the build standards.

Keep the judgment yours, the mechanics the builders'

What to build, what it should produce, and whether the result meets the spec — those are your calls.

Where files land, how a spec is shaped, which moment a hook fires on, how a connector speaks its protocol — those stay with the builders.

One reach to respect: a rule applies in every domain by definition, so a new one is rarely a private change — when it would shift how someone else’s domain behaves, talk to them before you ship it; the system won’t block you, coherence asks that you check.

The one thing to remember

Describe the what and summon the right specialist by name — the Knowledge Builder for what the company knows, the System Builder for the machinery — then judge what comes back against the spec, because the spec is the contract.

Next: the Lead modules — roles, governance, and adoption.