Use when:
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionaxiom-higExecute the skills CLI command in your project's root directory to begin installation:
Fetches axiom-hig from charleswiltgen/axiom and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate axiom-hig. Access via /axiom-hig in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
767
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
767
stars
Use when:
axiom-hig-ref for comprehensive details and code examplesaxiom-liquid-glass for iOS 26 material design implementation and version-conditional design (supporting both pre-Liquid Glass and Liquid Glass in the same app)axiom-liquid-glass-ref for iOS 26 app-wide adoption guide with backward compatibility strategyaxiom-accessibility-diag for accessibility troubleshootingWhen supporting both iOS 25 (pre-Liquid Glass) and iOS 26+, see axiom-liquid-glass for the adoption strategy — it covers when to use #available(iOS 26, *), how to degrade gracefully, and which system components adopt Liquid Glass automatically vs which need explicit opt-in.
Is your app media-focused (photos, videos, music)?
├─ Yes → Consider permanent dark appearance
│ WHY: "Lets UI recede, helps people focus on media" (Apple HIG)
│ EXAMPLES: Apple Music, Photos, Clock apps use dark
│ CODE: .preferredColorScheme(.dark) on root view
│
└─ No → Use system backgrounds (respect user preference)
CODE: systemBackground (adapts to light/dark automatically)
GROUPED: systemGroupedBackground for iOS Settings-style lists
Apple's guidance: "In rare cases, consider using only a dark appearance in the interface. For example, it can make sense for an app that enables immersive media viewing to use a permanently dark appearance."
Do you need a specific color value?
├─ No → Use semantic colors
│ label, secondaryLabel, tertiaryLabel, quaternaryLabel
│ systemBackground, secondarySystemBackground, tertiarySystemBackground
│ WHY: Automatically adapts to light/dark/high contrast
│
└─ Yes → Create Color Set in asset catalog
1. Open Assets.xcassets
2. Add Color Set
3. Configure variants:
├─ Light mode color
├─ Dark mode color
└─ High contrast (optional but recommended)
Key principle: "Use semantic color names like labelColor that automatically adjust to the current interface style."
Which font weight should I use?
├─ ❌ AVOID: Ultralight, Thin, Light
│ WHY: Legibility issues, especially at small sizes
│
├─ ✅ PREFER: Regular, Medium, Semibold, Bold
│ WHY: Maintains legibility across sizes and conditions
│
└─ Headers: Semibold or Bold for hierarchy
Body: Regular or Medium
Apple's guidance: "Avoid light font weights. Prefer Regular, Medium, Semibold, or Bold weights instead of Ultralight, Thin, or Light."
Verify every screen passes these checks:
A: Only for media-focused apps (photos, videos, music) where content should be the hero. Use system backgrounds for everything else.
Apple's own apps:
| App | Background | Reason |
|---|---|---|
| Music | Dark | Album art is focus |
| Photos | Dark | Images are hero |
| Clock | Dark | Nighttime use |
| Notes | System | Document editing |
| Settings | System | Utilitarian |
Code:
// ❌ WRONG - Don't override unless media-focused
.background(Color.black)
// ✅ CORRECT - Let system decide
.background(Color(.systemBackground))
A: Use systemBackground which adapts to light/dark automatically. For grouped content (like iOS Settings), use systemGroupedBackground.
Color hierarchy:
systemBackground - Main backgroundsecondarySystemBackground - Grouping elementstertiarySystemBackground - Grouping within secondary// ✅ Standard list
List { }
.background(Color(.systemBackground))
// ✅ Grouped list (Settings style)
List { }
.listStyle(.grouped)
.background(Color(.systemGroupedBackground))
A: Use semantic label colors, maintain 4.5:1 contrast, avoid light font weights.
Label hierarchy:
// Most prominent
Text("Title").foregroundStyle(.primary)
// Subtitles
Text("Subtitle").foregroundStyle(.secondary)
// Tertiary information
Text("Detail").foregroundStyle(.tertiary)
// Disabled text
Text("Disabled").foregroundStyle(.quaternary)
A: SF Symbols unless you need brand-specific imagery. They scale with Dynamic Type and adapt to appearance automatically.
Benefits of SF Symbols:
When to use custom:
A: Always support both. Never create app-specific appearance settings.
Apple's guidance: "Avoid creating app-specific appearance settings. Users expect apps to honor their systemwide Dark Mode choice. An app-specific appearance mode option creates more work for people because they have to adjust more than one setting to get the appearance they want."
A: 4.5:1 minimum for normal text, 7:1 recommended for small text.
WCAG Contrast Standards:
Testing: Use online contrast calculators or Xcode's Accessibility Inspector.
A: 44x44 points on iOS/iPadOS, with spacing between targets.
Platform-specific:
Use this checklist for design reviews, App Store submissions, or stakeholder presentations:
In design reviews, you'll hear:
These violate HIG. Here's how to push back professionally.
If you hear ANY of these, reference this skill:
"I want to make this change, but let me show you Apple's guidance:
[Show the relevant HIG section from this skill or hig-ref]
Apple explicitly recommends against this because..."
For contrast issues:
For appearance toggles:
"I understand the brand concern. Here are HIG-compliant alternatives:
1. Use your brand color as the app's tint color
2. Feature branding in onboarding (not launch screen)
3. Use your accent color for primary actions
4. Include subtle branding in content, not chrome"
If overruled:
Slack message to PM + designer:
"Design review decided to [violate HIG guidance].
Important risks to monitor:
- App Store rejection (HIG violations)
- Accessibility issues (users with visual impairments)
- User complaints (departure from platform norms)
I'm flagging this proactively. If we see issues after launch,
we'll need an expedited follow-up."
Sometimes designers have valid reasons to override HIG. Accept if:
Every design decision should support these principles:
Definition: Content should be paramount, interface elements should defer to content.
In practice:
Definition: Use standard UI elements and familiar patterns.
In practice:
Definition: UI shouldn't compete with content for attention.
In practice:
From HIG: "Deference makes an app beautiful by ensuring the content stands out while the surrounding visual elements do not compete with it."
Make data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
pproenca/dot-skills
mattpocock/skills
axiom-hig fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
We added axiom-hig from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Solid pick for teams standardizing on skills: axiom-hig is focused, and the summary matches what you get after install.
Useful defaults in axiom-hig — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
axiom-hig is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
We added axiom-hig from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
axiom-hig is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Useful defaults in axiom-hig — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
axiom-hig has been reliable in day-to-day use. Documentation quality is above average for community skills.
axiom-hig has been reliable in day-to-day use. Documentation quality is above average for community skills.
showing 1-10 of 62