Minion docs

Packages

Package manifest

Every field of a package's package.json: name, exports and the minion block (description, tags, dependencies, jobs, subscriptions, emits, webhooks, app), with the rules each save is checked against.

Editing package source

Open a repo session on a saved package, edit files one at a time or with a patch, run the publish checks, then publish a new version.

Package apps

Serve a Hono app from a package at https://<org>.runminion.run/<package>/: the minion.app block, members or public access, how members sign in, limits and the security model.

Package authoring

START HERE when creating or materially changing a Minion package: package shape, required README.md (human) and AGENTS.md (agent), README Intent section, per-export JSDoc (search Purpose), personal-details hygiene before going public, secret-using package approval checklist, and scope-update guidance without adding new primitives.

Package lifecycle: reuse, execute, or create

Choose between invoking existing behavior, temporary execute exploration, deferred workflows, and creating a durable saved package; test package-owned job wrappers safely.

Package storage and SQL

Saved packages keep durable state with packageStorage() (JSON key/value per package) and sql() (a SQLite database per package). Limits, isolation, moving from Postgres, and how storage counts against your plan.

Package subscriptions and events

Run a package export when a platform topic fires (failed runs, jobs, OAuth, webhooks, inbox mail) or another package emits one. Test and inspect deliveries.

Plain repos

Minion has no plain repos or git remotes. Package source lives in saved versions: edit it with repo sessions or packages.save.

Sharing packages

Minion has no public package catalog yet. How to reuse packages inside your organization, and what to do when you need one somewhere else.