feat: plugin system design for portable kit extensions

[LucasSantana-Dev]

Summary

Design and implement a portable plugin system that allows external packages to extend the forgekit catalog without modifying the core monorepo.

Motivation

Currently, adding catalog entries requires a PR to this repo. Teams with private or domain-specific skills, agents, or hooks have no clean extension path. A plugin system would enable:

• Private catalogs mounted alongside the public one
• Third-party skill packages published to npm
• Organization-scoped overrides of default entries

Proposed approach

1. Discovery: forge-kit CLI resolves plugins from a local config (e.g., ~/.config/ai-dev-toolkit/plugins.json) and from workspace-local .forgekit/plugins.json
2. Schema: A plugin is an npm package (or local directory) that exports a catalog subtree matching the existing directory structure (skills/, agents/, collections/, etc.)
3. Merging: Plugin entries are merged into the catalog at runtime; conflicts resolved by explicit priority order
4. Validation: pnpm catalog:validate runs against the merged catalog, not just the built-in one

Out of scope (v1)

• Plugin marketplace / discovery
• Plugin signing or trust model
• GUI management

Open questions

• Should plugins be resolved at CLI runtime or at build time for the web UI?
• What's the naming convention to avoid ID collisions between plugins?

References

• backlog.json item: plugin-system (status: backlog, priority: low)
• Current catalog structure: packages/catalog/catalog/