Plugin Ops

"A plugin is born once but maintained forever. Route each movement to the piece that owns it." [INFERENCE]

TL;DR

The lifecycle hub for plugin operations: it maps each movement — ideate → build → validate → audit → document → deploy → maintain → fix — to the toolkit piece that owns it, instead of re-implementing any of them. Learns the 9-movement model from internal-plugin-quality-source; the gate stays the single validator. Use it to know what to run next across a plugin's life. [EXPLICIT]

When to use

• You have (or want) a plugin and ask "what's the next step?" across its lifecycle. [EXPLICIT]
• You need to deploy/publish a plugin and orient the user to install it. [EXPLICIT]
• You need to maintain a plugin (skills/scripts/agents/workflows/assets/routing) over time. [EXPLICIT]
• A real failure or correction happened → capture it and harden the gate (FIX). [EXPLICIT]
• NOT for authoring one component in isolation — that is plugin-builder (BUILD owns it). [INFERENCE]

Lifecycle → toolkit piece (the routing map)

Deep mapping + the 9-movement gates (G1-G4) in references/lifecycle.md. Deploy gotchas in references/deploy-gotchas.md. [DOC]

Procedure

1. Locate the movement the user is in; open the row above and route to that piece. [EXPLICIT]
2. Never skip the gate: every BUILD closes with check.sh + toolkit-hardener before DEPLOY. [EXPLICIT]
3. Deploy by CLI (docs/DEPLOY.md): marketplace add → install → restart → claude plugin list. Before the install, run the inherited loadability gate on the plugin dir: python3 ${CLAUDE_PLUGIN_ROOT}/skills/plugin-reload/scripts/validate_loadable.py <plugin-dir> (manifest parses, frontmatter at byte 0, hooks JSON valid) — the subset of checks whose failure makes Claude Code reject the plugin at load time. [CÓDIGO]
4. Maintain on a cadence: commands/maintain.md; record drift/fixes in LESSONS-LEARNED.md. [EXPLICIT]
5. FIX = harden, not just patch: turn each real failure into a gate/doc that prevents recurrence. [DOC]

Quality Criteria

• Each movement routed to its owning piece (no re-implementation of the gate). [INFERENCE]
• BUILD always closed by check.sh + toolkit-hardener before DEPLOY. [DOC]
• Deploy uses the CLI flow; manifest passes validate_manifest.py (installable). [CÓDIGO]
• Failures captured in LESSONS-LEARNED.md and converted to a gate/doc. [DOC]
• Claims evidence-tagged. [EXPLICIT]

Anti-Patterns

• Re-implementing validation inside this skill instead of routing to check.sh. [INFERENCE]
• Publishing without validate_manifest.py (ships the Invalid input install-breaker). [CÓDIGO]
• "Fixing" a recurring failure by patching once, never hardening the gate. [DOC]

Contract

• Aceptación: movimiento identificado y ruteado a su pieza; gate corrido antes de deploy; deploy por CLI con manifest válido; fallos capturados en LESSONS-LEARNED y convertidos en gate/doc. [EXPLICIT]
• Límites: rutea el ciclo de vida; NO re-implementa el gate (check.sh/toolkit-hardener) ni la autoría de componentes (plugin-builder). [EXPLICIT]
• Casos borde: plugin externo (no del toolkit) → solo aplican Validate/Deploy genéricos + validate_manifest; lo demás es orientación. [INFERENCE]
• Supuestos: las piezas destino (plugin-builder, toolkit-hardener, scripts del gate, DEPLOY.md) están presentes. [SUPUESTO]
• Trade-off: un hub añade indirección a cambio de que nadie se salte un movimiento ni el gate. [EXPLICIT]

Related Skills

• plugin-builder — owns BUILD (scaffold + author components). [EXPLICIT]
• toolkit-hardener — owns AUDIT (excellence gate). [EXPLICIT]
• homolog-plugin-dev — routes to the external plugin-dev plugin under toolkit governance. [EXPLICIT]
• claude-native-inventory — IDEATE: what already exists (don't duplicate). [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · assets/ recursos estáticos.