mobile-ios-design
Master iOS Human Interface Guidelines and SwiftUI patterns for building native iOS apps. Use when designing iOS interfaces, implementing SwiftUI views, or ensuring apps follow Apple's design principles.
76
54%
Does it follow best practices?
Impact
89%
1.36xAverage score across 6 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/ui-design/skills/mobile-ios-design/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is competent with a clear 'Use when' clause and reasonable domain specificity around iOS and SwiftUI. However, it lacks concrete action verbs describing specific capabilities (e.g., building navigation hierarchies, implementing accessibility, creating custom components) and could benefit from more natural trigger terms users would actually say. The description reads more like a general expertise statement than a list of actionable capabilities.
Suggestions
Add specific concrete actions like 'build navigation stacks, implement tab views, create adaptive layouts, apply accessibility modifiers, design custom SwiftUI components'.
Expand trigger terms to include common variations users would say: 'HIG', 'iPhone app', 'iPad layout', 'SwiftUI view', 'iOS UI', 'Apple design guidelines', '.swift'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (iOS/SwiftUI) and mentions some actions ('designing iOS interfaces', 'implementing SwiftUI views', 'ensuring apps follow Apple's design principles'), but these are fairly broad and don't list specific concrete actions like 'create navigation stacks, implement tab views, build adaptive layouts'. | 2 / 3 |
Completeness | Clearly answers both 'what' (master iOS HIG and SwiftUI patterns for building native iOS apps) and 'when' with an explicit 'Use when...' clause covering three trigger scenarios: designing iOS interfaces, implementing SwiftUI views, or ensuring Apple design principle compliance. | 3 / 3 |
Trigger Term Quality | Includes relevant keywords like 'iOS', 'SwiftUI', 'Human Interface Guidelines', and 'Apple's design principles', but misses common user variations like 'HIG', 'UIKit', 'iPhone app', 'iPad', 'mobile UI', '.swift files', or specific component names users might mention. | 2 / 3 |
Distinctiveness Conflict Risk | Reasonably specific to iOS/SwiftUI but could overlap with general Swift programming skills, mobile development skills, or UI/UX design skills. The mention of 'Human Interface Guidelines' adds some distinctiveness, but 'building native iOS apps' is broad enough to conflict with other iOS-related skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads like a SwiftUI tutorial or documentation summary rather than a targeted skill file. It covers too many topics at surface level, explains concepts Claude already knows well (basic HIG principles, what semantic colors are), and doesn't provide novel or project-specific guidance that would justify the token cost. The code examples are its strongest aspect—they're executable and well-formed—but the surrounding content is largely redundant with Claude's training data.
Suggestions
Reduce content by 60-70%: Remove explanations of HIG principles, what SF Symbols are, and basic SwiftUI concepts. Focus only on non-obvious patterns, gotchas, or project-specific conventions Claude wouldn't already know.
Split into focused reference files: Create separate files for navigation patterns, layout patterns, accessibility checklist, and common issues, with SKILL.md serving as a concise overview with links.
Add a workflow with validation: Include a clear sequence for building an iOS view (e.g., 1. Define layout → 2. Preview in multiple Dynamic Type sizes → 3. Test Dark Mode → 4. Run VoiceOver audit → 5. Check iPad multitasking).
Remove the 'When to Use This Skill' section entirely—it's metadata that belongs in frontmatter, not content that helps Claude execute tasks.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is very verbose at ~200+ lines, explaining concepts Claude already knows well (HIG principles like Clarity/Deference/Depth, what SF Symbols are, basic SwiftUI layout concepts). The 'When to Use This Skill' section is unnecessary padding. Much of this is standard SwiftUI documentation that Claude has extensive training on. The 'Core Concepts' section reads like a tutorial rather than novel, actionable guidance. | 1 / 3 |
Actionability | The code examples are fully executable, copy-paste ready SwiftUI code with proper imports and complete view structures. The NavigationStack, TabView, grid layouts, and FeatureCard examples are all concrete and runnable. | 3 / 3 |
Workflow Clarity | For a design/UI skill, there's no clear workflow for how to approach building an iOS interface from scratch. The Best Practices and Common Issues sections are lists without sequencing. There are no validation checkpoints (e.g., 'preview in different Dynamic Type sizes', 'run Accessibility Inspector'). The content is organized by topic but lacks a coherent process flow. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no references to external files. Given the breadth of topics covered (navigation, layout, SF Symbols, accessibility, visual design, common issues), this content would benefit greatly from being split into focused reference files. Everything is inline with no structure for discovery or navigation. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- wshobson/agents
- Commit
112197c
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.