Run any Skill in Manus with one click

review-ios-ui-apple-hig

Stars4

Forks0

UpdatedJune 25, 2026 at 16:17

Review iOS app UI against Apple Human Interface Guidelines and iOS platform conventions. Use when asked for an Apple HIG-based iOS UI, UX, SwiftUI, UIKit, screenshot, simulator, accessibility, Dynamic Type, navigation, layout, controls, color, typography, or platform-conventions review, especially when the user wants critique or prioritized findings grounded in Apple's interface guidance instead of project-specific design docs.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

bastos

bastos/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Web and Digital Interface DesignersComputer and Mathematical Occupations·SOC 15-1255

File Explorer

9 files

SKILL.md

readonly

name

review-ios-ui-apple-hig

description

Review iOS UI Against Apple HIG

Purpose

Use this skill to review an iOS interface against Apple Human Interface Guidelines, iOS conventions, and observable product behavior.

Default to review-only. Do not edit files unless the user explicitly asks for fixes.

Workflow

Define the review surface: identify the app screens, screenshots, SwiftUI/UIKit files, simulator state, and target devices or size classes involved.
Gather evidence from the actual artifact. Prefer screenshots, simulator runs, UI previews, or concrete SwiftUI/UIKit code over generic assumptions.
Read references/apple-hig-review.md before making guideline claims, then read the page-specific reference files it routes to. If the user asks for the current or exact Apple rule, verify the linked Apple page live.
Review by category: platform fit, layout, navigation, controls and input, typography, color and materials, accessibility, feedback states, destructive actions, and iPad/adaptive behavior when relevant.
Rank findings by user impact and confidence. Prioritize issues that affect comprehension, task completion, accessibility, safety, or platform expectation.
Report findings with evidence and a concrete recommendation. Avoid broad redesign advice unless it follows directly from an observed issue.

Evidence Rules

Do not rely on project-specific design documents unless the user explicitly asks for that comparison.
When reviewing code, cite file paths and line numbers for the UI surface that creates the issue.
When reviewing screenshots or simulator output, describe the visible region precisely enough that the user can locate it.
When behavior depends on runtime state, Dynamic Type, appearance mode, localization, or device size, say whether it was verified.
Use the Browser plugin or another rendered browser only when Apple HIG imagery/examples or web-rendered reference pages need visual inspection.

Output Shape

Start with findings, ordered by severity:

High: <issue title>
Evidence: <file:line, screenshot area, or runtime observation>
Apple guideline basis: <short paraphrase plus HIG page name/link when useful>
Recommendation: <specific UI change or validation step>

Then include:

Open questions only when missing context changes the recommendation.
Verification gaps when the review did not include device, simulator, Dynamic Type, dark mode, VoiceOver, or localization checks that matter.
No guideline-level issues found when the inspected surface appears aligned and only subjective style preferences remain.

Keep the response concise. Do not include a generic HIG checklist in the final answer unless the user asks for one.

More from this repository

same repository

ios-design-review

bastos/skills

Review iOS app UI/UX design quality using Apple's design principles and the Liquid Glass-era design language from WWDC25/26. Use when asked for a design review, UX critique, visual design assessment, or evaluation of an app's interface quality, design intent, alignment with the new Apple design system, or usability. Triggers: "design review", "UX review", "visual design critique", "review the UI", "does this design work", "evaluate this interface", "design feedback", "Liquid Glass review".

2026-07-144

write-a-prompt

bastos/skills

Creates a copy-ready prompt from a rough request, notes, source material, or the current conversation using OpenAI's prompting guidance. Use when the user invokes $write-a-prompt or /write-a-prompt, types a common misspelling such as /write-a-promopt or /wite-a-prompt, asks to "write a prompt for me," asks to turn the conversation into a prompt, or wants a prompt tailored for Chat, ChatGPT Work, or Codex. It writes the prompt without performing the underlying task.

2026-07-134

send-to-minion

bastos/skills

Use this skill only when the user explicitly invokes $send-to-minion, /send-to-minion, or explicitly asks to delegate a prompt to one minion, helper, worker, child agent, spawned agent, subagent, Claude Code agent, or other single delegated agent. It sends the user's prompt to exactly one subagent using the current runtime's delegation tools, coordinates follow-up with the runtime's messaging/resume tools, verifies the result, and returns the parent agent's final answer.

2026-07-074

topydo

bastos/skills

Manages todo.txt tasks using topydo CLI. Adds, lists, completes, prioritizes, tags, and organizes tasks with dependencies, due dates, recurrence, and projects. Use for any task management, todo lists, or when the user mentions tasks, todos, or todo.txt. Requires Python 3 and pip. Works on macOS, Linux, and Windows.

2026-06-304

orbstack-cli

bastos/skills

Command reference and recipes for driving OrbStack from the terminal on macOS: the orb/orbctl CLI for Linux VMs (create, start/stop, exec, file transfer, clone, export/import, per-VM CPU/memory limits), Docker under OrbStack (contexts, platform/Rosetta, volume extension commands, migrate from Docker Desktop, debug shell), container domains (.orb.local) and networking (port-forwarding, host.docker.internal, proxies, IP ranges), SSH access, Kubernetes, every config key, and headless/CI automation. Use whenever the user runs or asks about an `orb`, `orbctl`, or OrbStack-flavored `docker` command, manages OrbStack Linux machines, runs containers locally on a Mac, sets up .orb.local domains or port-forwarding, scripts OrbStack in CI, or hits an OrbStack networking/daemon problem - even phrased loosely as "spin up an ubuntu VM", "my container isn't reachable on localhost", "use Docker on my Mac", or "OrbStack keeps resetting the connection".

2026-06-184

mikrotik-routeros

bastos/skills

Configures and automates MikroTik RouterOS routers through the terminal, command line interface, .rsc imports, /system script repository, Scheduler, Netwatch, firewall, NAT, DHCP, DNS, bridge, VLAN, routing, VPN, device-mode, backup/export, and RouterOS scripting. Use this skill whenever the user mentions MikroTik, Mikrotik, RouterOS, WinBox terminal, router CLI, router scripts, .rsc files, or configuring MikroTik services from the command line.

2026-04-244

name

review-ios-ui-apple-hig

description

Review iOS UI Against Apple HIG

Purpose

Use this skill to review an iOS interface against Apple Human Interface Guidelines, iOS conventions, and observable product behavior.

Default to review-only. Do not edit files unless the user explicitly asks for fixes.

Workflow

Define the review surface: identify the app screens, screenshots, SwiftUI/UIKit files, simulator state, and target devices or size classes involved.
Gather evidence from the actual artifact. Prefer screenshots, simulator runs, UI previews, or concrete SwiftUI/UIKit code over generic assumptions.
Read references/apple-hig-review.md before making guideline claims, then read the page-specific reference files it routes to. If the user asks for the current or exact Apple rule, verify the linked Apple page live.
Review by category: platform fit, layout, navigation, controls and input, typography, color and materials, accessibility, feedback states, destructive actions, and iPad/adaptive behavior when relevant.
Rank findings by user impact and confidence. Prioritize issues that affect comprehension, task completion, accessibility, safety, or platform expectation.
Report findings with evidence and a concrete recommendation. Avoid broad redesign advice unless it follows directly from an observed issue.

Evidence Rules

Do not rely on project-specific design documents unless the user explicitly asks for that comparison.
When reviewing code, cite file paths and line numbers for the UI surface that creates the issue.
When reviewing screenshots or simulator output, describe the visible region precisely enough that the user can locate it.
When behavior depends on runtime state, Dynamic Type, appearance mode, localization, or device size, say whether it was verified.
Use the Browser plugin or another rendered browser only when Apple HIG imagery/examples or web-rendered reference pages need visual inspection.

Output Shape

Start with findings, ordered by severity:

High: <issue title>
Evidence: <file:line, screenshot area, or runtime observation>
Apple guideline basis: <short paraphrase plus HIG page name/link when useful>
Recommendation: <specific UI change or validation step>

Then include:

Open questions only when missing context changes the recommendation.
Verification gaps when the review did not include device, simulator, Dynamic Type, dark mode, VoiceOver, or localization checks that matter.
No guideline-level issues found when the inspected surface appears aligned and only subjective style preferences remain.

Keep the response concise. Do not include a generic HIG checklist in the final answer unless the user asks for one.