Plugin Design Patterns
The main plugin shapes in Downcity and when to choose actions, hooks, lifecycle runtime, system text, or HTTP
Plugin Design Patterns
Not every plugin should look the same.
In current Downcity, a healthy plugin design usually starts by choosing one primary shape.
1. Action-first plugin
Use this shape when the main goal is:
- explicit user-triggered capability
- clear command or API entry points
- bounded one-shot work
Typical examples:
skilltts
2. Hook or resolve plugin
Use this shape when the plugin should participate in an existing runtime chain.
Typical examples:
authasr- role resolver style plugins
3. System-text plugin
Use this shape when the plugin's main job is to add stable runtime guidance.
Typical examples:
skillwebmemory
4. Lifecycle-owned runtime plugin
Use this shape when the plugin must own long-lived runtime state.
Typical examples:
chattaskshell
ActionSchedule is intentionally not modeled as a plugin; it is a shared Agent action module.
This is the right choice when the capability must:
- start
- stop
- recover
- keep in-memory state
- poll or react over time
5. Runtime HTTP plugin
Use this shape when the plugin mainly exposes runtime status or control surfaces through HTTP.
Typical example:
workboard
One practical rule
Do not start from “where can I quickly place this code”.
Start from:
- is this an explicit command
- is this chain participation
- is this stable system guidance
- is this lifecycle-owned runtime state
- is this HTTP exposure