Menú
Use when designing or implementing feedback, status, progress, alerts, errors, success states, and live activity indicators in Apple-platform apps — inline status, banners, alerts, notifications, and loading states.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use when shipping a macOS app outside the App Store — Developer ID signing with hardened runtime, notarization with notarytool, stapling, building a clean drag-to-Applications DMG, and verifying the result launches on a stranger's Mac.
Use when reading, writing, or watching the macOS clipboard — NSPasteboard types and multiple representations, the changeCount polling pattern, the transient/concealed pasteboard conventions clipboard tools must respect, and the Sequoia paste-privacy alerts.
Use when adding or reviewing keyboard shortcuts in a macOS app — in-app vs global, RegisterEventHotKey vs the KeyboardShortcuts package vs NSEvent monitors, user-configurable recording, conflict handling, and which defaults won't collide with the system.
Use when adding, reviewing, or debugging Launch at Login in a macOS app — SMAppService registration, the requiresApproval state, a Settings toggle that reflects reality, and migration off deprecated login-item APIs.
Use when adding or reviewing macOS user notifications — UNUserNotificationCenter permission flow, categories and action buttons, click routing through the delegate, foreground presentation, and rules that keep notifications from becoming spam.
Use when a macOS app needs a TCC permission or touches private data — the map of which API, Info.plist key, and entitlement each permission needs, pre-prompt explanation patterns, denied-state recovery with System Settings deep links, and honest privacy copy.
| name | apple-hig-feedback-status |
| description | Use when designing or implementing feedback, status, progress, alerts, errors, success states, and live activity indicators in Apple-platform apps — inline status, banners, alerts, notifications, and loading states. |
Use this skill when designing or implementing feedback, status, progress, alerts, errors, success states, and live activity indicators in Apple-platform apps. It covers running states, task progress, model status, local server status, notifications, toasts, banners, inline errors, loading states, and completion feedback.
Always tell the user what is happening, what changed, and whether they need to act.
Use consistent states:
Idle
Thinking
Running
Waiting
Blocked
Needs Review
Completed
Failed
Offline
Paused
Cancelled
Use for:
Use for local state near content.
Running
Saved
Waiting for model
Use for screen-level issues.
Ollama is offline. Local models are unavailable.
[Retry] [Settings]
Use for destructive actions, permission issues, or blocking errors.
Use when work completes while user is elsewhere.
Use when time or steps matter.
Idle moon No current work
Thinking brain Planning or reasoning
Running bolt.circle Executing a task
Waiting clock Waiting for input/service
Blocked xmark.octagon Cannot continue without action
Needs Review checkmark.seal User should inspect result
Completed checkmark.circle Finished successfully
Failed exclamationmark.triangle Failed with error
Offline wifi.slash Required service unavailable
Paused pause.circle Temporarily stopped
Cancelled xmark.circle Stopped by user
Pair symbols with text. Do not rely on color alone.
Use loading indicators only when something is actually happening.
Good:
Checking Ollama connection…
Generating report…
Indexing project files…
Waiting for agent response…
Bad:
Loading…
Please wait…
Working magic…
Use determinate progress only when you know the total.
ProgressView(value: completed, total: total)
Use indeterminate progress when the duration is unknown.
ProgressView("Generating report…")
Avoid fake percentages.
Do not show 73% if the app does not actually know progress.
For agent work, prefer step labels over fake percent:
Planning task
Editing files
Running checks
Waiting for result
Ready for review
For your app, use a subtle pulse when the agent is active.
Rules:
SwiftUI reduced motion:
@Environment(\.accessibilityReduceMotion) private var reduceMotion
Use short confirmation.
Task created
Report exported
Skill validated
Project opened
Settings saved
Avoid dramatic success messages.
Good error message structure:
What failed
Why it may have failed
What to do next
Example:
Ollama Not Running
The app could not connect to http://127.0.0.1:11434.
Start Ollama, then retry.
[Retry] [Open Settings]
struct StatusChip: View {
let title: String
let symbol: String
var body: some View {
Label(title, systemImage: symbol)
.font(.caption)
.foregroundStyle(.secondary)
.padding(.horizontal, 8)
.padding(.vertical, 4)
.background(.quaternary, in: Capsule())
.accessibilityLabel(title)
}
}
struct StatusBanner: View {
let title: String
let message: String
let symbol: String
let actionTitle: String?
let action: (() -> Void)?
var body: some View {
HStack(alignment: .top, spacing: 12) {
Image(systemName: symbol)
.foregroundStyle(.secondary)
VStack(alignment: .leading, spacing: 4) {
Text(title).font(.headline)
Text(message).font(.callout).foregroundStyle(.secondary)
}
Spacer()
if let actionTitle, let action {
Button(actionTitle, action: action)
}
}
.padding(12)
.background(.regularMaterial, in: RoundedRectangle(cornerRadius: 12))
}
}
Use alerts for blocking or dangerous operations.
.alert("Delete Project?", isPresented: $showDeleteAlert) {
Button("Delete", role: .destructive) {
deleteProject()
}
Button("Cancel", role: .cancel) {}
} message: {
Text("This removes the project from the app. Files on disk will not be deleted.")
}
Use notifications for background completion:
Agent finished the task
Report is ready
Run failed and needs attention
Do not notify for every minor state change.
[ ] Every async operation has visible feedback
[ ] No fake progress percentages
[ ] Agent states use consistent vocabulary
[ ] Running/thinking states are clear
[ ] Success messages are short
[ ] Errors explain recovery
[ ] Destructive actions require confirmation
[ ] Offline/service errors offer retry/settings
[ ] Reduced motion is respected
[ ] Status does not rely on color alone
Fake progress
Blinking aggressive indicators
Silent failure
Vague “Something went wrong”
Success messages that stay forever
Too many notifications
Color-only status
No retry action
Drop this into any coding agent (Claude Code, Codex, Cursor, …) to apply the skill:
Use the apple-hig-feedback-status skill to add clear status and feedback.
Rules:
- Use consistent state vocabulary.
- Show inline status for local state.
- Use banners for screen-level issues.
- Use alerts for destructive/blocking actions.
- Use notifications only for background completion or failure.
- Do not use fake percentages.
- Prefer step labels for agent work.
- Pair symbols with text.
- Respect reduced motion.
- Add retry/settings actions for offline/service errors.
After coding:
1. List statuses added.
2. Explain loading/progress behavior.
3. Explain error recovery.
4. Explain notification behavior.
5. Give manual test steps.