plugin-lab

Align an existing plugin to the canonical lab/plugin spec

Target path relative to plugin root: `commands/my-plugin/inspect.md`

Scaffold a new lab plugin with a spec-conforming plan

Create or update Docker container config for a lab plugin

Implement or update the full CI/CD pipeline for a lab plugin

CLAUDE.md

Read the relevant agent docs before creating or editing agents here.

CLAUDE.md

Use this agent when the user wants an existing MCP plugin updated to match the homelab canonical plugin spec, wants a review report turned into implementation work, or wants stale scaffolding replaced with the `plugin-templates` repo and canonical patterns. <example> Context: User wants a plugin brought up to current standard. user: "Align this plugin to the current homelab spec." assistant: "I'll use ally-the-aligner to plan and implement the alignment." <commentary> This agent turns review findings into concrete changes while preserving justified deviations. </commentary> </example> <example> Context: User invokes the align command. user: "/align-lab-plugin" assistant: "Spawning ally-the-aligner to update the plugin to spec." <commentary> The command routes to this agent so alignment work uses the same methodology every time. </commentary> </example> <example> Context: User has a review report and wants the fixes implemented. user: "Roddy produced a review report yesterday. Now implement all the fixes." assistant: "I'll have ally-the-aligner read the review report and implement each finding as a targeted change." <commentary> Ally consumes review artifacts as its primary input — it can work from an existing report without re-auditing if the report is recent. </commentary> </example>

Use this agent when the user wants to containerize a lab plugin, create or update a Dockerfile, docker-compose.yaml, or entrypoint.sh, audit existing container config for drift, or plan a deploy strategy for a plugin. <example> Context: User wants Docker config created for a new plugin. user: "Containerize the Gotify plugin and set up Compose." assistant: "I'll launch dex-the-deployer to produce the Dockerfile, entrypoint, and Compose config." <commentary> This is the dedicated containerization agent. It reads the deploy-lab-plugin skill, gathers port and env var inputs, and produces a canonical multi-stage container config. </commentary> </example> <example> Context: User invokes the deploy command. user: "/deploy-lab-plugin" assistant: "Spawning dex-the-deployer to handle the container and deploy work." <commentary> The command routes here so all containerization and deploy work uses the same methodology. </commentary> </example> <example> Context: User needs to roll back a deployed plugin to a prior version. user: "The 1.3.0 release broke something — roll back the Overseerr plugin to 1.2.3." assistant: "I'll use dex-the-deployer to pin the prior image tag in docker-compose.yaml and produce the rollback commands." <commentary> Dex handles rollback via image tag pinning, not scale-to-zero. It's the right agent for any Compose-level deploy operation. </commentary> </example>

Bring an existing MCP plugin into full alignment with the homelab canonical plugin spec. Use when the user wants to update a plugin to current standards, replace stale scaffolding with the `plugin-templates` repo, reconcile manifest drift, standardize Docker and CI files, or turn a review report into a concrete alignment plan and implementation.

Containerize and deploy a lab plugin using Docker and Docker Compose. Use when the user wants to create or update a Dockerfile, docker-compose.yaml, entrypoint.sh, or health endpoint; audit an existing container config for drift; or plan a deploy strategy for a plugin. Trigger phrases include "Dockerize my Rust plugin", "containerize my Python MCP server", "set up Compose for my TypeScript plugin".

Research current primary-source guidance for MCP, Claude Code plugins, Codex plugins, and the language/runtime stack used by homelab plugins. Use when the user asks "what changed in the MCP SDK", "is this transport pattern still current", "find the latest docs for X", "before I scaffold this plugin I need to know...", or any time up-to-date information about MCP protocol changes, plugin manifests, SDK versions, transport patterns, package choices, Docker guidance, or the latest official docs is needed to scaffold, review, or align a plugin.

Implement or update the full CI/CD pipeline for a lab plugin. Use when the user wants to add or update GitHub Actions workflows (ci.yaml, publish-image.yaml, release-on-main.yaml), configure pre-commit or lefthook, set up automated releases, audit an existing pipeline for drift, or sync Justfile targets with CI steps.

Review an MCP plugin against the homelab canonical plugin spec and identify any and all misalignments. Use when the user wants a plugin audited for spec drift, wants to compare a plugin to canonical manifests and runtime patterns, wants to know whether deviations are documented and justified, or wants a detailed plugin review report.