Support extracting publishable plugins from project-local plugins

[JustAGhosT]

Context

While building a project-local Claude plugin for mystira-workspace, we found that retort's plugin scaffolding produces project-specific plugins that work great locally but aren't publishable to the Claude marketplace because:

1. Skills reference project-specific paths, agent names, and domain rules
2. Hooks contain hardcoded namespace patterns (e.g., Mystira.App.Api)
3. Subagent dispatch skills depend on agent definitions that live outside the plugin

Feature Request

Retort should support a plugin extraction workflow that takes a project-local plugin and produces a generic, configurable, publishable plugin. Specifically:

1. Templatize project-specific values

Skills currently hardcode paths like apps/app/src/Mystira.App.Api/. The sync engine should support a plugin-vars.yaml (or extend project.yaml) that parameterizes these:

pluginVars:
  rootNamespace: Mystira.App
  apiLayer: apps/app/src/Mystira.App.Api
  domainLayer: apps/app/src/Mystira.App.Domain
  applicationLayer: apps/app/src/Mystira.App.Application
  coppaEnabled: true
  coppaCoverageThreshold: 80

2. Generic plugin templates

Retort should ship reusable plugin templates that any .NET hexagonal project could adopt:

• hexagonal-enforcer — validates layer boundaries (configurable namespace patterns)
• coppa-guardian — COPPA compliance for any children's platform (configurable paths/thresholds)
• dotnet-security-hooks — PII-in-logs + sync-over-async + secrets detection

3. Plugin extraction command

pnpm ak:extract-plugin --template hexagonal-enforcer --output ./dist/plugins/

This would read the project's project.yaml, apply the template, and produce a standalone plugin directory with all project-specific values replaced by configuration.

4. Marketplace readiness checklist

Add a /plugin-preflight skill that checks whether a plugin meets marketplace requirements:

• No hardcoded project paths
• All skills are self-contained (no external agent dependencies)
• plugin.json and marketplace.json are valid
• Hook scripts are portable (no absolute paths)
• README/description is generic enough for discoverability

Motivation

The current flow is: retort scaffolds project configs → project builds local plugin → plugin is useful but not distributable. The missing piece is: local plugin → extracted generic plugin → publishable.

This would let the retort ecosystem produce a library of reusable Claude plugins from real-world usage, rather than designing them in the abstract.

Example: What mystira built locally

.claude-plugin/
├── plugin.json
├── marketplace.json
├── hooks/
│   ├── hooks.json
│   └── scripts/
│       ├── check-pii-in-logs.sh        # COPPA: PII in log statements
│       └── check-layer-violation.sh     # Hexagonal layer enforcement
└── skills/
    ├── agent-dispatch/SKILL.md          # 26-agent router
    ├── coppa-check/SKILL.md             # COPPA compliance audit
    ├── architecture-check/SKILL.md      # Hexagonal validation
    ├── security-audit/SKILL.md          # 3-domain security sweep
    ├── coverage-check/SKILL.md          # Test coverage + COPPA 80% gate
    └── health-sweep/SKILL.md            # Project health gates

All of these encode patterns that could be generic — but currently aren't because retort doesn't have a path from "project plugin" to "published plugin".

---

🤖 Generated with Claude Code

[blocksorg]

Mention Blocks like a regular teammate with your question or request:

@blocks can you add technical details to this issue?
@blocks make the following changes ...
@blocks create an issue from what was mentioned in the following comment ...
@blocks explain the following code ...
@blocks are there any security or performance concerns?

Run @blocks /help for more information.

Workspace settings | Disable this message