agentleFS
spokvulcanspokvulcan/claude-code-build-ios-apps/skills/ios-app-intents/SKILL.md

ios-app-intents

Skill2 starsChanged 6 months agoMITView on GitHub

Design and implement App Intents, app entities, and App Shortcuts for iOS apps so useful actions and content are available to Shortcuts, Siri, Spotlight, widgets, controls, and other intent-driven system surfaces. Use when exposing app actions outside the UI, adding `AppEntity` and `EntityQuery` types, shaping shortcut phrases and display representations, or routing intent execution back into the main app.

6 other projects use a version of this, 4 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 14 are common, 0 are distinctive, and 5 are very specific to this project.

  • 14

    Common

    Most of the 5 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Read these references as needed:

    line 11
  2. Common:

    Prefer verbs like compose, open, find, filter, continue, inspect, or start.

    line 22
  3. Common:

    Do not mirror the entire app navigation tree as intents.

    line 23
  4. Very specific:

    Add AppEntity types only for the objects the system needs to understand or route.

    line 26
  5. Common:

    Keep the entity shape narrower than the app's persistence model.

    line 27
  6. Very specific:

    Add EntityQuery or other query types only where disambiguation or suggestions are genuinely useful.

    line 28
  7. Common:

    Use non-opening intents for actions that can complete directly from the system surface.

    line 31
  8. Very specific:

    Use openAppWhenRun or open-style intents when the user should land in a specific in-app workflow.

    line 32
  9. Common:

    When the app must react inside the main scene, add one clear runtime handoff path instead of scattering ad hoc routing logic.

    line 33
  10. Common:

    If the action can work in both modes, consider shipping both an inline version and an open-app version rather than forcing one compromise.

    line 34
  11. Very specific:

    Add AppShortcutsProvider entries for the first set of high-value intents.

    line 37
  12. Common:

    Keep shortcut phrases direct and task-oriented.

    line 39
  13. Common:

    Verify the app opens or routes to the expected place when an intent runs.

    line 44
  14. Common:

    Prefer a dedicated intents target or module for the system-facing layer.

    line 49
  15. Common:

    Keep intent types thin; business logic should stay in app services or domain models.

    line 50
  16. Common:

    Keep app entities small and display-friendly.

    line 51
  17. Very specific:

    Use AppEnum for fixed app choices such as tabs, modes, or visibility levels before reaching for a full entity type.

    line 52
  18. Common:

    Prefer one predictable app-intent routing surface in the main app scene or root router.

    line 53
  19. Common:

    Treat App Intents as system integration infrastructure, not only as a Shortcuts feature.

    line 54

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

iOS App Intents

Overview

Expose the smallest useful action and entity surface to the system. Start with the verbs and objects people would actually want outside the app, then implement a narrow App Intents layer that can deep-link or hand off cleanly into the main app when needed.

Read these references as needed:

  • references/first-pass-checklist.md for choosing the first intent and entity surface
  • references/example-patterns.md for concrete example shapes to copy and adapt
  • references/code-templates.md for generalized App Intents code templates
  • references/system-surfaces.md for how to think about Shortcuts, Siri, Spotlight, widgets, and other system entry points

Core workflow

1) Start with actions, not screens

  • Identify the 1-3 highest-value actions that should work outside the app UI.
  • Prefer verbs like compose, open, find, filter, continue, inspect, or start.
  • Do not mirror the entire app navigation tree as intents.

2) Define a small entity surface

  • Add AppEntity types only for the objects the system needs to understand or route.
  • Keep the entity shape narrower than the app's persistence model.
  • Add EntityQuery or other query types only where disambiguation or suggestions are genuinely useful.

3) Decide whether the action completes in place or opens the app

  • Use non-opening intents for actions that can complete directly from the system surface.
  • Use openAppWhenRun or open-style intents when the user should land in a specific in-app workflow.
  • When the app must react inside the main scene, add one clear runtime handoff path instead of scattering ad hoc routing logic.
  • If the action can work in both modes, consider shipping both an inline version and an open-app version rather than forcing one compromise.

4) Make the actions discoverable

  • Add AppShortcutsProvider entries for the first set of high-value intents.
  • Choose titles, phrases, and symbols that make sense in Shortcuts, Siri, and Spotlight.
  • Keep shortcut phrases direct and task-oriented.
  • Reuse the same action model for widgets and controls when a widget configuration or intent-driven control already needs the same parameters.

5) Validate the runtime handoff

  • Build the app and confirm the intents target compiles cleanly.
  • Verify the app opens or routes to the expected place when an intent runs.
  • Summarize which actions are now exposed, which entities back them, and how the app handles invocation.

Strong defaults

  • Prefer a dedicated intents target or module for the system-facing layer.
  • Keep intent types thin; business logic should stay in app services or domain models.
  • Keep app entities small and display-friendly.
  • Use AppEnum for fixed app choices such as tabs, modes, or visibility levels before reaching for a full entity type.
  • Prefer one predictable app-intent routing surface in the main app scene or root router.
  • Treat App Intents as system integration infrastructure, not only as a Shortcuts feature.

Anti-patterns

  • Exposing every screen or tab as its own intent without a real user value.
  • Mirroring the entire model graph as AppEntity types.
  • Hiding runtime handoff in global side effects with no clear app entry path.
  • Adding App Shortcuts with vague phrases or generic titles.
  • Treating the first App Intents pass as a broad taxonomy project instead of a small useful release.

Notes

  • Apple documentation to use as primary references:
    • https://developer.apple.com/documentation/appintents/making-actions-and-content-discoverable-and-widely-available
    • https://developer.apple.com/documentation/appintents/creating-your-first-app-intent
    • https://developer.apple.com/documentation/appintents/adopting-app-intents-to-support-system-experiences
  • In addition to the links above, use web search to consult current Apple Developer documentation when App Intents APIs or platform behavior may have changed.
  • A good first pass often includes one open-app intent, one action intent, one or two entity types, and a small AppShortcutsProvider.
  • Good example families to cover are:
    • open a destination or editor in the app
    • perform a lightweight action inline without opening the app
    • choose from a fixed enum such as a tab or mode
    • resolve one or more entities through EntityQuery
    • power widget configuration or controls from the same entity surface

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.