App intents workflow
Skill gaelic-ghost/socket/plugins/apple-dev-skills/skills/app-intents-workflow
The Source for macOS Agent Workflows
npx -y skills add gaelic-ghost/socket --skill app-intents-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Design, implement, validate, and troubleshoot App Intents, App Entities, App Shortcuts, and system-surface integrations. Use when exposing a focused app action or content to Siri, Spotlight, Shortcuts, widgets, controls, Live Activities, or hardware interactions.
SKILL.md
5.5 KB, as published. Nobody here has run it
App Intents Workflow
Purpose
Expose the smallest useful action and content surface outside an app without turning system integration into a second app architecture. Apple documents App Intents as the bridge that makes app actions and data discoverable in system experiences; select real user-recognizable verbs and entities before adding an intent type.
When To Use
- Use for
AppIntent,AppEntity,AppEnum,AppShortcutsProvider, entity queries, result snippets, Spotlight indexing, widgets, controls, Live Activities, Siri, and Action button or Apple Pencil actions. - Use when an app action needs an explicit deep-link or scene-opening handoff after system invocation.
- Hand off Xcode target, extension, build, simulator, and runtime inspection work to
xcode-build-run-workflow; hand test plans and UI automation toxcode-testing-workflow.
Single-Path Workflow
- Apply the Apple docs gate through
explore-apple-swift-docs. Confirm the framework, platform availability, and target system surface before changing code. - Define one user-recognizable verb and the minimum data it needs. Prefer an existing app domain type; do not invent a parallel intent-only repository, store, or DTO layer.
- Classify the surface: direct action, parameterized action, entity lookup, App Shortcut, Spotlight result, widget/control action, Live Activity action, or hardware interaction.
- Read
references/intent-entity-and-shortcut-shapes.mdfor intent, entity, query, shortcut, and result patterns. Readreferences/system-surfaces-and-validation.mdfor indexing, extension boundaries, privacy, and validation. - Implement the narrow intent and make
perform()call the existing domain action or explicit app handoff. Keep parameter confirmation, failures, and result output descriptive and user-facing. - Add
AppEntityonly when people need to select, search, or inspect app-owned content. Give entity display representations stable identifiers and use the appropriate query shape; do not expose private, transient, or unverifiable data. - Add App Shortcuts only for actions people plausibly invoke repeatedly. Use short, natural phrases and real parameter defaults rather than advertising every internal operation.
- For widgets, controls, Live Activities, and Spotlight, validate the owning extension and system-surface contract rather than assuming the main app target alone is enough.
- Validate discovery, parameter resolution, cancellation/failure behavior, app handoff, accessibility, and privacy on the intended platform. Record system-surface limitations separately from app behavior.
Inputs
- app and target shape, deployment target, and intended system surface
- user-recognizable action or content entity
- authentication, confirmation, privacy, and app-handoff requirements
- existing domain operation, content identity, and validation evidence
Outputs
- selected intent/entity/shortcut shape and the documented Apple behavior it relies on
- target or extension requirements and the narrowest app-handoff contract
- privacy and destructive-action boundary
- validation evidence for the actual system surface and any remaining limitation
Guards and Stop Conditions
- Do not expose every app command just because the framework can describe it.
- Do not put network, persistence, or feature business logic into
perform()when an existing domain operation owns it. - Do not claim Siri, Spotlight, widget, control, or hardware availability without checking the current Apple documentation and deployment target.
- Do not use App Intents to bypass app authentication, confirmation, privacy policy, or destructive-action safeguards.
- Stop when the requested surface needs an unsupported entitlement, extension, capability, or system behavior that Apple documentation does not establish.
Fallbacks and Handoffs
- Recommend
swiftui-app-architecture-workflowfor scene and deep-link ownership. - Recommend
apple-ui-accessibility-workflowfor accessible labels, snippets, and alternate interaction verification. - Recommend
xcode-build-run-workflowfor target setup, extensions, build, simulator, logs, and runtime execution. - Recommend
xcode-testing-workflowfor deterministic testing and UI automation. - Recommend
apple-developer-provisioning-workflowonly when documented capability or identifier provisioning becomes the actual blocker.
Customization
Use references/customization-flow.md. The first version exposes no runtime-enforced knobs; it preserves the shared customization contract without allowing a configuration to bypass documentation, privacy, or validation requirements.
References
references/intent-entity-and-shortcut-shapes.mdreferences/system-surfaces-and-validation.mdreferences/customization-flow.md- Recommend
references/snippets/apple-xcode-project-core.mdwhen the app needs reusable Xcode-project policy alongside App Intents integration. - App Intents documents intents, entities, shortcuts, and system-surface integration.
- Adopting App Intents to support system experiences documents discovery across system experiences.