hig-components-system

Overview of hig-components-system skill

hig-components-system is an Apple HIG-focused skill for designing system experiences that live outside the main app, such as widgets, Live Activities, notifications, complications, Home Screen quick actions, top shelf, watch faces, App Clips, and app shortcuts. It is best for designers, product teams, and AI assistants that need a practical hig-components-system guide for deciding what belongs on each surface and how to keep it glanceable, useful, and platform-appropriate.

What this skill helps you decide

Use the hig-components-system skill when the real task is not “make a UI” but “choose the right system surface and shape the content for it.” It helps you answer questions like whether a feature should be a widget, a Live Activity, or a notification; how much information to expose at a glance; and what the smallest viable presentation should be for each context.

Why it differs from a generic prompt

A generic prompt can produce a pretty mockup, but hig-components-system is aimed at system constraints: limited space, update cadence, surface-specific behavior, and Apple ecosystem expectations. That makes it more useful for UI Design decisions where the risk is overstuffing a surface or choosing the wrong interaction model.

Best fit and misfit cases

This skill fits best when you are designing for Apple surfaces outside the app, or when you need an Apple-aligned critique of a proposed system experience. It is less useful if you only need broad mobile UI advice, a marketing page, or a feature spec unrelated to system surfaces.

How to Use hig-components-system skill

Install and verify the skill

Install hig-components-system with npx skills add raintree-technology/apple-hig-skills --skill hig-components-system, then confirm the skill files are present under skills/hig-components-system. If your environment already has a .claude/apple-design-context.md file, check it first because the skill explicitly tells you to use existing context before asking new questions.

Read the right files first

Start with SKILL.md to understand scope and decision rules, then inspect any linked repository context your workflow depends on, including README.md, AGENTS.md, and metadata.json if available. In this repository, the main signal lives in SKILL.md, so the fastest way to get value is to extract the key principles, reference index, output format, and question prompts rather than treating the repo like a large library.

Give the skill a complete design brief

The hig-components-system usage pattern works best when your prompt names the surface, the user goal, the content available, and the constraints. Strong input looks like: “Design a widget for a grocery app that shows today’s next reminder, supports small and medium sizes, and must avoid dense text.” Weak input like “make a widget better” forces the skill to guess the product, audience, and update model.

Use it as a decision and drafting workflow

A practical hig-components-system workflow is: identify the target surface, ask what the user needs in seconds, trim the content to the most relevant slice, then verify the layout against Apple HIG constraints. If you are exploring multiple surfaces, ask the skill to compare them first instead of jumping directly to visual copy, because the biggest failure mode is choosing the wrong surface and then polishing the wrong answer.

hig-components-system skill FAQ

Is hig-components-system only for widgets?

No. The hig-components-system skill covers a wider set of Apple system experiences, including Live Activities, notifications, complications, App Clips, app shortcuts, Home Screen quick actions, and related surfaces. That breadth makes it useful when you are deciding between system touchpoints, not just styling a single widget.

When should I use hig-components-system for UI Design?

Use it when the design problem depends on Apple’s system presentation rules, especially if the interface must work in a small, glanceable, or context-aware surface. If the work is inside the main app, a general product design prompt is usually enough; if the work appears on the Lock Screen, Home Screen, watch face, or another system surface, hig-components-system is the better fit.

Do I need Apple design experience to use it?

No, but you do need to provide more context than a casual prompt. The skill is beginner-friendly if you can describe the user goal and the surface clearly, but you will get better results if you can state the platform, size, update behavior, and what must be shown immediately.

What is the biggest reason not to use it?

Do not use hig-components-system if you want generic UI inspiration without platform constraints. This skill is strongest when the output must respect Apple ecosystem patterns and when the main question is about fit, hierarchy, and surface selection rather than broad visual exploration.

How to Improve hig-components-system skill

Lead with the surface and the job-to-be-done

The strongest hig-components-system outputs come from prompts that name the exact surface and user job first. For example: “Design a Lock Screen Live Activity for a delivery app that needs to show status, ETA, and one action.” This is better than listing features because it tells the skill what must survive the space limit.

Share only the content that can actually appear

If the surface can show three lines, do not feed it a full product spec and expect a good result. Instead, provide the few fields that matter most, such as state, status, next action, and urgency. The more tightly you define the available content, the easier it is for the skill to produce something that looks like an actual Apple system experience rather than a compressed app screen.

Watch for the common failure modes

The most common failure is overloading the surface with too many labels, actions, or secondary details. Another is treating every widget size as a scaled version of the same layout. Improve the result by asking the skill to separate layouts by size, remove nonessential content, and justify any tap target or interaction it proposes.

Iterate by asking for tradeoff checks

After the first output, ask for a review of clarity, glanceability, and platform fit instead of asking for more decoration. Good follow-ups are: “What should be removed to make this more glanceable?”, “Which system surface is the best fit and why?”, or “Rewrite this for a smaller widget size.” That kind of iteration makes hig-components-system more useful as a design decision aid and a hig-components-system install choice for real workflow use.