Plugin Development

This section is now an orientation page. The plugin documentation is intentionally split to reduce drift:

• user-facing setup stays in Quick Start / Plugins
• CLI command behavior stays in the generated CLI Commands reference
• maintainer-facing semantic contract belongs in the Divekit CLI repository
• plugin authoring and CI conventions belong in the plugin template repository
• plugin-specific CLI configuration can be exposed through Configuration Wizards

Split

User-facing setup

• discover plugins
• choose a source and pin a ref
• enable or disable them per distribution
• update injected templates

Use:

• Plugins
• CLI Commands

Maintainer-facing contract

• discovery requirements such as ci.yaml or ci.yml, and plugin.json
• optional materialized feedback assets under feedback/; plugin code ships in the plugin image
• CLI-managed state files such as .divekit/eval-pipeline/plugins.json and plugin-sources.json
• normalized reporting through plugin-results/<plugin-id>/report.json
• optional feedback and execution issue artifacts under plugin-results/<plugin-id>/feedback/ and plugin-results/<plugin-id>/issues/
• declarative configuration wizards exposed through plugin.json

See:

• Contract Reference
• Configuration Wizards
• CLI Plugin Contract

Authoring and CI conventions

• repository layout
• image structure (Dockerfile plus implementation code under src/)
• release-template usage
• ci.yaml / ci.yml structure
• DIVEKIT_PLUGIN_DIR usage for optional materialized feedback files
• FAQ artifact conventions
• execution issue artifact conventions
• copyable examples for new plugin repos

See:

• Authoring Guide
• Troubleshooting
• Plugin Template README

Practical Rule

If you are using plugins, stay in Quick Start and CLI reference. If you are building or maintaining plugins, use the maintainer-facing docs and template repository instead of treating this pages section as the primary source of truth.