DocumentationExtend the framework
Choose an extension point
Add the smallest capability that solves the problem, at the layer that owns it.
On this page
Match the change to its ownerPrompt, tool, trigger and skillKeep the application contract stableA useful development loopImpo is a source framework. Most extensions are code changes in a fork, composed into the API, worker or clients. There is no general installable Impo plugin marketplace or automatic skill loader implied by these guides.
Match the change to its owner#
| You want to… | Start with… | Guide |
|---|---|---|
| Change how the personal agent responds | English prompt modules and their version in server/src/prompts/. | Tools and instructions |
| Let it perform a new operation | A validated tool definition and server adapter. | Tools and instructions |
| Run work at a particular time | Existing scheduled Tasks, or a versioned background step for a platform feature. | Background work |
| Add a phone capability or UI surface | A shared contract, platform adapters and client state. | Clients and generated UI |
| Run your own backend | Service configuration, ownership and deployment checks. | Deployment and services |
| Support a physical device | A board adapter or Linux command in the separate Gadget SDK. | Extend Gadgets |
Prompt, tool, trigger and skill#
A prompt describes behavior: when to use an operation, what context matters and how to report its result. It does not execute a side effect or create a recurring schedule by itself.
A tool exposes an operation with a schema, validation, execution code and a result. The current execution context decides which tools the model can see.
A trigger admits work: a user's command, a Temporal schedule or a supported event path. It starts a run that can use prompts and tools.
A skill is guidance for using capabilities. The Gadget SDK has product-specific guides. A guide still needs working tools, transport and permissions; installing text alone does not implement them.
For example, generated UI uses authoring instructions plus the impo_publish_ui tool. A normal user message starts the run. The model calls the tool when an interface helps, and the worker validates the document. There is no separate hidden UI-trigger service.
Keep the application contract stable#
Clients consume Impo's API and stream protocol. Keep provider-specific messages behind the Rebyte adapter. Add versioned fields or capabilities with a fallback for installed clients that do not understand them yet.
API handlers accept durable work and return receipts. Workers run agent sessions. Repositories own queries and transactions. These boundaries make an extension recoverable without duplicating execution in every client.
A useful development loop#
- Write the contract and name the execution context: main Chat, Task, background step, native action or gadget command.
- Implement validation and owned execution before adding model-facing instructions.
- Expose the capability only where it is available. Add the client surface if one is needed.
- Verify success, unavailable state, revocation and uncertain outcomes.
- Update the relevant guide and record completed validation in
WORK_LOG.md.
Start with the local environment and the permission model. A fixture proves protocol behavior; deployed-account and physical-device checks establish different things.