umbraco-add-listing-page

Add Listing Page

Adds a listing pair: a listing page (articleListingPage) and the item page it lists (articlePage), made together because neither is useful alone. The listing gets its own collection view so editors manage items as a table, and the two types allow each other the way the conventions say. It works requirements-first: write the change down, stop for the user's approval, apply it, then read it back.

One standalone page belongs to umbraco-add-page; this skill calls it once for each of the two pages, so each gets its template and takes the SEO composition, and adds only what the pairing needs. The schema of each page is decided by umbraco-add-document-type with the role page.

The rules come from umbraco-content-model-conventions, and the requirements doc format and the six-step workflow from umbraco-content-requirements-documentation (change-workflow.md); 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	Home page, compositions, master template, existing listings and items	workflow.md
2. Decide the pair	Names, compositions, fields, templates, parent and children	workflow.md
3. Decide the collection view	Columns, ordering, page size, layouts	collection-view.md
4. Write and lint	Collection view, two templates, two page types, the parent update, 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

MCP when connected, otherwise a manual walkthrough from the same requirements doc; see change-workflow.md.

Version compatibility

Targets Umbraco 17+. The collection view uses Umbraco.ListView with the editor UI Umb.PropertyEditorUi.Collection, read from the Umbraco 17.5.3 packages. MCP tool names were checked as described in umbraco-content-requirements-documentation; the connected tool list is the authority.

Best practices

• Always the pair. A listing without its item type cannot list anything, and an item type with nowhere to live cannot be created. Specify both, and the allowed children between them, in one changeset.
• Name them together: <noun>ListingPage lists <noun>Page; see naming.md.
• Each listing has its own collection view, except listings of the same item type, which may share one; see allowed-children-and-root.md.
• The listing is not the item's data. Fields that describe an item (a date, a summary, an author) live on the item, or a composition; the listing shows them as columns.
• Order by something the item holds. Newest first by a date on the item is usually right; the create date is a fallback when the item has none.
• The parent is an existing type, updated by a full-body replace: the riskiest call in the change, as umbraco-add-page says.
• Every page takes SEO. Both pages take the SEO composition; if the site has none, it joins the change, as SEO is mandatory says.
• "Just add a blog" is a request for the section, not approval of a requirements doc the user has not yet seen; the gate is in change-workflow.md.

Validation

Objective assertions live in evals/evals.json; run them with umbraco-skill-evaluator. Coverage tier: Documented. This skill ships no assets; its only code is the Razor layout stub borrowed from umbraco-add-page, which is uncompiled context that no host builds; for real templates see the Umbraco templates docs or the implementation plugin. 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.