ToranaYour workflow hack could help someone else.
A small plugin that solves one annoying problem is a good place to start. Try moving a harness-specific tool or policy into Torana so you can reuse it across compatible setups. It does not need to cover everyone’s workflow.
Build it where you like.
Start with the Go and Rust plugin-authoring guide to scaffold, build, and test your plugin. The SDK repository has helpers and further examples. Your source can stay in your own repository. People can install it from source without a central publishing step or a catalogue listing.
Plugins work with a shared request format, but compatibility still depends on the fields and capabilities they use. Document the harnesses, endpoints, and versions you have actually tried.
Request a place in the catalogue.
Open a listing request in the website repository. Include:
- The problem it solves and a small example of it working.
- A public source link, license, and the tag or commit to review.
- Build and installation instructions, plus any configuration it needs.
- Requested permissions and resources, including where data goes if it uses network access.
- The Torana and SDK versions, harnesses, and provider endpoints you tested.
Maintainers review requests before adding a listing and may ask for changes or more information. Keep credentials, private prompts, and customer data out of the issue and examples.
A listing helps people find it.
It is not a security certification or automatic approval. A listing only helps people find the source; they still choose it explicitly, build it locally, and approve the permissions of the exact bundle they run.
Community listings identify the reviewed revision, not future branch updates. Maintainers may remove listings if source disappears, maintenance or compatibility lapses, licensing changes, or security concerns emerge.
Not looking for a listing? Share your repository directly. The install path works the same way.