Zyron Mail Triage OpenCode plugin

OpenCode plugin package for the Zyron Mail Triage agent skills and support tool.

The JavaScript plugin entrypoint stays intentionally small: it exports the OpenCode plugin function plus named metadata exports for the bundled skill files. The package is primarily a versioned distribution channel for the same skills that ship with the macOS app release. The plugin's only runtime behavior is a lightweight update-awareness check described below.

Install

npm install @zaradacht/opencode-mail-triage-plugin

The package is published publicly for npm, bunx, and OpenCode consumption.

For a quick package/version check with Bun:

bunx @zaradacht/opencode-mail-triage-plugin

OpenCode skill setup

OpenCode npm plugins cannot inject SKILL.md files into the OpenCode skill registry at runtime. To make the bundled skills available to agents, copy them into the workspace OpenCode skill directory:

bunx @zaradacht/opencode-mail-triage-plugin setup --target .opencode

setup and install are equivalent. The target defaults to .opencode in the current working directory, and the installer writes:

• .opencode/skills/mail-attention-triage/SKILL.md
• .opencode/skills/zyron-mail-triage/SKILL.md

Useful options:

bunx @zaradacht/opencode-mail-triage-plugin setup --target .opencode --dry-run
bunx @zaradacht/opencode-mail-triage-plugin setup --target=/path/to/workspace/.opencode --force

Without --force, setup fails if an existing target skill has different content. Identical existing files are treated as no-op. In a development checkout, run npm run prepare:skills first if opencode-plugin/skills/ is missing.

Bundled skills

npm pack/npm publish runs npm run prepare:skills, which copies these files from the repository devkit/ directory into this package's skills/ directory:

• mail-attention-triage-SKILL.md
• zyron-mail-triage-SKILL.md
• mail-dump

mail-dump is bundled as a host-side support script under package skills/mail-dump; the setup command does not install it into .opencode/skills. Devkit/workspace tooling can choose where to install support scripts later.

Update awareness

When OpenCode opens and the plugin is registered in the OpenCode config, the plugin checks once per OpenCode process whether a newer package version exists, and shows a small info toast if so. Modeled on OMO-Slim's update awareness.

• Trigger: the first top-level session.created event; child sessions are ignored, the check runs in the background and never blocks startup.
• Source of truth: the npm registry latest dist-tag for this package. npm is the install channel (bunx/npm), it is public, and it needs no GitHub authentication, so it is the authoritative version signal. GitHub Releases carry the same version through the shared release pipeline.
• Throttling: successful lookups are cached for 6 hours in $XDG_CACHE_HOME/opencode-mail-triage-plugin/update-check.json (default ~/.cache/...), so frequent OpenCode restarts do not hammer the registry.
• Failures: offline, registry, or timeout errors keep the check silent. Set OPENCODE_MAIL_TRIAGE_DEBUG=1 to print diagnostics to stderr.
• Nothing is ever installed automatically. The toast only suggests: bunx @zaradacht/opencode-mail-triage-plugin@latest setup --target .opencode --force.

Opt out by setting OPENCODE_MAIL_TRIAGE_UPDATE_CHECK=0 (also accepts false, off, no).

Manual check and simulation paths:

bunx @zaradacht/opencode-mail-triage-plugin update-check
bunx @zaradacht/opencode-mail-triage-plugin update-check --latest 9.9.9
bunx @zaradacht/opencode-mail-triage-plugin update-check --offline

OpenCode module

The package exports an ESM default plugin function and the same function as a named export:

import mailTriagePlugin, { mailTriagePlugin as namedMailTriagePlugin } from "@zaradacht/opencode-mail-triage-plugin";

export default mailTriagePlugin;

The plugin registers a single event hook for the update-awareness check; it registers no tool or file hooks. Agents should load the bundled skill files after the setup copy step according to the workspace's OpenCode skill/plugin conventions. Package metadata is available through the pluginInfo, skillFiles, and packageName named exports, and the update-check helpers (checkForUpdate, compareVersions, formatUpdateMessage) are exported for reuse and testing.