agentsclimarketplace

Ios design system atoms

Skill srinitude/ios-design-system-atoms/skills/ios-design-system-atoms

Agent Skill for deterministic iOS design-system atom YAML from reference images

Install
npx -y skills add srinitude/ios-design-system-atoms --skill ios-design-system-atoms

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when reference images, screenshots, moodboards, or visual design-system YAML should become a complete deterministic YAML inventory of iOS design-system atoms. Handles iOS atomic tokens, primitive visual atoms, static values, dynamic adaptations, accessibility variants, SwiftUI/UIKit handoff fields, and strict no-null/no-empty/no-unknown validation.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

7.6 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

iOS Design System Atoms

Goal

Generate every foundational atom needed to implement an iOS design system from reference images. The final artifact is always parser-valid YAML using the contract in references/atoms-yaml-contract.md.

An atom is a reusable lowest-level design primitive: color, type, spacing, sizing, layout, shape, stroke, elevation, material, opacity, gradient, texture, icon, image treatment, motion, haptic, sound, copy, and z-index token. Every atom must include static values and dynamic adaptation rules.

Non-Negotiables

  • Start from reference images. If no visual reference or already-extracted visual design-system YAML is available, ask for it before generating atoms.
  • Invoke visual-design-system-extractor with the reference images first. Use its validated YAML output as the source visual system for atom extrapolation.
  • Final output must be YAML only unless the user explicitly asks for package maintenance, explanation, or files.
  • Preserve the exact top-level order and required nested object shapes from references/atoms-yaml-contract.md.
  • Do not emit null, empty strings, empty lists, empty mappings, undefined, unknown, missing, todo, tbd, n/a, or placeholder values.
  • Do not use wall-clock timestamps, random IDs, or run-dependent values. Derive IDs from stable source order, source filenames, visible evidence, or a source fingerprint.
  • If a field is not directly visible, fill it through a deterministic fallback and record the fallback in provenance.decision_rule with confidence: low.
  • Every atom object must include static, dynamic, provenance, implementation, and qa sections.
  • Dynamic adaptations are required even for visually simple atoms: light/dark, accessibility, interaction state, device context, locale direction, motion context, and data context.

Workflow

Progress:

  • Confirm reference input.
  • Run visual extraction.
  • Normalize source evidence.
  • Extrapolate static atoms.
  • Extrapolate dynamic atoms.
  • Validate YAML.

1. Confirm Reference Input

Proceed when the user supplies one of:

  • attached reference images
  • local image paths
  • screenshots or moodboards
  • a visual design-system YAML artifact from visual-design-system-extractor

If multiple references are supplied, preserve their order. Assign deterministic source IDs as ref_001, ref_002, and so on.

2. Run Visual Extraction

Use visual-design-system-extractor with the same reference images. Ask it for its native visual design-system YAML, not for iOS atoms.

The extractor output becomes extraction_bridge.visual_design_system_extractor.output_summary and drives these sections:

  • static_atoms.color from extracted color, lighting, material, and accessibility evidence
  • static_atoms.typography from extracted typography and rare typeface candidates
  • static_atoms.spacing, layout, shape, and stroke from spacing, grid, sizing, borders, and radii
  • static_atoms.elevation, material, opacity, gradient, and texture from surface treatment, shadow, gradient, and rendering evidence
  • static_atoms.iconography and imagery from icon, illustration, rendering, and photography evidence
  • static_atoms.motion, haptics, and sound from motion, interaction, tone, and platform adaptation evidence
  • dynamic_atoms from extracted state variants, responsive rules, accessibility notes, and platform adaptations

If the extractor cannot run, stop and explain the blocked dependency. Do not invent image evidence.

3. Normalize Evidence

Before writing atoms, create a stable source fingerprint:

  1. Prefer SHA-256 of ordered image bytes when local files are available.
  2. Otherwise hash ordered source IDs, filenames, dimensions if known, and extractor meta fields.
  3. Use the first 12 lowercase hex characters in determinism.source_fingerprint.

Separate direct visual evidence, deterministic iOS defaults, and extrapolated values in each atom's provenance object. Do not collapse weak evidence into direct evidence.

4. Generate Atom Inventory

Read references/atoms-yaml-contract.md before producing the final YAML.

Create all required static atom categories:

  • color
  • typography
  • spacing
  • sizing
  • layout
  • shape
  • stroke
  • elevation
  • material
  • opacity
  • gradient
  • texture
  • iconography
  • imagery
  • motion
  • haptics
  • sound
  • copy
  • z_index

Use deterministic token IDs:

atom.<category>.<role>.<variant>

Examples:

atom.color.surface.primary
atom.typography.body.default
atom.motion.spring.emphasized

Every token must include the required atom object fields from the contract. Use iOS-native implementation mappings where possible: SwiftUI Color, Font, Material, Animation, SymbolEffect, SensoryFeedback, Layout, and UIKit equivalents.

5. Generate Dynamic Adaptations

Create every required dynamic atom section:

  • color_scheme_adaptations
  • accessibility_adaptations
  • interaction_state_adaptations
  • device_context_adaptations
  • locale_context_adaptations
  • motion_context_adaptations
  • data_context_adaptations
  • system_material_adaptations

Each dynamic section must specify:

  • rule_id
  • affected_atom_categories
  • default_behavior
  • variants
  • implementation_notes

Variants must be concrete and non-empty. If reference images do not show a variant, derive it from the base atom and record that derivation.

6. Validate

When shell tools are available, draft the YAML to a temporary file and run:

uv run scripts/validate-ios-atoms-yaml.py /tmp/ios-design-system-atoms.yaml

If PyYAML is installed directly, run python3 scripts/validate-ios-atoms-yaml.py /tmp/ios-design-system-atoms.yaml.

Fix all reported errors before returning or saving the artifact. If validation cannot run, manually check every item in quality_gates.validation_checks and report the limitation.

Gotchas

  • Do not treat dynamic as runtime metadata. It means adaptive design behavior across iOS contexts.
  • Do not use "unknown" for weak evidence. Choose a deterministic fallback, lower the confidence, and explain the rule.
  • Do not emit empty optional-looking structures. If a section is required, it must contain at least one concrete value.
  • Do not add top-level sections for convenience. Put additions under the nearest existing mapping using snake_case keys.
  • Do not browse for brand, font, or product comparisons unless the user explicitly asks. The visual extractor and the reference images are the source of truth.

Support Files

  • references/atoms-yaml-contract.md: canonical YAML schema, key order, atom object shape, category requirements, and deterministic fallback rules.
  • references/agent-skills-compliance.md: package-maintenance and publication guidance.
  • scripts/schema_tools.py: prints contract sections and the canonical top-level skeleton for quick reference.
  • scripts/validate-ios-atoms-yaml.py: mechanical YAML validation for top-level order, required nested fields, atom object shape, confidence values, and banned placeholder values.

Gives 0 of the 12 instructions most design systems skills give in ~1.6k tokens

Counted across 528 of the 534 authors here whose files we hold, read 2026-08-06

  • create a custom theme if neededin 54 of 528, across 10 files
  • read the corresponding theme filein 54 of 528, across 10 files
  • ask which theme to applyin 53 of 528, across 9 files
  • show the theme showcasein 53 of 528, across 9 files
  • maintain visual identity across all slidesin 50 of 528, across 6 files
  • apply the specified colors and fontsin 47 of 528, across 3 files
  • get explicit confirmationin 45 of 528, across 1 file
  • Generate a design system before codingin 19 of 528, across 6 files
  • Maintain at least 4.5:1 color contrast ratioin 19 of 528, across 8 files
  • Describe component shapes, colors, shadows, and interaction statesin 18 of 528, across 4 files
  • Check Python installation and install if missingin 17 of 528, across 4 files
  • Default to html-tailwind if stack is unspecifiedin 17 of 528, across 4 files

Said here and by no other author read

  • Ask for reference images before generating atoms
  • Invoke visual-design-system-extractor with the reference images first
  • Emit final output as YAML only
  • Preserve exact top-level order from the contract
  • Include static, dynamic, provenance, implementation, and qa sections
  • Create all required static atom categories

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.