Why plugin-kit-ai

plugin-kit-ai exists to solve a very specific problem: teams want one real plugin repo that can grow into more supported outputs, not a pile of hand-edited target files and one-off helper scripts.

What It Gives You

• one repo instead of drift across separate target setups
• one workflow that can generate multiple supported outputs without turning into a pile of hand-maintained repos
• a strong default Go path and stable local Python and Node paths
• deterministic generate and validation flows
• generated API and support metadata that stay tied to real source data

Who It Is For

• plugin authors who want a stronger structure than ad-hoc local scripts
• teams migrating from native target files to a repo-owned workflow
• maintainers who care about drift detection, strict validation, and explicit public boundaries

When It Is The Wrong Tool

It is probably the wrong choice when:

• you only want a tiny one-off local script with no intention to maintain structure
• you want universal dependency management for every interpreted runtime ecosystem
• you want every target and every hook family to carry the same stability promise

What Matters Most

plugin-kit-ai optimizes for manageability, not ad-hoc flexibility.

In practice, that means:

• one repo instead of drift across target files
• one clear workflow through generate, validate, and CI
• one repo that can grow into more supported outputs without losing structure
• an explicit support boundary that makes engineering decisions easier for teams

Read One Project, Multiple Targets if you want the direct product-level explanation of how one repo grows over time. Read Managed Project Model if you want the deeper internal model behind that workflow. Pair this page with Choosing Runtime and Support Boundary.