Adds the site settings singleton: one siteSettings node at the root of the content tree that
holds what belongs to the whole site (the logo, navigation, footer, social links, default sharing
image, tracking codes). It is not the home page. Its schema is decided by
umbraco-add-document-type with
the role site settings; this skill adds the tabs, the root behaviour and the content node. It
works requirements-first: write the change down, stop for the user's approval, apply it, then
read it back.
The rules come from
umbraco-content-model-conventions, and the
requirements doc format and
the six-step workflow
from
umbraco-content-requirements-documentation;
both must be installed alongside this one. If a link into either cannot be read, stop and say so.
Steps
| Step | What happens | Reference |
|---|---|---|
| 1. Inspect | Existing settings (on the home page, in another node), root types, languages | workflow.md |
| 2. Decide the tabs | Which tabs, in which order, 0 to 9 | tab-layout.md |
| 3. Decide the fields | Aliases, data types, repeaters | workflow.md |
| 4. Write and lint | The settings type, any data types and repeaters, a changeset | workflow.md |
| 5. Approve | Stop. The user approves the changeset | workflow.md |
| 6. Apply | Through the MCP if connected, otherwise a manual walkthrough | workflow.md |
| 7. Verify | Read everything back, set the status lines, report | workflow.md |
How to decide between MCP and manual
One approach, two mechanisms: the Umbraco Developer MCP when it is connected, otherwise a manual walkthrough generated from the same requirements doc; see change-workflow.md.
Version compatibility
Targets Umbraco 17+. MCP tool names were checked as described in
umbraco-content-requirements-documentation;
the connected tool list is the authority.
Best practices
- Settings are not on the home page. The rule is in allowed-children-and-root.md; it deliberately overrides the older advice to put settings on the root page.
- One type, one node per site. A second site gets a second
siteSettingscontent node, never amicrositeSettingstype; how code finds the right node is agreed with the developer. - The home page stays first at the content root. A settings node sorted above it changes every URL; see root order and check the position after the user creates the node.
- Its tabs are its own, 0 to 9, with no template, children or compositions; the rules are in tabs-groups-sorts.md and templates.md, the layout in tab-layout.md.
- Moving settings off the home page loses their values unless they are migrated. Stop and say so; never delete the home page's fields to make room.
- "Just add a settings node" is not approval. It is a request for the change; stop at the approval gate.
Validation
Objective assertions live in evals/evals.json; run them with
umbraco-skill-evaluator. Coverage tier: Documented. This skill ships no code and no assets.
The requirements docs it writes are checked by the linter in
umbraco-content-requirements-documentation, and an eval graded the guidance. Nothing ran against
a live site.