Stallion

What it does

Stallion is not a plugin you connect Claude to a service with. It is a developer toolkit for building other Speedwave plugins. It scaffolds a new plugin from a template, bumps its version, writes its changelog, and supplies the shared CI pipeline that every plugin uses to build, sign, and publish. If you write plugins for Speedwave, Stallion does the repetitive parts of that job. Like every Speedwave plugin, Stallion itself is written, developed, and shipped exclusively by Speednet.

What it consists of

Stallion has two faces. As an installed plugin, it adds shared instructions for Claude (claude-resources/CLAUDE.md), mounted read-only and imported by every generated plugin, plus three slash commands and one hook. As a repository, it provides the shared GitLab CI template (.build-plugin.yml) that every plugin includes to build, sign, and publish itself, plus a local build script for testing.

Note

Stallion’s manifest declares only ["skills", "commands", "hooks"]. There is no service_id, no port, no Containerfile, and no worker. It runs nothing in a container; it only adds resources Claude uses while you build a plugin. See using plugins for how installed plugins add commands, skills, and hooks in general.

Skills and commands

Name	What it does
create-plugin skill	Walks you through starting a new plugin from plain language: slug, worker or resource-only, scaffold, manifest.
add-oauth skill	Wires up token-based sign-in for an MCP plugin, keeping the actual credentials out of the worker’s reach.
/stallion:new-plugin command	Lays down a fresh plugin directory from the shared template.
/stallion:bump command	Keeps the version number in sync between the manifest, package.json, and the lockfiles.
/stallion:changelog command	Drafts the changelog for whatever version is currently set.

Tools

Stallion ships no MCP worker and no tools, only the skills, commands, and hooks listed above.

How it works

Ask Claude to scaffold a plugin, for example with /stallion:new-plugin jira "Jira Integration", and Claude copies a template tree into a new plugin directory and renames the placeholders: the slug, the display name, a default port of 4010, a default memory limit of 256 MiB, and the Stallion version that generated it. The scaffold validates the slug against ^[a-z][a-z0-9-]{0,63}$ and rejects the 13 reserved built-in service ids: slack, sharepoint, redmine, gitlab, github, atlassian, office, playwright, context7, os, oauth, ide, and host_exec. Or describe the plugin in plain language and let create-plugin gather the slug, ask whether it is an MCP worker or resource-only, and walk you through the manifest and tools.

Releasing a version follows bump, then changelog, then commit: bump raises the version across the manifest, package.json, and the lockfiles together, and changelog reads that version and proposes bullets split into user-facing and developer-only entries. CI publishes the new version on merge and refuses to republish a version that already exists.

The build pipeline itself runs three stages on the main branch. Build compiles the plugin. Sign reproduces Speedwave’s plugin-digest algorithm (a SHA-256 over the files sorted by path, with length framing, signed with Ed25519, aborting on any symlink) using the Speednet signing private key as a protected CI variable. Publish uploads the signed ZIP to the GitLab package registry.

Set it up

Plugins depend on @speedwave/* packages from the private GitLab npm registry, so there is one machine-level step before anything else: create a GitLab deploy token scoped to reading the package registry and export it as NPM_TOKEN. The Stallion repository README has the exact one-time steps. After that, install Stallion into your plugin-development project and scaffold your first plugin with /stallion:new-plugin or by describing the plugin to Claude.

When a plugin needs OAuth2 rather than a static token, ask Claude to add it: add-oauth walks through the manifest’s oauth block, the runtime mounts, and refresh-on-401 wiring, with the GLPI plugin as the reference implementation.

Installed plugins $ install plugin my my-project

plugintypesignedon

figmamcp✓ ed25519

glpimcp✓ ed25519

Security boundaries

Stallion’s commands and scripts run in place from the installed plugin; there is no separate install step or per-repo copy. The signing key that proves a plugin’s authenticity is a protected CI variable, never something a plugin author holds directly, and a local unsigned build only installs if you set the SPEEDWAVE_ALLOW_UNSIGNED=1 escape hatch, because Speedwave installs only signed plugins by default. When a scaffolded plugin adds OAuth2, the worker only ever sees a short-lived access token; the client secret and refresh token stay host-side. See how credentials are handled for that model in full. Stallion’s own hook, repos-shortcuts.mjs, is implemented but marked “not working yet” for an installed plugin, so it is not active.