@ngxtm/devkit 3.15.0 → 3.16.0

package/skills/hig-components-layout/references/tab-views.md

@@ -0,0 +1,68 @@
+---
+title: "Tab views | Apple Developer Documentation"
+source: https://developer.apple.com/design/human-interface-guidelines/tab-views
+
+# Tab views
+
+A tab view presents multiple mutually exclusive panes of content in the same area, which people can switch between using a tabbed control.
+
+![A stylized representation of a view with two labeled tabs, the first of which is selected. The image is tinted red to subtly reflect the red in the original six-color Apple logo.](https://docs-assets.developer.apple.com/published/4b2dbd07b3c6fe1d349d6db6aad5890b/components-tab-view-intro%402x.png)
+
+## [Best practices](https://developer.apple.com/design/human-interface-guidelines/tab-views#Best-practices)
+
+**Use a tab view to present closely related areas of content.** The appearance of a tab view provides a strong visual indication of enclosure. People expect each tab to display content that is in some way similar or related to the content in the other tabs.
+
+**Make sure the controls within a pane affect content only in the same pane.** Panes are mutually exclusive, so ensure they’re fully self-contained.
+
+**Provide a label for each tab that describes the contents of its pane.** A good label helps people predict the contents of a pane before clicking or tapping its tab. In general, use nouns or short noun phrases for tab labels. A verb or short verb phrase may make sense in some contexts. Use title-style capitalization for tab labels.
+
+**Avoid using a pop-up button to switch between tabs.** A tabbed control is efficient because it requires a single click or tap to make a selection, whereas a pop-up button requires two. A tabbed control also presents all choices onscreen at the same time, whereas people must click a pop-up button to see its choices. Note that a pop-up button can be a reasonable alternative in cases where there are too many panes of content to reasonably display with tabs.
+
+**Avoid providing more than six tabs in a tab view.** Having more than six tabs can be overwhelming and create layout issues. If you need to present six or more tabs, consider another way to implement the interface. For example, you could instead present each tab as a view option in a pop-up button menu.
+
+For developer guidance, see [`NSTabView`](https://developer.apple.com/documentation/AppKit/NSTabView).
+
+## [Anatomy](https://developer.apple.com/design/human-interface-guidelines/tab-views#Anatomy)
+
+The tabbed control appears on the top edge of the content area. You can choose to hide the control, which is appropriate for an app that switches between panes programmatically.
+
+![An illustration of a window in which a three-tab tabbed control is centered on the top edge of the content view.](https://docs-assets.developer.apple.com/published/05bb7fbc6365c3bab10db218644756c3/tab-views-top%402x.png)
+
+When you hide the tabbed control, the content area can be borderless, bezeled, or bordered with a line. A borderless view can be solid or transparent.
+
+**In general, inset a tab view by leaving a margin of window-body area on all sides of a tab view.** This layout looks clean and leaves room for additional controls that aren’t directly related to the contents of the tab view. You can extend a tab view to meet the window edges, but this layout is unusual.
+
+## [Platform considerations](https://developer.apple.com/design/human-interface-guidelines/tab-views#Platform-considerations)
+
+ _Not supported in iOS, iPadOS, tvOS, or visionOS._
+
+### [iOS, iPadOS](https://developer.apple.com/design/human-interface-guidelines/tab-views#iOS-iPadOS)
+
+For similar functionality, consider using a [segmented control](https://developer.apple.com/design/human-interface-guidelines/segmented-controls) instead.
+
+### [watchOS](https://developer.apple.com/design/human-interface-guidelines/tab-views#watchOS)
+
+watchOS displays tab views using [page controls](https://developer.apple.com/design/human-interface-guidelines/components/presentation/page-controls). For developer guidance, see [`TabView`](https://developer.apple.com/documentation/SwiftUI/TabView) and [`verticalPage`](https://developer.apple.com/documentation/SwiftUI/TabViewStyle/verticalPage).
+
+![An illustration showing the page control next to the Digital Crown on Apple Watch. The current dot is enlarged, indicating that people can scroll through the current content, as well as scroll between pages.](https://docs-assets.developer.apple.com/published/10938a94cb663210f148e0fbce431e70/tab-view-watch-vertical%402x.png)
+
+## [Resources](https://developer.apple.com/design/human-interface-guidelines/tab-views#Resources)
+
+#### [Related](https://developer.apple.com/design/human-interface-guidelines/tab-views#Related)
+
+[Tab bars](https://developer.apple.com/design/human-interface-guidelines/tab-bars)
+
+[Segmented controls](https://developer.apple.com/design/human-interface-guidelines/segmented-controls)
+
+#### [Developer documentation](https://developer.apple.com/design/human-interface-guidelines/tab-views#Developer-documentation)
+
+[`TabView`](https://developer.apple.com/documentation/SwiftUI/TabView) — SwiftUI
+
+[`NSTabView`](https://developer.apple.com/documentation/AppKit/NSTabView) — AppKit
+
+## [Change log](https://developer.apple.com/design/human-interface-guidelines/tab-views#Change-log)
+
+Date| Changes  
+---|---  
+June 5, 2023| Added guidance for using tab views in watchOS.  
+  

package/skills/hig-components-layout/references/windows.md

@@ -0,0 +1,188 @@
+---
+title: "Windows | Apple Developer Documentation"
+source: https://developer.apple.com/design/human-interface-guidelines/windows
+
+# Windows
+
+A window presents UI views and components in your app or game.
+
+![A stylized representation of a window with close, minimize, and full-screen buttons. The image is tinted red to subtly reflect the red in the original six-color Apple logo.](https://docs-assets.developer.apple.com/published/3c5ea22db1d7d414c160c95ed7f62ec9/components-window-intro%402x.png)
+
+In iPadOS, macOS, and visionOS, windows help define the visual boundaries of app content and separate it from other areas of the system, and enable multitasking workflows both within and between apps. Windows include system-provided interface elements such as frames and window controls that let people open, close, resize, and relocate them.
+
+Conceptually, apps use two types of windows to display content:
+
+  * A _primary_ window presents the main navigation and content of an app, and actions associated with them.
+
+  * An _auxiliary_ window presents a specific task or area in an app. Dedicated to one experience, an auxiliary window doesn’t allow navigation to other app areas, and it typically includes a button people use to close it after completing the task.
+
+
+
+
+For guidance laying out content within a window on any platform, see [Layout](https://developer.apple.com/design/human-interface-guidelines/layout); for guidance laying out content in Apple Vision Pro space, see [Spatial layout](https://developer.apple.com/design/human-interface-guidelines/spatial-layout). For developer guidance, see [Windows](https://developer.apple.com/documentation/SwiftUI/Windows).
+
+## [Best practices](https://developer.apple.com/design/human-interface-guidelines/windows#Best-practices)
+
+**Make sure that your windows adapt fluidly to different sizes to support multitasking and multiwindow workflows.** For guidance, see [Layout](https://developer.apple.com/design/human-interface-guidelines/layout) and [Multitasking](https://developer.apple.com/design/human-interface-guidelines/multitasking).
+
+**Choose the right moment to open a new window.** Opening content in a separate window is great for helping people multitask or preserve context. For example, Mail opens a new window whenever someone selects the Compose action, so both the new message and the existing email are visible at the same time. However, opening new windows excessively creates clutter and can make navigating your app more confusing. Avoid opening new windows as default behavior unless it makes sense for your app.
+
+**Consider providing the option to view content in a new window.** While it’s best to avoid opening new windows as default behavior unless it benefits your user experience, it’s also great to give people the flexibility of viewing content in multiple ways. Consider letting people view content in a new window using a command in a [context menu](https://developer.apple.com/design/human-interface-guidelines/context-menus) or in the [File menu](https://developer.apple.com/design/human-interface-guidelines/the-menu-bar#File-menu). For developer guidance, see [`OpenWindowAction`](https://developer.apple.com/documentation/SwiftUI/OpenWindowAction).
+
+**Avoid creating custom window UI.** System-provided windows look and behave in a way that people understand and recognize. Avoid making custom window frames or controls, and don’t try to replicate the system-provided appearance. Doing so without perfectly matching the system’s look and behavior can make your app feel broken.
+
+**Use the term _window_ in user-facing content.** The system refers to app windows as _windows_ regardless of type. Using different terms — including _scene_ , which refers to window implementation — is likely to confuse people.
+
+## [Platform considerations](https://developer.apple.com/design/human-interface-guidelines/windows#Platform-considerations)
+
+ _Not supported in iOS, tvOS, or watchOS._
+
+### [iPadOS](https://developer.apple.com/design/human-interface-guidelines/windows#iPadOS)
+
+Windows present in one of two ways depending on a person’s choice in Multitasking & Gestures settings.
+
+  * **Full screen.** App windows fill the entire screen, and people switch between them — or between multiple windows of the same app — using the app switcher.
+
+  * **Windowed.** People can freely resize app windows. Multiple windows can be onscreen at once, and people can reposition them and bring them to the front. The system remembers window size and placement even when an app is closed.
+
+
+
+
+  * Full screen 
+  * Windowed 
+
+
+
+![A screenshot of the Notes app in full screen on iPad, with an open document titled Nature Walks. The app interface fills the entire screen, with no visible border to the window.](https://docs-assets.developer.apple.com/published/5daa697ab73d7e08de1e4fa78a56bfcb/windows-ipad-notes-fullscreen%402x.png)
+
+![A screenshot of the Notes app  in a window on iPad, with an open document titled Nature Walks. The document window occupies the center of the screen, with the Home Screen background filling the rest of the screen behind it, and the Dock at the bottom.](https://docs-assets.developer.apple.com/published/0d1eca9806c6d60816eb9b6f436c28d3/windows-ipad-notes-windowed%402x.png)
+
+**Make sure window controls don’t overlap toolbar items.** When windowed, app windows include window controls at the leading edge of the toolbar. If your app has toolbar buttons at the leading edge, they might be hidden by window controls when they appear. To prevent this, instead of placing buttons directly on the leading edge, move them inward when the window controls appear.
+
+**Consider letting people use a gesture to open content in a new window.** For example, people can use the pinch gesture to expand a Notes item into a new window. For developer guidance, see [`collectionView(_:sceneActivationConfigurationForItemAt:point:)`](https://developer.apple.com/documentation/UIKit/UICollectionViewDelegate/collectionView\(_:sceneActivationConfigurationForItemAt:point:\)) (to transition from a collection view item), or [`UIWindowScene.ActivationInteraction`](https://developer.apple.com/documentation/UIKit/UIWindowScene/ActivationInteraction) (to transition from an item in any other view).
+
+Tip
+
+If you only need to let people view one file, you can present it without creating your own window, but you must support multiple windows in your app. For developer guidance, see [`QLPreviewSceneActivationConfiguration`](https://developer.apple.com/documentation/QuickLook/QLPreviewSceneActivationConfiguration).
+
+### [macOS](https://developer.apple.com/design/human-interface-guidelines/windows#macOS)
+
+In macOS, people typically run several apps at the same time, often viewing windows from multiple apps on one desktop and switching frequently between different windows — moving, resizing, minimizing, and revealing the windows to suit their work style.
+
+To learn about setting up a window to display your game in macOS, see [Managing your game window for Metal in macOS](https://developer.apple.com/documentation/Metal/managing-your-game-window-for-metal-in-macos).
+
+#### [macOS window anatomy](https://developer.apple.com/design/human-interface-guidelines/windows#macOS-window-anatomy)
+
+A macOS window consists of a frame and a body area. People can move a window by dragging the frame and can often resize the window by dragging its edges.
+
+The _frame_ of a window appears above the body area and can include window controls and a [toolbar](https://developer.apple.com/design/human-interface-guidelines/toolbars). In rare cases, a window can also display a bottom bar, which is a part of the frame that appears below body content.
+
+#### [macOS window states](https://developer.apple.com/design/human-interface-guidelines/windows#macOS-window-states)
+
+A macOS window can have one of three states:
+
+  * **Main.** The frontmost window that people view is an app’s main window. There can be only one main window per app.
+
+  * **Key.** Also called the _active window_ , the key window accepts people’s input. There can be only one key window onscreen at a time. Although the front app’s main window is usually the key window, another window — such as a panel floating above the main window — might be key instead. People typically click a window to make it key; when people click an app’s Dock icon to bring all of that app’s windows forward, only the most recently accessed window becomes key.
+
+  * **Inactive.** A window that’s not in the foreground is an inactive window.
+
+
+
+
+The system gives main, key, and inactive windows different appearances to help people visually identify them. For example, the key window uses color in the title bar options for closing, minimizing, and zooming; inactive windows and main windows that aren’t key use gray in these options. Also, inactive windows don’t use [vibrancy](https://developer.apple.com/design/human-interface-guidelines/materials) (an effect that can pull color into a window from the content underneath it), which makes them appear subdued and seem visually farther away than the main and key windows.
+
+![An illustration of a stack of three windows, as follows: An inactive window in the background, an app’s main window in the middle, and a key window appearing above the other two windows.](https://docs-assets.developer.apple.com/published/7ecd910726f347fb452d9ecd2b492d22/window-states%402x.png)
+
+Note
+
+Some windows — typically, panels like Colors or Fonts — become the key window only when people click the window’s title bar or a component that requires keyboard input, such as a text field.
+
+**Make sure custom windows use the system-defined appearances.** People rely on the visual differences between windows to help them identify the foreground window and know which window will accept their input. When you use system-provided components, a window’s background and button appearances update automatically when the window changes state; if you use custom implementations, you need to do this work yourself.
+
+**Avoid putting critical information or actions in a bottom bar, because people often relocate a window in a way that hides its bottom edge.** If you must include one, use it only to display a small amount of information directly related to a window’s contents or to a selected item within it. For example, Finder uses a bottom bar (called the status bar) to display the total number of items in a window, the number of selected items, and how much space is available on the disk. A bottom bar is small, so if you have more information to display, consider using an inspector, which typically presents information on the trailing side of a split view.
+
+### [visionOS](https://developer.apple.com/design/human-interface-guidelines/windows#visionOS)
+
+visionOS defines two main window styles: default and volumetric. Both a default window (called a _window_) and a volumetric window (called a _volume_) can display 2D and 3D content, and people can view multiple windows and volumes at the same time in both the Shared Space and a Full Space.
+
+![An illustration representing a window in visionOS. The illustration consists of two parallel rounded rectangles, slightly separated and displayed on an angle, positioned above a window bar.](https://docs-assets.developer.apple.com/published/e8dc51484c2e5f3289a5f6a878f4c47d/visionos-window-style-2d-window%402x.png)A window
+
+![An illustration representing a volume in visionOS. The illustration consists of a translucent cube. The base of the cube is darker than the other sides. The front of the cube is positioned above a window bar.](https://docs-assets.developer.apple.com/published/92d953d099f72f9909c47bad408f4c9b/visionos-window-style-3d-volume%402x.png)A volume
+
+Note
+
+visionOS also defines the _plain_ window style, which is similar to the default style, except that the upright plane doesn’t use the glass background. For developer guidance, see [`PlainWindowStyle`](https://developer.apple.com/documentation/SwiftUI/PlainWindowStyle).
+
+The system defines the initial position of the first window or volume people open in your app or game. In both the Shared Space and a Full Space, people can move windows and volumes to new locations.
+
+#### [visionOS windows](https://developer.apple.com/design/human-interface-guidelines/windows#visionOS-windows)
+
+The default window style consists of an upright plane that uses an unmodifiable background [material](https://developer.apple.com/design/human-interface-guidelines/materials) called _glass_ and includes a close button, window bar, and resize controls that let people close, move, and resize the window. A window can also include a Share button, [tab bar](https://developer.apple.com/design/human-interface-guidelines/tab-bars), [toolbar](https://developer.apple.com/design/human-interface-guidelines/toolbars), and one or more [ornaments](https://developer.apple.com/design/human-interface-guidelines/ornaments). By default, visionOS uses dynamic [scale](https://developer.apple.com/design/human-interface-guidelines/spatial-layout#Scale) to help a window’s size appear to remain consistent regardless of its proximity to the viewer. For developer guidance, see [`DefaultWindowStyle`](https://developer.apple.com/documentation/SwiftUI/DefaultWindowStyle).
+
+![A screenshot of a window for an app named 'Hello World' in visionOS. The window includes text and buttons for entering different experiences.](https://docs-assets.developer.apple.com/published/95650cb19e1930e6b08ca5aa3b5b06a0/visionos-window-2d%402x.png)A window
+
+**Prefer using a window to present a familiar interface and to support familiar tasks.** Help people feel at home in your app by displaying an interface they’re already comfortable with, reserving more [immersive experiences](https://developer.apple.com/design/human-interface-guidelines/immersive-experiences) for the meaningful content and activities you offer. If you want to showcase bounded 3D content like a game board, consider using a [volume](https://developer.apple.com/design/human-interface-guidelines/windows#visionOS-volumes).
+
+**Retain the window’s glass background.** The default glass background helps your content feel like part of people’s surroundings while adapting dynamically to lighting and using specular reflections and shadows to communicate the window’s scale and position. Removing the glass material tends to cause UI elements and text to become less legible and to no longer appear related to each other; using an opaque background obscures people’s surroundings and can make a window feel constricting and heavy.
+
+**Choose an initial window size that minimizes empty areas within it.** By default, a window measures 1280x720 pt. When a window first opens, the system places it about two meters in front of the wearer, giving it an apparent width of about three meters. Too much empty space inside a window can make it look unnecessarily large while also obscuring other content in people’s space.
+
+**Aim for an initial shape that suits a window’s content.** For example, a default Keynote window is wide because slides are wide, whereas a default Safari window is tall because most webpages are much longer than they are wide. For games, a tower-building game is likely to open in a taller window than a driving game.
+
+**Choose a minimum and maximum size for each window to help keep your content looking great.** People appreciate being able to resize windows as they customize their space, but you need to make sure your layout adjusts well across all sizes. If you don’t set a minimum and maximum size for a window, people could make it so small that UI elements overlap or so large that your app or game becomes unusable. For developer guidance, see [Positioning and sizing windows](https://developer.apple.com/documentation/visionOS/positioning-and-sizing-windows).
+
+![A screenshot of a window for an app in visionOS. The window includes text that discusses objects in orbit, and it includes buttons for viewing a satellite, the moon, and a telescope. The satellite button is selected and a 3D satellite is displayed.](https://docs-assets.developer.apple.com/published/db1e41fe4000281898003f792ff037c8/visionos-window-2d-with-volume%402x.png)A window containing 3D content
+
+**Minimize the depth of 3D content you display in a window.** The system adds highlights and shadows to the views and controls within a window, giving them the appearance of [depth](https://developer.apple.com/design/human-interface-guidelines/spatial-layout#Depth) and helping them feel more substantial, especially when people view the window from an angle. Although you can display 3D content in a window, the system clips it if the content extends too far from the window’s surface. To display 3D content that has greater depth, use a volume.
+
+#### [visionOS volumes](https://developer.apple.com/design/human-interface-guidelines/windows#visionOS-volumes)
+
+You can use a volume to display 2D or 3D content that people can view from any angle. A volume includes window-management controls just like a window, but unlike in a window, a volume’s close button and window bar shift position to face the viewer as they move around the volume. For developer guidance, see [`VolumetricWindowStyle`](https://developer.apple.com/documentation/SwiftUI/VolumetricWindowStyle).
+
+![A screenshot of a volume containing a 3D globe in visionOS, beside a window.](https://docs-assets.developer.apple.com/published/99098a290c36254e48329511216e1d5a/visionos-window-3d%402x.png)A volume
+
+**Prefer using a volume to display rich, 3D content.** In contrast, if you want to present a familiar, UI-centric interface, it generally works best to use a [window](https://developer.apple.com/design/human-interface-guidelines/windows#visionOS-windows).
+
+**Place 2D content so it looks good from multiple angles.** Because a person’s perspective changes as they move around a volume, the location of 2D content within it might appear to change in ways that don’t make sense. To pin 2D content to specific areas of 3D content inside a volume, you can use an attachment.
+
+**In general, use dynamic scaling.** Dynamic scaling helps a volume’s content remain comfortably legible and easy to interact with, even when it’s far away from the viewer. On the other hand, if you want a volume’s content to represent a real-world object, like a product in a retail app, you can use fixed scaling (this is the default).
+
+**Take advantage of the default baseplate appearance to help people discern the edges of a volume.** In visionOS 2 and later, the system automatically makes a volume’s horizontal “floor,” or _baseplate_ , visible by displaying a gentle glow around its border when people look at it. If your content doesn’t fill the volume, the system-provided glow can help people become aware of the volume’s edges, which can be particularly useful in keeping the resize control easy to find. On the other hand, if your content is full bleed or fills the volume’s bounds — or if you display a custom baseplate appearance — you may not want the default glow.
+
+**Consider offering high-value content in an ornament.** In visionOS 2 and later, a volume can include an ornament in addition to a toolbar and tab bar. You can use an ornament to reduce clutter in a volume and elevate important views or controls. When you use an attachment anchor to specify the ornament’s location, such as `topBack` or `bottomFront`, the ornament remains in the same position, relative to the viewer’s perspective, as they move around the volume. Be sure to avoid placing an ornament on the same edge as a toolbar or tab bar, and prefer creating only one additional ornament to avoid overshadowing the important content in your volume. For developer guidance, see [`ornament(visibility:attachmentAnchor:contentAlignment:ornament:)`](https://developer.apple.com/documentation/SwiftUI/View/ornament\(visibility:attachmentAnchor:contentAlignment:ornament:\)).
+
+**Choose an alignment that supports the way people interact with your volume.** As people move a volume, the baseplate can remain parallel to the floor of a person’s surroundings, or it can tilt to match the angle at which a person is looking. In general, a volume that remains parallel to the floor works well for content that people don’t interact with much, whereas a volume that tilts to match where a person is looking can keep content comfortably usable, even when the viewer is reclining.
+
+## [Resources](https://developer.apple.com/design/human-interface-guidelines/windows#Resources)
+
+#### [Related](https://developer.apple.com/design/human-interface-guidelines/windows#Related)
+
+[Layout](https://developer.apple.com/design/human-interface-guidelines/layout)
+
+[Split views](https://developer.apple.com/design/human-interface-guidelines/split-views)
+
+[Multitasking](https://developer.apple.com/design/human-interface-guidelines/multitasking)
+
+#### [Developer documentation](https://developer.apple.com/design/human-interface-guidelines/windows#Developer-documentation)
+
+[Windows](https://developer.apple.com/documentation/SwiftUI/Windows) — SwiftUI
+
+[`WindowGroup`](https://developer.apple.com/documentation/SwiftUI/WindowGroup) — SwiftUI
+
+[`UIWindow`](https://developer.apple.com/documentation/UIKit/UIWindow) — UIKit
+
+[`NSWindow`](https://developer.apple.com/documentation/AppKit/NSWindow) — AppKit
+
+#### [Videos](https://developer.apple.com/design/human-interface-guidelines/windows#Videos)
+
+[![](https://devimages-cdn.apple.com/wwdc-services/images/3055294D-836B-4513-B7B0-0BC5666246B0/873F40BE-101A-4C0D-99F0-F5C7CE7B47A3/10046_wide_250x141_1x.jpg) Elevate the design of your iPad app ](https://developer.apple.com/videos/play/wwdc2025/208)
+
+## [Change log](https://developer.apple.com/design/human-interface-guidelines/windows#Change-log)
+
+Date| Changes  
+---|---  
+June 9, 2025| Added best practices, and updated with guidance for resizable windows in iPadOS.  
+June 10, 2024| Updated to include guidance for using volumes in visionOS 2 and added game-specific examples.  
+June 21, 2023| Updated to include guidance for visionOS.  
+  

package/skills/hig-components-menus/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: hig-components-menus
+version: 1.0.0
+description: ">-"
+  Apple HIG guidance for menu and button components including menus, context menus,
+  dock menus, edit menus, the menu bar, toolbars, action buttons, pop-up buttons,
+  pull-down buttons, disclosure controls, and standard buttons. Use this skill
+  when the user says "how should my buttons look," "what goes in the menu bar,"
+  "should I use a context menu or action sheet," "how do I design a toolbar," or
+  asks about button design, menu design, context menu, toolbar, menu bar, action
+  button, pop-up button, pull-down button, disclosure control, dock menu, edit
+  menu, or any menu/button component layout and behavior. Cross-references:
+  hig-components-search, hig-components-controls, hig-components-dialogs.
+risk: unknown
+source: community
+---
+
+# Apple HIG: Menus and Buttons
+
+Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.
+
+## Key Principles
+
+1. **Menus should be contextual and predictable.** Standard items in standard locations. Follow platform conventions for ordering and grouping.
+
+2. **Use standard button styles.** System-defined styles communicate affordance and maintain visual consistency. Prefer them over custom designs.
+
+3. **Toolbars for frequent actions.** Most commonly used commands in the toolbar. Rarely used actions belong in menus.
+
+4. **Menu bar is the primary command interface on macOS.** Every command reachable from the menu bar. Toolbars and context menus supplement, not replace.
+
+5. **Context menus for secondary actions.** Right-click or long-press, relevant to the item under the pointer. Never put a command only in a context menu.
+
+6. **Pop-up buttons for mutually exclusive choices.** Select exactly one option from a set.
+
+7. **Pull-down buttons for action lists.** No current selection; they offer a set of commands.
+
+8. **Action buttons consolidate related actions** behind a single icon in toolbars or title bars.
+
+9. **Disclosure controls for progressive disclosure.** Show or hide additional content.
+
+10. **Dock menus: short and focused** on the most useful actions when the app is running.
+
+## Reference Index
+
+| Reference | Topic | Key content |
+|---|---|---|
+| [menus.md](references/menus.md) | General menu design | Item ordering, grouping, shortcuts |
+| [context-menus.md](references/context-menus.md) | Context menus | Right-click, long press, secondary actions |
+| [dock-menus.md](references/dock-menus.md) | Dock menus | macOS app-level actions, running state |
+| [edit-menus.md](references/edit-menus.md) | Edit menus | Undo, copy, paste, standard items |
+| [the-menu-bar.md](references/the-menu-bar.md) | Menu bar | macOS primary command interface, structure |
+| [toolbars.md](references/toolbars.md) | Toolbars | Frequent actions, customization, placement |
+| [buttons.md](references/buttons.md) | Buttons | System styles, sizing, affordance |
+| [action-button.md](references/action-button.md) | Action button | Grouped secondary actions, toolbar use |
+| [pop-up-buttons.md](references/pop-up-buttons.md) | Pop-up buttons | Mutually exclusive choice selection |
+| [pull-down-buttons.md](references/pull-down-buttons.md) | Pull-down buttons | Action lists, no current selection |
+| [disclosure-controls.md](references/disclosure-controls.md) | Disclosure controls | Progressive disclosure, show/hide |
+
+## Output Format
+
+1. **Component recommendation** -- which menu or button type and why.
+2. **Visual hierarchy** -- placement, sizing, grouping within the interface.
+3. **Platform-specific behavior** across iOS, iPadOS, macOS, visionOS.
+4. **Keyboard shortcuts** (macOS) -- standard and custom shortcuts for menu items and toolbar actions.
+
+## Questions to Ask
+
+1. Which platforms?
+2. Primary or secondary action?
+3. How many actions need to be available?
+4. macOS menu bar app?
+
+## Related Skills
+
+- **hig-components-search** -- Search fields, page controls alongside toolbars and menus
+- **hig-components-controls** -- Toggles, pickers, segmented controls complementing buttons
+- **hig-components-dialogs** -- Alerts, sheets, popovers triggered by menu items or buttons
+- **hig-inputs** -- Keyboard shortcuts and pointer interactions with menus and toolbars
+
+---
+
+*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/skills/hig-components-menus/references/action-button.md

@@ -0,0 +1,61 @@
+---
+title: "Action button | Apple Developer Documentation"
+source: https://developer.apple.com/design/human-interface-guidelines/action-button
+
+# Action button
+
+The Action button gives people quick access to their favorite features on supported iPhone and Apple Watch models.
+
+![A sketch of an arrow pointing toward the Action button on Apple Watch, suggesting initiating an action. The image is overlaid with rectangular and circular grid lines and is tinted purple to subtly reflect the purple in the original six-color Apple logo.](https://docs-assets.developer.apple.com/published/e9f0fbe50cec4b4b3ac0ef5daa14e321/inputs-action-button-intro%402x.png)
+
+On a supported device, people can use the Action button to run [App Shortcuts](https://developer.apple.com/design/human-interface-guidelines/app-shortcuts) or access system-provided functionality, like turning the flashlight on or off. On Apple Watch Ultra, the Action button supports activity-related actions, including workouts and dives.
+
+A person chooses a function for the Action button when they set up their device; later, they can adjust this choice in Settings. When someone associates an App Shortcut with the Action button, pressing the button runs the App Shortcut similarly to using their voice with Siri or tapping it in Spotlight.
+
+When designing your app or game, think of the Action button as another way for someone to quickly access a function that they use on a regular basis.
+
+## [Best practices](https://developer.apple.com/design/human-interface-guidelines/action-button#Best-practices)
+
+**Support the Action button with a set of your app’s essential functions.** For example, if your cooking app includes an egg timer, a “Start Egg Timer” action might be one that people want to initiate when they press the Action button. You don’t need to offer an App Shortcut that opens your app, because the system provides this function already. Your app icon, widgets, and Apple Watch complications give people other quick ways to open your app. For additional guidance, see [App Shortcuts](https://developer.apple.com/design/human-interface-guidelines/app-shortcuts).
+
+**For each action you support, write a short label that succinctly describes it.** People see your labels when they visit Settings to configure the Action button’s behavior. Create labels that use [title-style capitalization](https://support.apple.com/guide/applestyleguide/c-apsgb744e4a3/web#apdca93e113f1d64), begin with a verb, use present tense, and exclude articles and prepositions. Keep labels as short as possible, with a maximum of three words. For example, use “Start Race” instead of “Started Race” or “Start the Race.”
+
+**Prefer letting the system show people how to use the Action button with your app.** When you support the Action button, the system automatically helps people configure it to initiate one of your app’s functions. Avoid creating content that repeats the guidance offered in Settings for the Action button, or other usage tips the system provides.
+
+## [Platform considerations](https://developer.apple.com/design/human-interface-guidelines/action-button#Platform-considerations)
+
+ _Not supported in iPadOS, macOS, tvOS, or visionOS._
+
+### [iOS](https://developer.apple.com/design/human-interface-guidelines/action-button#iOS)
+
+**Let people use your actions without leaving their current context.** When possible, make use of lightweight multitasking capabilities like [Live Activities](https://developer.apple.com/design/human-interface-guidelines/live-activities) and custom snippets to provide functionality without opening your app. For example, the “Set Timer” action doesn’t launch the Clock app; it prompts people to set a duration for the timer, and then launches a Live Activity with the countdown.
+
+### [watchOS](https://developer.apple.com/design/human-interface-guidelines/action-button#watchOS)
+
+In watchOS, a person can assign the Action button’s first press to drop a waypoint, start a dive, or begin a specific workout. Beyond a single button press, the Action button also supports secondary actions like marking a segment or transitioning to the next modality during a multi-part workout.
+
+**Consider offering a secondary function that supports or advances the primary action people choose.** People often use the Action button without looking at the screen, so a subsequent button press needs to flow logically from the first press, while also making sense in the current context. If your app supports workout or dive actions, consider designing a simple, intuitive secondary function that people can easily learn and remember. Consider carefully before you offer more than one secondary function, because doing so can increase people’s cognitive load and make your app seem harder to use.
+
+**Prefer using subsequent button presses to support additional functionality rather than to stop or conclude a function.** If you need to let people stop their main task — as opposed to pausing the current function — offer this option within your interface instead.
+
+**Pause the current function when people press the Action button and side button together.** The exception is in a diving app where pausing a dive may be dangerous to the diver, causing them to lose track of their depth or not understand how long they’ve been underwater. Unless pausing the current function results in a negative experience, be sure to meet people’s expectations by letting them pause their current activity when they press both buttons at the same time.
+
+## [Resources](https://developer.apple.com/design/human-interface-guidelines/action-button#Resources)
+
+#### [Related](https://developer.apple.com/design/human-interface-guidelines/action-button#Related)
+
+[Workouts](https://developer.apple.com/design/human-interface-guidelines/workouts)
+
+[Digital Crown](https://developer.apple.com/design/human-interface-guidelines/digital-crown)
+
+[App Shortcuts](https://developer.apple.com/design/human-interface-guidelines/app-shortcuts)
+
+[Live Activities](https://developer.apple.com/design/human-interface-guidelines/live-activities)
+
+## [Change log](https://developer.apple.com/design/human-interface-guidelines/action-button#Change-log)
+
+Date| Changes  
+---|---  
+September 12, 2023| Updated to include guidance for iOS.  
+September 14, 2022| New page.  
+