|
| 1 | +--- |
| 2 | +name: composable-mini-apps |
| 3 | +description: >- |
| 4 | + Build many focused workspace apps that compose through agent discovery and |
| 5 | + A2A. Use when designing headless mini-apps or cross-app workflows. |
| 6 | +--- |
| 7 | + |
| 8 | +# Composable Mini-Apps |
| 9 | + |
| 10 | +## Rule |
| 11 | + |
| 12 | +Prefer many one-job apps in a workspace over one oversized app. A headless app |
| 13 | +can own a provider, dataset, workflow, or specialist action surface without a |
| 14 | +full UI; the main agent composes those apps through discovery and A2A. |
| 15 | + |
| 16 | +## Shape |
| 17 | + |
| 18 | +- Give each mini-app one clear job, a concise `package.json` description, and |
| 19 | + action names that describe the job it owns. |
| 20 | +- Keep provider credentials and upstream API details in the app that owns that |
| 21 | + provider or workflow. Other apps should delegate to it instead of copying its |
| 22 | + integration code. |
| 23 | +- Use a tiny status/config screen only when users need to inspect state. A |
| 24 | + pure headless app is fine when its job is invoked by agents, automations, or |
| 25 | + sibling apps. |
| 26 | +- If two workflows only share a helper, put the helper in `packages/shared`; |
| 27 | + keep the workflow actions in separate apps. |
| 28 | + |
| 29 | +## Discovery And Invocation |
| 30 | + |
| 31 | +The main agent should discover available siblings before assuming capability: |
| 32 | + |
| 33 | +- Runtime agents receive an `<available-apps>` block built from |
| 34 | + `discoverAgents()`. Workspace siblings are layered in by |
| 35 | + `discoverWorkspaceAgents()`. |
| 36 | +- UI shells, headless surfaces, and scripts can read the same registry through |
| 37 | + `GET /_agent-native/agents?selfAppId=<app-id>`. |
| 38 | +- Code or CLI callers should use the first-class A2A invocation path |
| 39 | + (`invokeAgent()` / `agent-native invoke`) when they need to call an app by |
| 40 | + id, name, or URL. |
| 41 | +- In the agent loop, use `call-agent` with the sibling app id when another app |
| 42 | + owns the work or data. Never call the current app through `call-agent`; use |
| 43 | + local actions instead. |
| 44 | + |
| 45 | +Send narrow prompts to siblings: name the exact question, relevant ids, date |
| 46 | +ranges, and expected output shape. Preserve returned ids and URLs verbatim. |
| 47 | + |
| 48 | +## Provider APIs |
| 49 | + |
| 50 | +Provider-specific actions are shortcuts, not limits. When the upstream API can |
| 51 | +answer the question better than a first-class shortcut, call |
| 52 | +`provider-api-catalog` and `provider-api-docs` as needed, then |
| 53 | +`provider-api-request` against the real provider endpoint. For broad joins, |
| 54 | +searches, or absence claims, stage the bounded corpus with `stageAs` and reduce |
| 55 | +it with `query-staged-dataset` or code. |
| 56 | + |
| 57 | +When composing apps, make the provider-owning mini-app do those |
| 58 | +`provider-api-request` calls. The orchestrator should delegate a bounded job; |
| 59 | +it should not reimplement every provider endpoint locally. |
| 60 | + |
| 61 | +## Example |
| 62 | + |
| 63 | +For a sales-intelligence workspace, split the job into small apps: |
| 64 | + |
| 65 | +| App | Owns | Calls | |
| 66 | +| --- | --- | --- | |
| 67 | +| `hubspot-pipeline` | CRM deals, contacts, companies, associations | `provider-api-request` with provider `hubspot` | |
| 68 | +| `gong-evidence` | Calls, transcripts, snippets, speaker evidence | `provider-api-request` with provider `gong` | |
| 69 | +| `knowledge-base` | Internal docs, pricing rules, playbooks | local search/read actions | |
| 70 | +| `deal-brief` | Orchestration and final brief | `invokeAgent()` or `call-agent` to the three apps | |
| 71 | + |
| 72 | +Flow: `deal-brief` asks `hubspot-pipeline` for the target account and open |
| 73 | +deals, asks `gong-evidence` for recent transcript evidence about those deals, |
| 74 | +asks `knowledge-base` for relevant playbook guidance, then synthesizes the |
| 75 | +answer. That is a HubSpot→Gong→knowledge-base chain made of focused apps, |
| 76 | +not a single app that clones every provider integration. |
| 77 | + |
| 78 | +## Don't |
| 79 | + |
| 80 | +- Do not clone Mail, Calendar, Analytics, Brain, Assets, or another first-party |
| 81 | + app just to reuse its data. Delegate or link to the existing app. |
| 82 | +- Do not hide a multi-provider workflow inside a giant "misc tools" app. |
| 83 | +- Do not add one-off provider endpoints when `provider-api-request` can express |
| 84 | + the upstream API safely. |
| 85 | +- Do not create wrapper routes that only re-export another app's action or A2A |
| 86 | + result. |
| 87 | + |
| 88 | +## Related Skills |
| 89 | + |
| 90 | +- **a2a-protocol** - How apps expose and call A2A endpoints. |
| 91 | +- **actions** - How each mini-app exposes its own operation surface. |
| 92 | +- **external-agents** - How external MCP hosts route through workspace apps. |
| 93 | +- **storing-data** - How app-owned data stays SQL-backed and portable. |
0 commit comments