# Hodios paste pack: Design systems
Everything in Design systems from Hodios, the open prompt library by Hermes IDE: 7 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Design systems
- [Audit design consistency across screens](#audit-design-consistency) (prompt)
- [Define a design token architecture](#define-design-tokens) (prompt)
- [Define an icon system](#define-iconography) (prompt)
- [Design a dark theme](#design-dark-mode) (prompt)
- [Plan design system governance](#plan-design-system-governance) (prompt)
- [Write a design-system component spec](#write-component-spec) (prompt)
- [Write accessibility annotations](#write-accessibility-annotations) (prompt)
---
## Audit design consistency across screens
`audit-design-consistency` · prompt · Design systems · https://hermes-ide.com/prompts/audit-design-consistency
Inventories spacing, type, colour, radii and component variants across screens, finds near-duplicates and plans their consolidation. Use before building or cleaning up a design system.
````markdown
Products drift: 14 greys that should be 6, button heights of 36, 38 and 40 px, three ways to show an error, spacing that is "about 16" everywhere. Each difference is small, but together they slow every designer and engineer and make the product feel unreliable. An interface inventory makes the drift visible, separates intentional differences from accidental ones, and turns the clean-up into an ordered plan instead of a big-bang redesign.
Audit these screens for consistency.
[SCREENS]
1. **Inventory** every distinct value you can identify, per property: colours (text, backgrounds, borders), type (family, size, weight, line height), spacing (padding, gaps, margins), radii, borders, shadows, icon sizes and styles. For each value, record where it appears and how often.
2. **Cluster near-duplicates:** values a user cannot tell apart or that serve the same role (`#6B7280` and `#6B7380`, 15 px and 16 px body text, 7 px and 8 px radius). Propose one canonical value per cluster, preferring the design system's value, then the most frequent one.
3. **Check the scale:** flag values off the spacing and type scale (or, without a design system, propose the scale implied by the most common values, for example a 4 px base).
4. **Component variants:** list each component type (buttons, inputs, cards, alerts, tabs, modals) and every visual or behavioural variant found. Mark each variant keep, merge or remove, and name variants that exist for a real reason.
5. **Intentional versus accidental:** a difference is intentional if it signals a different role or state. Do not merge those; say why they differ.
6. **Consolidation plan:** order the work by impact (frequency times visibility) and risk. Start with tokens for colour and type, then spacing, then components. Group changes so each can ship on its own.
7. If screenshots are low resolution or the description lacks values, report what can be judged visually and say what exact values are needed (for example an exported style list).
- Report only values present in the input. Do not invent counts; when you can only estimate from images, say "approximately" and mark it.
- Colour values read from screenshots are approximate because of compression and colour profiles. Say so and recommend confirming from source files.
- Do not redesign. The aim is fewer, consistent values, not a new look.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
The size of the drift in numbers (for example "11 text colours for 4 roles") and the top 3 actions.
## Inventory
One table per property: | Value | Where used | Count | Cluster | Verdict (keep / merge into X / remove) |
## Component variants
| Component | Variants found | Keep / merge / remove | Reason |
## Consolidation plan
Numbered phases, each with scope, impact, risk and what to check after.
## Mapping
| Old value | New value or token | Screens affected |
## Questions
````
---
## Define a design token architecture
`define-design-tokens` · prompt · Design systems · https://hermes-ide.com/prompts/define-design-tokens
Designs a three-tier design token architecture (primitive, semantic, component) with naming conventions, theming rules and a sample token file. Use when starting or restructuring a design system.
````markdown
Token systems break in familiar ways: components reference raw values like `blue-500` directly, so a dark theme means editing every component; names describe the value (`color-light-grey`) instead of the role, so they lie the moment the value changes; and hundreds of one-off component tokens appear that nobody can maintain. A sound architecture separates what a value is (primitive) from what it is for (semantic), adds component tokens only where a component genuinely needs its own knob, and makes theming a matter of remapping the semantic layer.
Design the token architecture.
[BRAND_INPUTS]
Themes: light, dark.
If no platforms were given, assume web plus a design tool, and say so.
1. **Principles:** 3 to 5 rules for the system, including "components never reference primitives".
2. **Naming:** define the grammar, for example `{category}.{concept}.{variant}.{state}` for semantic tokens (`color.text.secondary`, `color.bg.danger.hover`) and `{category}.{hue or scale}.{step}` for primitives (`color.blue.600`, `space.4`). Give the allowed words for each segment, the casing, and how the names map to each platform (CSS custom properties, Swift, Kotlin or XML).
3. **Primitive tokens:** colour ramps derived from the brand inputs (10 to 12 steps per hue, built in a perceptual space such as OKLCH so steps look even; list the target lightness per step and mark hand-converted hex values as approximate, to be regenerated by a colour tool), neutrals, spacing scale (a 4 px base is common), radii, border widths, type families, sizes, weights and line heights, shadows or elevation, and motion durations and easings. Give values.
4. **Semantic tokens:** the role layer, grouped by category: backgrounds and surfaces, text, borders, interactive (default, hover, pressed, focus, disabled), status (success, warning, danger, info), and elevation. Show the value for each theme as a reference to a primitive.
5. **Component tokens:** only where a component needs to diverge from the semantic layer or be tuned independently (for example `button.primary.bg`), with the rule for when one may be added.
6. **Token file sample:** a JSON excerpt in the W3C Design Tokens Community Group format (`$value`, `$type`, aliases as `{color.blue.600}`), covering one primitive group, a few semantic tokens with per-theme values, and one component token. Show how themes are expressed (separate files or sets per theme).
7. **Theming rules:** how each theme in light, dark remaps the semantic layer; for dark themes, use lighter surfaces for higher elevation instead of shadows, avoid pure black and pure white body text, and re-check contrast. State that every text-on-background semantic pair must meet 4.5:1 (3:1 for large text and UI) in every theme, and list the pairs to verify.
8. **Platform delivery:** how the source becomes platform outputs with a token build tool, and which tokens each platform needs.
9. **Governance:** how tokens are proposed, deprecated (alias to the successor before removal) and versioned.
10. If brand inputs are too thin to derive colours (no colour at all), ask for them, or propose placeholder hues clearly marked "placeholder".
- Do not claim contrast ratios you have not computed. Mark pairs "to verify" unless you show the calculation.
- Keep the semantic layer small enough to learn: aim for tens of semantic colour tokens, not hundreds.
- Names describe purpose, never appearance, at the semantic and component tiers.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Markdown with the contract's sections in order. Use tables for the primitive, semantic (one column per theme) and component tiers, and a fenced `json` block for the token file sample.
````
---
## Define an icon system
`define-iconography` · prompt · Design systems · https://hermes-ide.com/prompts/define-iconography
Defines an icon system with grid and keylines, stroke and corner rules, sizes, naming, metaphors, accessibility and contribution rules. Use when a design system creates or tidies up its icons.
````markdown
Icon sets drift quickly: icons from three libraries mixed together, strokes of 1.5 and 2 pixels side by side, a trash can that means "delete" on one screen and "archive" on another, icons named after what they do in one feature so the same glyph has four names, and icon-only buttons that screen readers announce as "button". An icon system fixes the geometry so every icon looks like part of one family, fixes the meaning so each glyph means one thing, and makes the rules clear enough that a new contributor can draw an icon that fits.
Define the icon system.
[BRAND_STYLE]
If the brand style is too thin to set construction rules (no typeface, radius, line character or existing icons), ask up to three questions and stop.
1. **Principles.** Three or four principles that follow from the brand (for example "simple enough to read at 16 pixels", "friendly but precise: rounded terminals, geometric forms") and that rule something out.
2. **Grid and keylines.** A base grid (commonly 24 by 24 with 2 units of padding, giving a 20 by 20 live area), keyline shapes (circle, square, portrait and landscape rectangles) so icons of different shapes look the same size, and pixel-snapping rules.
3. **Construction rules.** Stroke weight in grid units and whether it scales with size, stroke caps and joins, corner radius (outer and inner) matched to the brand's UI radius, minimum gap between strokes, how to handle angles (for example multiples of 15 or 45 degrees), filled versus outlined construction, perspective (flat, no 3D), and level of detail.
4. **Sizes and scaling.** The sizes supported (for example 16, 20, 24 and 32), whether smaller sizes get simplified drawings, alignment with text (optical centring with text baseline and line height), and touch-target padding around icon buttons.
5. **Styles and states.** Outlined and filled styles and when each is used (for example filled for the selected state in navigation), colour rules (icons inherit text colour; colour only for status, never as the only signal), and disabled and active states.
6. **Metaphors.** For each concept in the icon needs (or common product concepts if none were given), propose the metaphor, note ambiguity or cultural risk (a floppy disk for save, a mailbox that looks different across countries, hand gestures, religious symbols), and say whether it needs a text label. Mark concepts that should not be icons at all because no metaphor is widely understood. Assign each glyph one meaning only.
7. **Naming.** Name icons by what they depict, not by the action in one feature ("trash", not "delete-project"), in a consistent pattern (for example object then modifier: "arrow-left", "bell-off", "heart-filled"), lowercase kebab case, with a list of aliases for search.
8. **Accessibility.** Decorative icons hidden from assistive technology; meaningful icons and icon-only buttons with an accessible name; visible text labels for important or ambiguous actions; non-text contrast of at least 3:1 against the background for meaningful icons; tooltips that are not the only label; mirroring rules for right-to-left languages (directional icons flip, others such as a clock or media play do not).
9. **Production and contribution.** Source file structure, SVG export rules (single path where possible, no hidden layers, `currentColor` fills, consistent viewBox, no embedded raster), optimisation, versioning, and a contribution checklist for new icons including review steps.
- Base geometry on the brand description; when you assume a value, say so.
- If the team uses an existing open-source icon library, recommend extending it with its own rules rather than mixing styles, and check its licence terms before modification.
- Do not draw or invent icons as images; describe them precisely enough for a designer.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Markdown with the contract's sections as `##` headings. Construction rules as a table:
| Property | Rule | Reason |
Metaphors as a table:
| Concept | Metaphor | Ambiguity or risk | Needs label? | Icon name |
End with the contribution checklist as yes-or-no items.
````
---
## Design a dark theme
`design-dark-mode` · prompt · Design systems · https://hermes-ide.com/prompts/design-dark-mode
Designs a dark theme from an existing light palette, covering surface elevation, semantic colour mapping, contrast checks, images, charts and token changes. Use when a design system adds dark mode.
````markdown
Dark themes made by inverting colours fail in familiar ways: pure black backgrounds with pure white text that glare and smear on OLED screens, saturated brand colours that vibrate against dark grey, shadows that vanish so cards lose their edges, logos that disappear, charts whose colours become indistinguishable, and contrast that nobody measured. A dark theme is a second mapping of the same semantic roles, built on surfaces that express elevation and checked pair by pair for contrast.
Design a dark theme for this palette.
[LIGHT_PALETTE]
If the palette has no colour values (hex or equivalent), ask for them and where each is used, and stop; do not guess the colours.
1. **Approach.** If the palette has no semantic tokens, propose the semantic layer first (background, surface levels, text primary, secondary and disabled, border, primary and on-primary, focus, success, warning, danger, info, overlay) and map the light theme onto it, so both themes switch at the semantic level and components never reference primitives directly.
2. **Surfaces and elevation.** Choose a dark base that is a very dark grey, not pure black, unless the user wants a true-black OLED option (offer it as a variant). Define 3 to 5 surface levels where higher elevation is lighter, because shadows are hard to see on dark backgrounds; add subtle borders where adjacent surfaces need separation. Tint the neutrals slightly with the brand hue only if the light theme does.
3. **Semantic token mapping.** For every semantic token, give the light value, the dark value (reusing existing primitives where possible, or a new primitive marked "(new)"), and the reason. Text should not be pure white on large areas; use an off-white for primary text and lower-emphasis values for secondary text that still pass contrast.
4. **Contrast checks.** Compute the WCAG 2 contrast ratio for every text and UI pair in the dark theme: text on each surface level, on primary buttons, links, placeholder and disabled text, borders of inputs, focus rings and status colours on surfaces. Use relative luminance (linearise each sRGB channel: c/12.92 if c is 0.04045 or less, otherwise ((c + 0.055) / 1.055) ^ 2.4; L = 0.2126 R + 0.7152 G + 0.0722 B; ratio = (L1 + 0.05) / (L2 + 0.05)). Targets: 4.5:1 for normal text, 3:1 for large text and for UI components and meaningful graphics. Show each ratio to one decimal place, mark pass or fail, and fix every failure. Recommend confirming the final values with a contrast checker.
5. **Brand and status colours.** Use lighter, slightly less saturated tones of brand and status colours on dark surfaces so they keep contrast without vibrating. Check that on-primary text still passes on the adjusted primary. Keep the hue recognisable.
6. **Images and illustrations.** Logo variants for dark backgrounds, transparent images and icons with dark strokes, screenshots and product shots, illustrations that need a dark version, and whether to reduce the brightness of large photos.
7. **Data visualisation.** Re-check categorical and sequential chart palettes on the dark surface (distinguishability and 3:1 against the background), gridlines and axes at low emphasis, and that no chart relies on colour alone.
8. **Platform notes.** For the platforms given: on web, a theme attribute plus the `prefers-color-scheme` media query and the `color-scheme` property, and avoiding a flash of the wrong theme on load; on iOS and Android, mapping to the system's semantic or dynamic colours where the product uses them; email clients that invert colours unpredictably. Offer the choice of light, dark or system in settings.
9. **Rollout and QA.** Token changes to make, components most likely to break (anything with hard-coded colours, shadows or images), and a test checklist: each component in every state in both themes, dim and bright environments, OLED devices, increased-contrast settings and screenshots in documentation.
- Do not claim a contrast ratio you did not compute from the hex values. If a value is unknown, write "to check".
- Do not invert the light theme; map each role deliberately.
- Keep the brand recognisable; do not introduce new hues without a reason.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Markdown with the contract's sections as `##` headings. The mapping as a table:
| Semantic token | Light | Dark | Primitive | Note |
The contrast checks as a table:
| Foreground | Background | Ratio | Target | Pass/fail | Fix |
End "Rollout and QA" with the token changes as a code block in the format the user's tokens use, or as JSON if unknown.
````
---
## Plan design system governance
`plan-design-system-governance` · prompt · Design systems · https://hermes-ide.com/prompts/plan-design-system-governance
Plans how a design system is run, covering ownership, the contribution model, versioning, deprecation, adoption tracking and support. Use when setting up or fixing how a design system is run.
````markdown
Design systems rarely fail on components; they fail on operations. The central team becomes a bottleneck, product teams fork or detach components to meet deadlines, breaking changes land without notice, nobody knows who may approve a new pattern, and adoption is reported as "lots of teams use it" with no data. Governance is the set of agreements about who decides, how changes get in, how they get out, and how the team knows whether the system is working, sized to the organisation rather than copied from a large company's blog post.
Plan the governance for this design system.
[ORG_CONTEXT]
1. **Diagnosis.** Summarise the situation and the 3 to 5 problems governance must solve, linked to the evidence given. If the context is too thin to size the model (no team counts, no idea of who maintains the system), ask up to four questions and stop.
2. **Team model.** Recommend centralised (a dedicated team builds and owns everything), federated (designers and engineers from product teams contribute and decide together) or hybrid (a small core team owns the foundations and quality, product teams contribute), sized to the organisation. Give roles, rough capacity (people or percentage of time), and the trade-off of the choice.
3. **Decision rights.** A table of decisions (new foundation token, new component, change to an existing component, a one-off exception, removing something, accessibility standards) with who proposes, who decides, who must be consulted and the expected turnaround.
4. **Contribution process.** Stages from request to release: check whether something existing solves it, proposal with the problem and evidence of reuse (for example needed by at least two teams), design and engineering review, accessibility review, documentation, release. Define contribution types: fix, enhancement, new pattern, and what each needs. Say where local, product-specific components live and when they are promoted into the system. Include a template for a contribution proposal.
5. **Versioning and releases.** Semantic versioning for code packages and design libraries: what counts as a major (breaking API, visual changes that break layouts, renamed or removed tokens), minor and patch change; release cadence; changelog format written for consumers; migration guides and codemods for breaking changes; keeping design and code libraries in step.
6. **Deprecation.** The lifecycle (experimental, stable, deprecated, removed), how a deprecation is announced (changelog, warnings in code and design tools, docs banner), the minimum notice period, migration support, and what happens to teams that cannot migrate in time.
7. **Adoption and health metrics.** Metrics that can actually be collected: component coverage in code (share of UI using system components, from code scans), version lag per product, detached or overridden instances in design files, contribution volume and cycle time, open issues and time to first response, accessibility defects, and a periodic satisfaction survey. For each, how to measure it and a starting target. Warn against vanity metrics such as number of components.
8. **Support.** Channels (a request form, a chat channel, office hours, design and code reviews), response-time expectations, documentation ownership, onboarding for new designers and engineers, and a community of champions in product teams.
9. **First 90 days.** A phased plan with the first actions, owners by role and what will be reported to leadership.
- Size everything to the organisation described; a 3-team start-up does not need a review board.
- Do not invent current metrics or team facts; mark assumptions and starting targets as proposals to calibrate.
- Recommend tools only by type (component analytics, design-file usage reports, code scanners), not by vendor, unless the user named their tools.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Markdown with the contract's sections as `##` headings. Decision rights as a table:
| Decision | Proposes | Decides | Consulted | Turnaround |
Metrics as a table:
| Metric | How measured | Starting target | Review cadence |
The contribution proposal template in a code block.
````
---
## Write a design-system component spec
`write-component-spec` · prompt · Design systems · https://hermes-ide.com/prompts/write-component-spec
Writes a design-system component spec covering anatomy, variants, states, behaviour, tokens, content rules, dos and don'ts, and accessibility. Use when adding or documenting a component.
````markdown
Component docs often show the happy-path picture and a props table, and leave out what matters for consistent use: when not to use it, what every state looks like, how it behaves with a keyboard and a screen reader, which tokens it reads, and what to do with long or translated text. Teams then rebuild the same component three ways. A good spec is the single source both designers and engineers build from.
Write the spec for the **[COMPONENT]** component.
1. **Overview:** what it is for in one sentence, when to use it, and when not to (name the component to use instead).
2. **Anatomy:** numbered parts (container, label, icon, and so on), each marked required or optional.
3. **Variants and sizes:** each variant with the job it does. Keep the set minimal; if two variants differ only cosmetically, propose merging them. Give sizes with the minimum target size each must keep.
4. **States:** default, hover, focus-visible, active or pressed, disabled, and those that apply (selected, loading, error, read-only, expanded). Say what changes visually and what the disabled state communicates, and whether a disabled control should instead stay enabled and explain why it cannot act.
5. **Behaviour:** interactions with mouse, touch and keyboard, timing (for example auto-dismiss and how pausing works), overflow and truncation, responsive behaviour, and motion with a reduced-motion alternative.
6. **Content:** label rules, length limits, casing, icon use, and how it handles long, empty and translated text (allow about 30 to 40 percent expansion).
7. **Tokens:** a table of the semantic tokens each part uses. Use the system's token names if given; otherwise propose names following `{category}.{property}.{variant}.{state}` and mark them "proposed". Never hard-code raw values.
8. **Accessibility:** the native element or WAI-ARIA Authoring Practices pattern it should follow, role and accessible name, keyboard map, focus management, announcements for dynamic changes, contrast and target-size requirements, and what must not rely on colour alone.
9. **Dos and don'ts:** 4 to 8 pairs, each a concrete situation, not a general principle.
10. **Related components** and how to choose between them.
11. If the component name is ambiguous (a "card" can be a container or an interactive tile), state the interpretation you chose, or ask if the difference would change most of the spec.
- Prefer native platform elements over custom ARIA. If ARIA is needed, specify it completely.
- Do not invent the system's existing tokens, components or values. Mark anything you propose as "proposed".
- Keep it implementation-neutral: describe behaviour and properties, not one framework's code.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Markdown with the sections from the contract, in order. Use tables for anatomy, variants, states, tokens and the keyboard map. End with Open questions.
````
---
## Write accessibility annotations
`write-accessibility-annotations` · prompt · Design systems · https://hermes-ide.com/prompts/write-accessibility-annotations
Annotates a screen design for engineering handoff with accessibility notes - headings, landmarks, focus order, accessible names, states, keyboard behaviour and announcements - mapped to WCAG.
````markdown
You are an accessibility specialist who writes annotations on designs before they reach engineering. Most accessibility defects are decided in design but discovered in testing: headings chosen for looks, icon buttons with no name, a focus order that jumps around, custom widgets with no keyboard model, and status changes that screen-reader users never hear. Annotations make these decisions explicit so engineers do not guess. You prefer native HTML elements over ARIA (the first rule of ARIA), follow the WAI-ARIA Authoring Practices keyboard patterns for custom widgets, and reference WCAG 2.2 success criteria where they apply.
[SCREEN_DESCRIPTION]
If the description is too thin to annotate (no list of elements or interactions), ask for an element-by-element description or layer list and stop.
1. **Annotation key.** The annotation types you use: heading, landmark, focus order, accessible name, alternative text, state, keyboard, announcement, and notes.
2. **Page structure.** The page title (unique and descriptive), landmarks (header, navigation with a distinguishing name if there are several, main, complementary, footer, search, named form regions), a skip link if there is repeated navigation, and the heading outline (one h1, no skipped levels) mapping each visual heading to its level. Visually styled text that is not a heading is called out.
3. **Focus order.** A numbered order for every interactive element, following the reading order. Flag anything where visual order and logical order differ, and focus traps that are intended (open dialogs) versus accidental. Note focus visibility and that sticky headers or footers must not hide the focused element.
4. **Annotations.** For each element, numbered to match the design: the native element or role, the accessible name (matching or starting with the visible label), description or hint linked to it, states and properties (expanded, selected, pressed, current page, disabled, invalid, required, busy), alternative text (or "decorative - hide from assistive technology"), and the WCAG 2.2 criteria it addresses.
5. **Component behaviour.** For each custom or complex component (dialog, menu, tabs, combobox, date picker, carousel, accordion, toast): the keyboard interactions, where focus goes on open and on close, and what is announced. Say "use the library component" when the components input says it is already accessible.
6. **Announcements.** Dynamic changes that must be announced without moving focus (form errors summary, items added to a cart, loading finished, results count, toasts): the exact text and politeness (polite or assertive). Errors: the message linked to its field and the summary behaviour.
7. **Visual checks to confirm.** Items design must verify that you cannot see from a description: text contrast at least 4.5:1 (3:1 for large text), 3:1 for control boundaries, focus indicators and meaningful icons, targets at least 24 by 24 CSS pixels, no meaning by colour alone, and reflow at 320 CSS pixels width.
8. **Open questions.** Decisions the designer must make before handoff.
- Annotate only what is described; mark assumptions ("assumed: opens a dialog") and do not invent elements.
- Native HTML first. Use ARIA only when no native element fits, and never add ARIA that duplicates native semantics.
- Cite a WCAG 2.2 criterion only by its correct number and name; if unsure, describe the requirement without a number.
- Write accessible names and announcements as exact strings in quotes.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Annotation key
## Page structure
Page title, landmark list, heading outline as an indented list.
## Focus order
Numbered list.
## Annotations
| # | Element | Element or role | Accessible name | States and properties | Notes | WCAG |
## Component behaviour
For each component: keyboard table (Key | Action), focus on open and close, announcements.
## Announcements
| Trigger | Announcement (exact text) | Politeness |
## Visual checks to confirm
Checklist.
## Open questions
| 7 | Icon-only button (trash icon) on each row | button | "Delete invoice INV-2041" (row-specific) | - | Tooltip shows "Delete"; confirmation dialog follows | 4.1.2 Name, Role, Value; 2.5.8 Target Size (Minimum) |
````