Author a component page

Author a new or existing MDS component-page draft from verified evidence. This is an internal method used by authoring-kit-writer, not a standalone user workflow.

Write one decision-focused MDS component page. Follow the assigned source state and iteration in the writer brief. The writer workflow owns paths, iteration mechanics, preservation, and handoff. This skill owns the component-page content method.

Read these references when the writer workflow selects this skill:

Page template: component-page structure and conditional sections.
Content elements: synopsis, rules, examples, tables, and callouts.
Content voice and tone: documentation register and final editing pass.

Evidence

Use the strongest available source for each claim:

Use the supplied component API surface for implemented props, events, slots, and states.
Use current MDS foundations, content, guidelines, and related component pages for system policy and terminology.
Use the research brief for external patterns and unresolved differences. External research informs and flags; it does not remove an existing MDS decision, and its additions go to the handoff as proposals (see the writer workflow’s invariants).
Use supplied product examples or stakeholder notes for domain context.

The API surface confirms what the component supports. It is not page copy. NEVER copy property names, types, defaults, or package descriptions into the draft as developer documentation.

The page template, content-element rules, and content voice and tone define current writing practice. NEVER treat another component page as the definition of quality. Read a current related MDS page only to answer a specific policy, terminology, or compatibility question.

Report contradictions instead of resolving them by assumption. Do not add a recommendation that depends on an unverified capability.

Source states

Source state	Audit input	Authoring rule
`new`	Approved content brief, research, and API surface	Establish guidance from verified inputs. Do not create a live page or supporting implementation.
`existing`	Current page, its assets, research, and API surface	Preserve every verified decision unless the brief approves its removal. Restructure and rephrase as needed.

A new component page requires a verified MDS implementation or public contract. If neither is available, return the missing product or API decision instead of drafting authoritative guidance.

Procedure

Audit

Run this section on iteration 1 only.

State the component’s primary UX axis.
Read the source page for an existing component or the approved content brief for a new one.
Map the verified decisions to the page template.
Identify unsupported claims, contradictions, missing decisions, reusable approved assets, and guidance that belongs in a shared guideline. Move guidance to a shared guideline only when that guideline already covers it; otherwise keep it on the page.
Read a current related MDS page only when a specific unresolved policy, terminology, or compatibility question requires it. Record the page and question in the writer handoff.

Pause only when an unresolved decision would make the draft unreliable. Otherwise continue and disclose non-blocking gaps in the writer handoff.

Draft

Follow the page template’s section order and conditional-section rules.
Put most depth on the primary UX axis. Do not turn the page into an alphabetical property catalogue.
Explain Maersk usage and decision boundaries. Do not write a generic component explainer.
Separate author responsibilities from behaviour implemented by the component.
Link to shared guidance instead of duplicating it.
Apply the content-element rules to every Rule and meaningful Example.

Self-check

Check every factual claim against the supplied evidence.
Check that each section helps a reader make a component-specific decision.
Check that examples agree with the prose and add information.
Check that imported files and linked pages are known to exist. Record any deliberately unlinked alternative.
Apply the final content check in Content elements.

Writer notes

Return these through the writer workflow’s handoff when they apply:

proposed assets, using each placeholder’s Setup: clause as the commissioning brief;
supporting implementation proposals for demos or code;
shared-guideline extractions;
unsupported claims, contradictions, and open product decisions;
any related MDS page read, and the specific question it answered.

References