What this package is

MeshWeaver Essentials bundles the framework's default skills as a single, node-native plugin that ships outside the core image. Factoring these defaults into an independently-versioned package means a deployment can update the standard /-menu skills without a core rebuild — and every mesh gets the same baseline.

Skills themselves are content nodes (nodeType: Skill), so there is nothing to compile — the mesh imports them as-is. The package does carry compiled code in two other shapes: two small node-native types the mesh compiles live — Essentials/Email (a message with a lifecycle, and an approval gate built on the platform's cross-cutting Approvals: name approvers and a quorum, and the page offers Request approvals, then Send only once the message's own _Approval satellites say the quorum stands on the text as it stands — an edit lapses every approval. Send and Save as Outlook draft run the message's own script on the kernel as the clicker: the attachments export to PDF, the mail is built in the clicker's own mailbox with its Cc, and it is sent — and the record stamped — or left in Outlook's Drafts with its link on the record; Show plan unfolds the exact chain. The /email skill walks the setup) and Essentials/OperationRequest, where an agent proposes a privileged operation as a script, a global admin previews and approves it on the request's page, and the platform runs it as System (see Operation requests) — and its module, MeshWeaver.Markdown.Collaboration (content.module), described under The collaboration module below.

🚨 The default AGENTS are not here. They have exactly one master — the pre-installed Agents package (Agent/*), which Essentials declares in requires. Essentials shipped its own copies of the same thirteen agents until #655: they drifted (its Assistant fell 650 characters behind the master's), the install seeded a user's home from whichever copy it reached first, and every listing surface showed each agent twice. One master, no copies — see One master per agent below.

What it ships

Nothing else. The default agents ship from the Agents package.

The collaboration module — one producer

content.module names MeshWeaver.Markdown.Collaboration: inline comments, the tracked-change view model and the anchoring that re-derives a comment's range as the document moves on — and, since 2026-09-03, the three Blazor views that render all of that: the collaborative markdown reader (CollaborativeMarkdownControl), the markdown editor with suggestions (MarkdownEditorControl) and the select-to-comment wrapper (CommentableControl).

The views used to be compiled into the platform's default view pack, which ships in the portal image. Because they bind the module, the image carried a second copy of the module's assembly beside the bundle this package delivers — and the bake refused to seal a publication against an assembly with two producers ("two builds of one assembly name in one bake", Systemorph/MeshWeaver#3175). CD stopped at that job. The rule that resolves it is the maintainer's: a module lives in exactly one place, so the views moved into the module (plugins#1262) and reach a portal together with it, the way the chat views reach it with the AI engine. The design and its runtime consequences are written up beside the code, in src/MeshWeaver.Markdown.Collaboration/README.md.

What that means for an installation:

How pre-install + install work

The root is a Store/Plugin whose PluginContent sets preInstalled: true. That has two effects, both owned by the Store/Plugin type:

  1. Open + globally resolvable. The content is never gated — every signed-in user can read it — and the shipped skills (Essentials/Skill/*) are mirrored into the global Skill/ registry, the namespace the composer's / menu reads for every user. So the skills resolve with no install and no purchase.
  2. Get copies into your home. The root declares installPaths: ["Essentials/Skill"], so Getting the package copies Essentials/Skill → {you}/Skill and nothing else — the skills become yours to browse and adapt. Uninstall removes exactly those copies and never touches your entitlement. There is no agent copy: the Agents package is pre-installed and its agents are read where they are served.

One master per agent

Two packages shipping the same agent is not a redundancy, it is a staleness generator: the copies diverge, and the user's home is seeded from whichever one the install reached — silently running last quarter's instructions with nothing on screen to say so. #655 measured exactly that.

The rule this package now follows:

Editing a skill

Each node is the source of truth. A skill's behaviour lives in its SkillDefinition (action + instructions). Edit the JSON node in this repo, open a PR, and the registry re-serves the updated package. An agent is edited in the Agent/ module — a .md with nodeType: Agent front matter whose body IS the instructions.

Reconnecting…
The server was updated. Reloading the page to pick up the latest version.