Page hierarchy and sections

Use Sections in the navigation rail to define accurate, reusable section schemas, and Pages to compose the pages that use them. Together these workspaces connect each section's content requirements and implementation context with its role on a page.

Reusable definitions live on the Sections canvas and in the Pages workspace library panel. Their global labels and shared implementation context remain stable, while each placed instance can be renamed on a page to describe its role there—for example, Two Column Content - Business Services can still reference the global Two Column Content definition.

Every Page node from Structure appears as a page card. Imported AI pages also create hidden Page Hierarchy route-card copies so the hierarchy is populated immediately after import.

Build the Sections library

Every section is reusable by default. Create it in the Sections workspace, create it from a page add menu, or select a preset on a page; each path creates or reuses one canonical library definition.

Each reusable section includes:

• A stable global name, such as Top Nav, Footer, or Two Column Content.
• An abstract preset thumbnail.
• Shared purpose and implementation notes.
• An ordered content structure with typed fields and repeating groups.
• Additional layout, behaviour, and reuse tags.
• A library-specific workflow status color.
• An instance count showing how many page placements reference it.

Arrange Sections freely on the canvas and add labelled dividers to create visual groups such as Navigation, Content, and Case Studies. Move a card using its drag handle or blank card space. Shift-click or marquee-select several items, then move the selection together. Positions extend in every direction and snap to the dotted canvas grid.

A grouped definition keeps the divider's stable groupId in JSON, so imports and later revisions retain the organisation as well as the visual placement.

Library cards show a layout preview, reusable title, description, content-field summary, usage count, and quick status control. Select a card's title or preview, or use its edit menu, to open the editor on the right.

The editor separates the work into three tabs:

• Content: name, description, and ordered content fields and groups.
• Layout: an abstract layout preset, chosen independently of the content fields.
• Settings: the definition's workflow status, additional tags, and build guidance.

Choose Save changes to apply the editor draft; normal project autosave then persists it. Cancel discards the draft.

Use search, Unused, and the status filter together to narrow the Sections canvas. The collapsible Section library in Pages offers the same filters. Unused shows definitions not yet placed on a page; the status filter includes All statuses, No status, and each workflow color. Hidden cards are excluded from marquee selection and bulk status changes.

In the Pages library, drag a definition onto a page, or select a page and use the definition's quick-add action. The library scrolls independently so the page canvas remains in place while you search.

Use shortcut 1 in the Sections workspace to open the section preset picker and 2 to add a divider. In the Pages workspace, shortcut 1 opens the page picker. Number shortcuts are always scoped to the active workspace.

Changing a reusable section's name, notes, tags, or abstract pattern updates linked page instances. Changing its library status does not change the status of any Page Hierarchy instance.

Deleting a reusable section or divider requires two clicks. The first click arms the row briefly; click again to confirm. Deleting a reusable section removes it from the library and detaches linked instances as local page sections.

Page cards

Each card represents one page or route. Cards show:

• The page name.
• The number of planned sections.
• Section order from top to bottom.
• Completion progress for sections tagged green.
• The linked library definition name, or a Legacy marker for older embedded data.

New page cards are placed around the current pointer position when possible. Move them freely across the Pages canvas; Skafold preserves manual positions instead of recalculating them on the next import or reload. Use the minimap to navigate larger hierarchies and the page search in the floating quick bar to find a specific route.

The Pages quick bar also filters by section status. A page matches when at least one of its sections has the selected status. The whole page composition stays visible, including its other sections. No status includes pages with unstarted sections and empty pages. Combine this filter with page search, or clear the filters to show all pages again. The page filter and library filter work independently.

Add section patterns

Use the add-section control on a page card or between existing sections to insert a section at the exact point it belongs. You can also drag or quick-add an existing definition from the library panel. Choosing a new preset creates its library definition automatically; selecting that preset again reuses the existing definition instead of creating numbered duplicates.

Patterns are abstract structure hints, not final UI components. They help communicate broad composition:

• Full width sm, Full width md, Full width lg, Full width xl
• 2 cards row, 3 cards row, 4 cards row, 5 cards row
• 2 columns, 2 columns 1:2, 2 columns 2:1, 2 columns 3:5
• 3 columns, 4 columns, 5 columns
• Grid patterns such as 2 x 1 grid, 3 x 2 grid, and 3 x 5 grid

Use compact card rows for shallow strips of cards. Use grid patterns for square or multi-row compositions. Use full-width sizes to indicate vertical weight, from a thin strip through a large hero-like band.

Section names

The section name communicates purpose. Prefer recognised names when one fits:

• Top Nav
• Hero
• Features
• Cards
• Product Grid
• CTA
• FAQ
• Contact Form
• Footer

Use a custom name only when the section has genuinely project-specific behavior. Avoid using the name to carry all implementation detail; use notes and tags for that.

Content structure

Open a reusable section's editor and use the Content tab to define its fields. Saved changes apply to every page using that definition. In the compact Pages library, open the section's edit menu.

Use Add field for common fields such as Eyebrow, Title, Short description, Body, Image, and Button / link, or add a custom field. Add group creates a repeating group. For an empty structure, Choose a preset… offers Hero, Features, Cards, FAQ, CTA, and Text defaults. Existing sections keep their tags and are not automatically assigned fields.

Fields appear in an ordered list. Drag the handle beside a field or group to change its order; fields inside a group have their own handles. With a handle focused, use the up/down arrow keys, or choose a move action from the row menu. Rename fields and search the type picker. The Required checkbox shows the current requirement: checked means required, unchecked means optional. New fields start required. Add field → Field types also creates a field with a specific type. Expand the field options to add guidance such as “roughly 30 words.”

Cards and other repeating groups contain their own fields. Set an optional item count, then choose what each item needs. Object / field group defines a single set of related fields, such as an address. Both support one level of child fields, with up to 50 fields per list. Repeating groups support counts from 1 to 100; objects have no item count. Leave the count blank when it has not been decided.

Field types and inputs

Choose Custom from the type picker when none of the standard types fits. Selecting it preserves the field's name. Set Custom type name to describe the type you need, such as Geopoint or Product picker, and use the visible Guidance field for context, data shape, and implementation requirements. You can still rename the field independently. The type stays Custom; its name and guidance are included in JSON and Markdown handoffs. Leaving the custom type name blank keeps the requirement undecided.

Checkbox / toggle represents a single true/false value. Radio buttons and Select dropdown represent one selection, while Checkbox group allows multiple selections. Use Add choice and enter a label for each choice. Drag its handle to reorder, or focus the handle and use the up/down arrow keys. Remove a choice with its cross button. Up to 50 choices are supported; leave the list empty if the choices are still undecided. Changing between choice types preserves the choices. Changing to another data type removes them. If a specific CMS value matters, record the requirement in Guidance.

These types describe the content data and intended authoring control. For example, in Sanity a checkbox maps to a boolean, radio buttons to a string with a predefined list and radio layout, and a checkbox group to an array of strings with predefined choices. See the official boolean, string, and array references.

Use guidance for HTML heading levels, numeric ranges, reference target types, media sources, and other project-specific constraints. A Heading field holds text; guidance can specify how it should render. These definitions inform implementation without assuming a particular CMS plugin or generating a complete Sanity schema automatically.

Image fields request an image brief, alt text, and an optional caption in the handoff. Button / link fields request a label and destination. Content structure defines the section's schema: its fields, types, order, required or optional values, and repeating groups. This gives developers and AI tools a more accurate basis for CMS schemas and component data requirements, while guiding content collection. Finished copy is authored separately.

The AI Context JSON includes contentSchema on reusable definitions. Choice values are managed automatically and retained when labels or order change, keeping imports stable. Markdown exports show the choice labels alongside ordered, nested fields for both reusable sections and page compositions. Republish an existing AI Context snapshot after editing to include the latest schema. Use Project Importer 2.4 or later for the simplified choice workflow. Missing facts, unspecified choices, and item counts should remain open questions.

Notes and additional tags

Edit the description in Content, the preset in Layout, and additional tags and build guidance in Settings on the canonical definition in Sections. Page Hierarchy keeps the independent placement title and content workflow status.

Use notes for the section's purpose and handoff context:

Compare the three service tiers and route visitors to the relevant enquiry path.

Use additional tags for quick implementation cues. Prefer content structure fields for copy requirements; older content tags are preserved:

• Content: title, eyebrow, summary, price, author
• Media: background image, video, gallery, icon
• Structure: grid with cards, card row, split content, accordion
• Controls: search, filter, sort, pagination
• Actions: primary cta, add to cart, submit
• States: empty state, loading state, validation message

Tags are intentionally lightweight. They should help the handoff without turning the planner back into a long form.

Workflow status colors

Select the status control on a library card to open its color palette. Choose a color to make workflow state visible at a glance, or clear the color when no status is needed. The palette closes after a selection, when you click elsewhere, or when you press Escape.

To update several definitions together, Shift-click or marquee-select the cards, then use the status control on one of the selected cards. The change applies to all selected, visible section cards; dividers are excluded. Using an unselected card's status control changes only that card.

In Pages, individual sections retain their own status controls. Use the completion counter in a page header to set or clear the status of every section on that page. If that page belongs to a multi-selection, the action updates every section in all selected, visible pages. The menu indicates mixed statuses when the sections differ, and the counter continues to count only green sections as complete.

Each bulk status change is one undoable action. Updating page sections leaves the reusable definition and placements on unselected pages unchanged.

The suggested meanings are intentionally flexible:

• Blue: work in progress.
• Purple: review or signoff.
• Amber: needs attention.
• Red: blocked.
• Green: complete.

No explicit status is treated as not started.

Only green counts toward the page-level completion rollup. The other colors remain flexible visual tags, so a team can adapt them to its own stages without changing the page model.

Status is intentionally isolated by context. A reusable definition has its own status in Sections, while every placed page instance has its own status in Page Hierarchy. This lets a team track the shared structure through design, build, and approval while separately tracking page-specific content or implementation readiness.

Reusable-by-default sections

All sections use the same reusable model, whether they currently appear once or many times. Typical repeated definitions include:

• Top navigation
• Footer
• Announcement bar
• Repeated CTA
• Shared product teaser
• Reused service proof block

The stable name, notes, tags, structure pattern, and build guidance come from the library definition. A placement can have a page-specific title without renaming that definition—for example, Two Column Content - Business Services can reference Two Column Content.

Older embedded sections continue to display with a Legacy marker. New sections are always linked, and import/export promotes page-only legacy definitions without merging records by name.

What gets exported

Sections.md includes reusable section names, layout patterns, shared notes, content structures, additional tags, and build guidance.

Page Layouts.md includes:

1. Page names and route paths where available.
2. Ordered section names.
3. Library-definition references.
4. Page-specific workflow status color and its suggested meaning.

Skafold JSON round-trips canonical definitions, divider groups and groupId, lightweight page placements, globalSectionId, page-specific instanceName, and independent library/placement status colors.

Build an accurate section schema

• Define the fields the section needs, with clear names, appropriate types, and an intentional order.
• Mark fields as required or optional, and model repeated content as groups with their own fields and item counts where known.
• Add guidance for content constraints and implementation requirements that the field controls do not express.
• Reuse a definition when its schema and purpose fit; create a distinct definition when the content requirements differ.
• Choose a layout pattern that communicates the intended composition, and review imported fields and groups before handoff.

The goal is a precise section schema that can inform CMS models, component interfaces, and content authoring. Capture the detail needed to implement each section accurately, and use notes and build guidance to record requirements beyond the available schema controls.