Research design systems

Research how official design systems, and MDS itself, document a component or pattern and return concise, source-linked usage, content, and accessibility evidence as the design-system section of an MDS research file.

Research one component or pattern across official design-system documentation and the existing MDS pages. Produce the ## Design-system research section of research.md, so an author can make decisions without external guidance being presented as MDS policy.

The researcher workflow owns the shared parts of research.md (header, Context, Summary, Decision topics, Gaps) and its assembly. This skill owns its own section only. Standards and expert sources belong to research-standards-and-expert.

Output

Return the section below to the researcher workflow. When run directly, follow the workflow’s file format and merge rules: create the shared parts if research.md is missing; otherwise edit the ## Design-system research section in place only. For an extend or re-verify, research only the topic or sources the brief names, and return only new or changed rows and any contradiction (both claims, sources, dates). Do not create working-note files, a research manifest, manual-research folders, or separate synthesis files.

Source scope

Read references/core-sources.md each run.

  • Check every Core source during a normal research run.
  • Read references/extended-sources.md and check Extended sources only when the user explicitly requests broader research. In the pipeline that request arrives as the brief’s extendedSources: the named systems, or a number for you to choose the most relevant. Check exactly that scope, and record which you checked.
  • Run directly, if the user requests broader research without naming its scope, ask which Extended sources or how many they want checked before fetching them. In the pipeline, never ask: the PM settles the scope before delegating.
  • Use only registered sources and the MDS baseline below. Do not discover sources by web search, and do not cite aggregators or third-party summaries.

The source registers record source names and canonical links only. Determine availability from the current run; do not rely on historical reachability assumptions.

MDS baseline

MDS is the subject of the research, not a peer. Report what MDS pages under src/pages/ already say in a separate subsection, never in the peer table.

  • Read the target page when it exists.
  • For a boundary topic, read the pages of the neighbouring components and any selection or pattern guideline.
  • Label a finding from a draft page as a draft. Never present it as published guidance.

Procedure

  1. Receive the subject, Decision topics, and search terms from the researcher workflow. When run directly, derive them as the workflow describes.
  2. Search with the supplied component name. Add an alternative term only when the target page or an official source provides evidence for it. Record every search term used; no approval step is required unless the terminology is ambiguous. Recheck an earlier absence when a newly attested term could change it.
  3. Check every Core source, plus any agreed Extended sources, for usage, content, accessibility, and relevant composition guidance. Record the actual outcome for every checked source: useful evidence found; checked with nothing relevant found; or inaccessible during this run.
  4. Read the MDS baseline pages.
  5. Return the section.

Answer a narrow factual question directly when the user is not asking for a research file.

Evidence rules

  • Link every finding to the official page that supports it.
  • Name the design system at the point of each finding.
  • NEVER describe an inaccessible source as checked or absent.
  • NEVER fill an evidence gap with general knowledge or a plausible value.
  • Label a fact observed only in an example, API table, or live demo as Observed, not documented guidance.
  • Record conflicting material from one source as a contradiction. Do not silently choose one side.
  • Separate accessibility guidance for authors from behaviour the external component implements.
  • Mark user-supplied evidence as Manually supplied and retain its source link or attachment name.
  • Treat external findings as evidence, not MDS policy. The writer must verify product and API decisions against MDS sources before using them.

Section format

Keep cells concise, but do not impose mechanical word limits. Use not documented only after the relevant official material was checked. Use — when a column genuinely does not apply. When no MDS page is relevant, write one row saying so.

Do not extract design tokens or CSS variables as part of this skill.

See also