plugins-server-extensions

Plug-Ins & Server Extensions

This skill handles Dataverse server-side logic — C# plug-ins and custom APIs — with a code-first, headless-first posture. It registers and pushes plug-in assemblies and plug-in packages, inspects SDK message-processing steps and images, reconciles step enable/disable state against source intent, and creates custom APIs with their parameters and properties. It treats step enablement as explicit deployment state and registration as an approval gate separate from build, even when code creation and build were already approved. It is intentionally generic about environment URL, publisher prefix, solution name, and project layout — read or request them per task and preserve any existing layered *.Business/*.Data/*.Plugins delivery model.

When to use this

• The user wants to register, push, or update a plug-in (assembly or package) and its steps/images.
• A step needs inspecting, or its enabled/disabled state must be reconciled to match what the source intends.
• You are diagnosing step-state drift after a push, registration, or solution import.
• The user wants a custom API (bound or unbound) created, optionally backed by a plug-in.
• You need to confirm critical steps stayed enabled and intentionally disabled steps stayed disabled.

Route here from the powerplatform-core orchestrator. For flows, schema, PCF/web resources, or solution packaging, use the matching sibling skill instead.

Helpers

The helpers live in the plugin's scripts/ directory at the plugin root, not in this skill folder. Resolve the plugin root and invoke them like:

• python "$CLAUDE_PLUGIN_ROOT/scripts/inspect_plugin_steps.py" --spec <spec.json> (Claude Code)
• python "$CODEX_PLUGIN_ROOT/scripts/inspect_plugin_steps.py" --spec <spec.json> (also exposed as $PLUGIN_ROOT)
• Installed standalone / unsure: the scripts/ folder sits beside this skill bundle — invoke by its path within the install.

Helper	Purpose
register_plugin_headless.py	Assembly-based first registration: uploads the pluginassembly, creates the plugintype records explicitly (the classic database path does not auto-create them), then registers sdkmessageprocessingstep and sdkmessageprocessingstepimage records. --reuse-existing reconciles an assembly that already exists (creates missing types/steps) instead of failing.
register_plugin_package_headless.py	Package-based first registration via pluginpackage. More reliable default: Dataverse's server-side package processing auto-creates the pluginassembly/plugintype records, so type discovery is not the caller's problem.
push_plugin.py	Repeatable build-and-push when the target pluginId already exists; captures step state before, compares after, and fails on unexpected drift unless reconcile is requested.
inspect_plugin_steps.py	Inspect existing step state for an assembly or package — messages, stages, modes, filtering attributes, images, and enabled/disabled state.
ensure_plugin_step_state.py	Explicitly enable or disable existing steps so live state matches source intent (desiredState).
create_custom_api.py	Repeatable headless creation of a custom API plus its request parameters and response properties.