agentsclimarketplace

Ios design router

Skill tyroneross/interface-built-right/skills/ios-design-router

Use as the entry point for iOS UI design work in IBR. Classifies apps into 6 archetypes (Utility, Content, Productivity, Consumer, Editorial, Tool/Pro) and routes to domain references.From its SKILL.md

Install
npx -y skills add tyroneross/interface-built-right --skill ios-design-router

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

  • 1 stars1 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.

SKILL.md

9.9 KB, as published. Nobody here has run it

iOS Design Router

Entry point for iOS UI design work in IBR. Classifies app archetype, applies defaults, routes to domain reference files for specific components.

Read this first on every new app or iteration session. Does NOT contain option catalogs — those live in domain reference files.

Principle Hierarchy

When rules conflict:

  1. Per-app design-config.md decisions — highest authority
  2. Explicit user instructions in current session
  3. Archetype defaults from this router
  4. Domain file options (prefer "preferred" options when archetype fits)
  5. HIG fundamentals (ios-design skill)

1. Archetype Classifier

Every iOS app fits one (sometimes two) of six archetypes. Archetype drives ~70% of design choices.

The Six Archetypes

ArchetypeCore PurposeDefining SignalExamples
UtilityComplete a specific task fastUser comes, does thing, leavesCalculator, Timer, FloDoro
Content/FeedBrowse informationScrollable, frequently refreshed contentNews, Social, Atomize News
ProductivityManage work/projectsPersistent user workspace, creation toolsNotion, Linear, Things
Consumer/HabitDaily engagement loopRetention-focused, streak/reward mechanicsDuolingo, Headspace
EditorialLong-form reading/mediaTypography-forward, reading experienceMedium, Arc
Tool/ProComplex workflowsPower-user controls, deep functionalityFigma, dev tools

Classification Questions

Ask in order. Stop at first strong match.

1. Is the core action completable in <60 seconds per visit?  → UTILITY
2. Is the primary screen a scrollable feed of items the user didn't create?  → CONTENT/FEED
3. Does the user CREATE persistent artifacts (docs, tasks, projects)?  → PRODUCTIVITY
4. Is daily return/retention a core success metric with streaks/rewards?  → CONSUMER/HABIT
5. Is long-form reading or media consumption the primary activity?  → EDITORIAL
6. Does the app target professionals with complex workflows?  → TOOL/PRO

Hybrid Archetypes

Some apps span two archetypes. Identify primary (dominant screen, main value) and secondary (supporting feature). Primary drives defaults; secondary applies to its specific feature area only.

Examples: Atomize News = Content/Feed (primary) + Tool/Pro (secondary). FloDoro = Utility (primary) + Productivity (secondary).

If archetype is unclear after the 6 questions, ask the user.


2. Archetype Defaults Table

Starting points before loading domain files. Narrows the option space.

CategoryUtilityContent/FeedProductivityConsumer/HabitEditorialTool/Pro
Primary action/screenONE clear, 1-stepONE + scroll contextONE primary + contextual secondaryONE engagement actionONE reading/nav actionONE primary + power menu
Task step budget1–2 steps2–3 steps2–3 steps1–2 steps1–2 steps3–5 steps
Tab barStandard iOS or hiddenFloating pill + auto-hideStandard iOSFloating pillHidden/minimalStandard iOS
Accent applicationCTA-OnlySemantic SystemSemantic SystemExpressive SpreadCTA-OnlySemantic System
Dark mode baseLayered Near-BlackTrue BlackLayered Near-BlackTrue Black or GlassLayered Near-BlackLayered Near-Black
List patternInset HairlineCard Per RowCard Per Row or GroupedCard Per RowFull-Width LineInset Hairline
Primary button depthDrop ShadowDrop ShadowDrop ShadowInner RimFlat or Drop ShadowFlat
Tap feedbackBG Highlight + OpacityBG HighlightBG Highlight + OpacityRipple on CTAsOpacity DimBG Highlight
OnboardingValue-First or NoneValue-FirstProgressive DisclosureInteractive Tutorial or QuizValue-FirstProgressive Disclosure
Skeleton loadingPulse FadeShimmerPulse FadeShimmerPulse FadePulse Fade
Empty stateSystem Icon + TextSystem Icon + TextText OnlyCustom IllustrationText OnlySystem Icon + Text
Toast routingBottom PillBottom Pill + Top BannerAll three channelsBottom Pill + CelebrationBottom PillAll three channels
CelebrationCheckmark MorphScore TickCheckmark MorphFull treatmentMinimalCheckmark Morph
Motion densityLow (2/screen)Medium (3/screen)Low (2/screen)High (4+/screen)Low (1–2/screen)Low (2/screen)
Haptic baselineKey momentsKey momentsKey momentsKey moments + customKey momentsKey moments
Profile headerCompact card (if any)Cover + overlap avatarCompact cardCover + overlap avatarLarge centeredCompact card

Reading the table:

  • Use defaults when no per-app config exists and no explicit user preference overrides
  • "or" between options: either is valid — match to secondary archetype
  • "All three channels" / "Full treatment": Consumer/Habit apps earn the maximum option set
  • Motion density numbers are a ceiling, not a floor

3. Domain Reference Files

When a design task requires detailed options beyond the defaults table, Read the relevant file from ${CLAUDE_PLUGIN_ROOT}/references/ios-design/.

Task DomainReference FileWhen to Load
Tab bars, back nav, transitions, sheets, page hierarchy, search1_navigation_structure.mdBuilding navigation or screen structure
Lists, cards, feeds, swipe actions, content resilience, grouping2_lists_cards_content.mdBuilding data display or content views
Buttons, tap feedback, haptics, toggles, form fields, placement3_buttons_touch_interactions.mdBuilding interactive controls or forms
Accent color, gradients, dark mode, elevation, typography, spacing, icons4_color_surface_typography.mdDefining visual identity or applying design tokens
Loading states, skeletons, empty states, errors, toasts, celebrations, onboarding, profiles5_motion_states_identity.mdAdding state handling, animations, or onboarding
Step counting, task flow validation, primary action rules6_task_economy.mdDesigning any multi-step flow or validating task efficiency

4. Clarification Protocol

Default behavior: decide using archetype defaults, flag choices in output for review.

When to DECIDE (don't ask)

  • Archetype is clear and default obviously fits
  • Low-impact choice (skeleton style, toast channel, micro-interaction timing)
  • User gave strong directional guidance earlier in the session

Flag the decision in output (see §5).

When to ASK (stop and clarify)

  • Archetype is ambiguous or hybrid primary is unclear
  • High-impact, disruptive-to-change-later decisions:
    • Tab bar style (affects every screen)
    • Accent application tier (affects entire visual language)
    • Dark mode treatment (affects every surface)
    • Primary navigation pattern
    • Onboarding structure (affects first-run funnel)
  • Conflicting signals in the session
  • About to ADD an optional element to a screen (Task Economy — see below)

Task Economy: Validate Before Adding

Before adding any of the following, validate with the user:

  • A secondary action to a screen that has a clear primary
  • A confirmation dialog (unless action is truly destructive)
  • A settings toggle for a behavior
  • An option that could be inferred from context
  • A step to a flow that was previously one screen
  • A "Welcome" screen before a feature is usable

Exception — just decide: The addition is required by the task, the user explicitly requested it, or it's a CP-required element (empty state, error handler, accessibility label).

Validation question format:

I'm about to add [element] to [screen].
Without it: [simpler version]
With it: [what it adds]
Cost: +[N] step(s) / +[N] decision(s) for the user
Should I add it?

Task Economy: Step Counting

For any task flow: define the outcome, count theoretical minimum steps, count current design steps, look for cuts if gap is wider than 1–2, report count in output.

When NOT to Ask

  • Platform fundamentals (how SwiftUI works, HealthKit patterns)
  • HIG principles (not preferences)
  • Things already answered in earlier turns
  • Minor timing/easing values

5. Output Flagging Format

Every design choice made without asking must be surfaced for audit:

## Design Choices Made

**Inferred archetype:** [type]
**Reason:** [one sentence]

**Primary action(s) per screen:**
- [Screen]: [action] — N step(s) to complete

**Step counts for key tasks:**
- [Task]: [N steps] — floor is [theoretical minimum]

**Choices (review before committing):**
- **[Category]:** [option chosen] — [why, one sentence]

**Flagged as tentative:**
- [Choice] — [what to validate]

**Elements NOT added (Task Economy validated):**
- [What was considered] — [why cut]

6. Ask-First Trigger List

Always ask on a new app:

  1. Archetype (if unclear after classification questions)
  2. Brand accent color
  3. Tab bar presence and style
  4. Dark mode behavior

Ask conditionally: 5. Onboarding flow existence 6. Login/auth pattern 7. Charts usage 8. Custom vs system design approach 9. Target iOS version 10. App-specific voice/tone 11. Any optional UI element addition (Task Economy — applies throughout)


Related Skills

  • ios-design: HIG fundamentals — navigation rules, color, typography, SF Symbols, haptics, materials. What the platform requires.
  • apple-platform: Architecture patterns, SwiftData, concurrency, CI/CD, TestFlight. How to build it.
  • This skill (ios-design-router) routes design decisions to the right domain reference and applies archetype defaults.

Keep looking

Skills are one crate of 627,801. 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.