# 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](/docs/plugins/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](/docs/plugins/catalog/glpi/).

<DesktopFrame screen="plugins" />

## 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](/docs/security/credentials/) 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.