Define one app action. Bring it to more places.

Use the same app code in your own interface, App Intents, Siri, Shortcuts, and future AI tools.

FIG 01 · HOW IT WORKS

Keep the real work in your app.

Your app should keep doing the real work. Its own interface, App Intents, and future connections can call the same trusted service instead of creating separate versions of the feature.

Native UIUser interaction

Your appService or store

ConnectionApp Intent or AI tool

FIG 02 · ACTION DETAILS

Give every connection the same basic details.

Supercomputer calls this the Capability Graph: one shared record of the action’s ID, purpose, inputs, result, permissions, version, connections, and test results.

Illustrative example · the public format is still in development.

{
  "id": "auralog.track-migraine",
  "version": "1.0.0",
  "goal": "Track a migraine",
  "inputs": ["startTime", "notes"],
  "effect": "Create a migraine entry",
  "permissions": {
    "authorization": "app-owned"
  },
  "connections": ["app-intent"]
}

FIG 03 · CONNECTIONS

Start with App Intents.

App Intents is the first connection we are building in depth. Start with one reviewed user task, call the same code as the app, add App Shortcuts or app data only when needed, and test the real installed feature separately.

App Intents

In development

Add reviewed app actions, data, results, and App Shortcuts that call your existing app code.

Read the guide

AI tool descriptions

Experimental

Create a portable description of an approved app action. It cannot run until a working connection has been built and tested.

Read the guide

MCP and CLIs

Planned

Add a tested way to run the action, along with sign-in, limits, error handling, and run records.

Read the guide

Tests and proof

In development

Keep code checks, tests, app builds, real feature checks, and live-use records with the exact version they support.

Read the guide

FIG 04 · DEVELOPMENT PRINCIPLES

Build for review, release, and proof.

Start with the user’s task

Describe the useful thing a person wants to do, not a button, Swift type, web address, or phrase they must memorize.

Keep the real work in the app

The app screen and every new connection should call the same trusted service or data store.

Keep the same ID and version

Use one action ID and exact version everywhere so results can be traced back to the right release.

Write down the permissions

State who may run the action, what needs confirmation, and what private data it may use.

Test each place

Finding code, seeing a preview, or passing a build does not prove the action works in Shortcuts, Siri, MCP, or the released app.

Let people approve releases

Someone on the team reviews the proposed changes and test results before a version ships.