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; an Essentials/Mailbox lists every message in its subtree, and its All and Drafts pages carry the framework's +, which opens a new message filed under the mailbox itself, so a mailbox placed at a counterparty drafts there. The Executive Assistant records each draft it saves in Outlook as one of these messages, filed under the counterparty it concerns: see Where a draft is filed) 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

• Essentials/Skill/* — 19 skills (nodeType: Skill, content SkillDefinition): the harness commands /agent, /model, /models, /harness, /clear, /navigate and the content skills /markdown, /space, /group, /access, /code, /layout-area, /slide, /presentation, /pull-request, /provider-keys, /activity, /communicate.

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:

• Nothing on the page changes — comments, suggestions and the editor look and behave as before; their styling and scripts travel inside the bundle (_content/MeshWeaver.Markdown.Collaboration/).
• A portal that has not landed this package has no markdown editor and no collaborative reader — the three controls render through the escaped-HTML fallback. Both portal hosts therefore list the module under Modules:Required, so the required-modules health check names Essentials as the module it waits for, and carry it as a modules/ seed so a self-registry install has it from the first boot.

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:

• The AI engine's Data/Agent/ is the ONE master for every built-in agent. The AI package is preInstalled: true and materializes the roster into the Agent partition on every portal, so its agents are already available to everyone with no per-user copy. (There is no Agent PACKAGE — the one that used to carry the roster was consolidated away on 2026-08-28.)
• No other package may ship a node with an Agent/* id as nodeType: Agent. A package that needs the roster declares AI@^1.0.0 in requires, exactly as this one does. scripts/validate-repos.py fails the PR on a re-introduced duplicate — deleting the copies is not enough if nothing stops the next author from adding them back.
• A package's OWN agent is welcome and needs a distinct id (Feedback/Agent/feedback-agent, Hosting/Agent/platform-update, Voice/Agent/voice). The gate only refuses re-shipping a master.
• ToolsReference and CommentingReference are documentation, not agents — Markdown nodes under Agent/, @@-embedded into the agents that need them (@@Agent/ToolsReference appears in Assistant, Worker and Researcher). Essentials shipped them as nodeType: Agent, which is why ToolsReference was the duplicate a user noticed first: it was the one pair where both copies claimed to be a selectable agent. The masters now declare NodeType: Markdown explicitly rather than relying on the parser's default, so the intent is readable in the file.

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.