| name | engineer-plugin-marketplace |
| description | Design AI-IDE plugin marketplaces - requirements, host-specific payloads, local dogfood, release sync, and validation. Use when the user wants to create or publish a plugin marketplace. |
Plugin Marketplace Engineer
Use this skill when the user asks to create, assess, or plan a plugin
marketplace for AI IDE plugins. Focus on marketplace-level distribution:
catalog roots, per-host payloads, release sync, install flows, local dogfood,
cache refresh, trust, and validation.
For a single plugin package, prefer engineer-ai-ide-plugin. For one MCP server
or hook adapter, prefer the focused skills listed in
references/related-skills.md.
Evidence First
Before giving implementation details, verify the current official docs for each
target host. Record the consulted links and separate:
- Verified host contract: manifest paths, component fields, marketplace shape,
install commands, trust prompts, and validation commands.
- Local inference: patterns copied from nearby repos such as flowai,
flowai-workflow, or FoxCode.
- Unknowns: host features that must be checked before writing files.
Use these official anchors first:
Workflow
- Classify scope.
- Marketplace design only -> produce requirements and risks; do not create files.
- Marketplace implementation -> design first, then create source, build, validate,
install-smoke, and docs.
- Existing marketplace audit -> inspect manifests, payload roots, install docs,
sync scripts, cache behavior, and validation evidence.
- Define the marketplace contract.
- Technical marketplace name, display name, owner, repository, license, version
source, target hosts, supported install scopes, and trust model.
- Plugin inventory: plugin IDs, descriptions, categories, tags, capabilities,
auth policy, and source paths.
- Payload inventory: skills, commands, agents, MCP servers, hooks, apps, assets,
scripts, binaries, and runtime dependencies.
- Split shared source from host outputs.
- Shared source: skill bodies, MCP code, assets, schemas, scripts, docs.
- Host output: marketplace root, plugin manifest, component paths, hook format,
MCP config, app config, install commands, cache paths, trust prompts.
- Do not claim one universal marketplace format unless current docs prove it.
- Specify packaging transforms.
- Deterministic file enumeration and sorted output.
- Version injection from one source.
- Asset copy near the consuming component.
- Namespace rewrite for slash commands where the host requires plugin namespaces.
- Host-specific path rewrite instead of leaking one host's root variables into
another host.
- Specify local dogfood.
- Use a distinct local marketplace name such as
<name>-local.
- Preserve disabled plugin state across reinstall.
- Keep official and local marketplace installs side by side.
- For Codex, run marketplace registration and plugin add/materialization.
- Specify validation gates before publishing.
- Schema/path validation for every marketplace and plugin manifest.
- Rebuild from source and fail on stale generated files.
- Byte-deterministic rebuild check.
- Install smoke in isolated host homes or config dirs.
- MCP handshake smoke:
initialize and tools/list from installed payload.
- Hook smoke: parse and execute declared command hooks with synthetic host env;
mark real trust/enablement as user-reviewed when required by the host.
- Cache refresh check for same-version local rebuilds.
Required Output
For design or requirements work, include:
- Official docs consulted.
- Requirements.
- Constraints.
- Anti-patterns.
- Canonical source layout.
- Host-specific output layout.
- Runtime, data, cache, and trust contracts.
- Local dogfood flow.
- Release sync plan.
- Validation gates.
- Risks and open questions.
- Related skills with links; read
references/related-skills.md when the user
asks for skill links or when routing adjacent work.
For implementation work, create files in this order:
- Shared source and schemas.
- Host-specific marketplace and plugin manifests.
- Build/sync scripts.
- Validation and install-smoke tests.
- User documentation.
Rules
- Keep generated marketplace payloads out of source control unless the downstream
repo is intentionally generated.
- Never edit generated
dist/ payloads by hand.
- Never publish from an unvalidated local tree.
- Never overwrite user-disabled plugin state during local reinstall.
- Never require manual config edits when the host supports native plugin wiring;
if a manual edit is unavoidable, label it as a host limitation.
- Never treat hook trust prompts as implementation noise; they are product
behavior.
- Never package Codex agents/subagents unless current Codex plugin docs define
that component. Represent worker behavior as skills when in doubt.
