Run any Skill in Manus with one click

powerplatform-core

Stars17

Forks0

UpdatedJuly 9, 2026 at 14:44

Entry point and router for Microsoft Power Platform and Dataverse development. Use to discover repo context, choose the right development surface, and run the mandatory live-mutation preflight before any deploy/publish/import/registration/data-write. Start here when the request spans multiple areas, is ambiguous, or the repo shape is unknown, then DEFER to the matching domain skill for focused single-domain work (schema, data, flows, plug-ins, PCF/web resources, code apps, solution ALM, security roles, document generation, custom connectors, platform administration). Trigger when the user mentions Power Platform, Dataverse, Dynamics 365, Power Apps, Power Automate, model-driven apps, solutions, or the pac CLI without naming a specific asset - but let the domain skills lead on their specifics.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

satriotsubasa

satriotsubasa/PowerPlatform-Core

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

dataverse-schema

satriotsubasa/PowerPlatform-Core

Use for Dataverse table METADATA - tables, columns, lookups/relationships, choices/option sets, alternate keys, main forms, public/lookup views, the form-level ribbon (RibbonDiffXml), form event handlers and script libraries, and table icons - plus up-front schema and query-shape design before metadata exists. Trigger on "create a table", "add a column/field", "add a lookup", "add a choice", "set an alternate key", "update the main form", "add a view / change view columns", "add a button to the form ribbon", "set the table icon", or "design a Dataverse schema", even when no helper is named. Prefer this over hand-edited customizations.xml. Not for row/record DATA, seeding config rows, or query authoring - use data-operations.

2026-07-0917

power-automate-flows

satriotsubasa/PowerPlatform-Core

Use for solution-aware Power Automate cloud flows in Dataverse - create, update, inspect, lint, connector governance review, hardening review (retry/concurrency/pagination/idempotency/ error handling), HTTP-trigger callback URL resolution, run-history inspection (recent runs, status, errors, duration), and the environment variables flows read. Fires whenever the user mentions a cloud flow, Power Automate, a workflow record, flow connection references, a flow trigger URL or webhook callback, "lint my flow", "harden this flow", "review the connectors", "why did my flow change behavior", "show me the run history", "did the flow run", "why did my flow fail", or "check the recent runs", even if no helper is named. Patches only the changed `workflow` properties and blocks semantic drift (emptied branches, dropped switch cases, removed required actions) by default. Not for C# plug-ins or custom APIs - use plugins-server-extensions. Run the live-mutation preflight from the `powerplatform-core` orchestrator before any

2026-07-0917

data-operations

satriotsubasa/PowerPlatform-Core

Use for Dataverse row/record DATA and queries - create, read, update, upsert, or delete rows, seed or sync reference/config data, and design and run queries. Trigger on "create a record/row", "read/retrieve this record", "get the value of a field on a row", "list/query the rows where", "how many rows match", "update this record", "upsert by alternate key", "delete this row", "seed config data", "import/sync these rows", "design an OData / FetchXML query", or "build the List rows filter for a flow", even when no helper is named. Covers keyed create/read/update/upsert/delete via the Dataverse SDK and query execution with bounded paging and total-count reporting, plus query design across OData, FetchXML, and Power Automate "List rows". Not for table/column/form/view/ribbon METADATA - use dataverse-schema.

2026-07-0817

platform-administration

satriotsubasa/PowerPlatform-Core

Use for Power Platform TENANT and ENVIRONMENT administration - the tasks normally done in the Power Platform Admin Center, driven headlessly via the `pac admin` CLI and the Power Platform API. Covers listing environments, creating / resetting / backing-up / restoring / deleting environments, reading and writing tenant settings, data loss prevention (DLP) policies, managed environments, environment groups, application users / admin service principals, and capacity reporting. Trigger on "list the environments", "create / reset / delete / backup / restore an environment", "tenant settings", "DLP" / "data policy", "managed environment", "environment group", "Power Platform admin", "admin center", or "what environments are in this tenant", even when no helper is named. Admin-tier: it needs a Power Platform Administrator profile, distinct from the maker/developer Dataverse auth the other skills use. NOT for Dataverse data or solution ALM inside a single environment - use data-operations or solution-alm-delivery. Ru

2026-06-2917

plugins-server-extensions

satriotsubasa/PowerPlatform-Core

Use for Dataverse server-side logic in C# - plug-ins and custom APIs. Covers headless first registration of a plug-in assembly or package, repeatable build-and-push, SDK message-processing step and image inspection, reconciling step enable/disable state to source intent, and creating a custom API with its request parameters and response properties. Fires whenever the user mentions a plug-in, plugin step, SDKMessage, pre/post image, plug-in assembly or package, "register my plug-in", "push the plug-in", "why is my step disabled", step-state drift, or a custom API / unbound action backed by a plug-in, even if no helper is named. Treats step enablement as explicit deployment state and registration as a separate approval gate. Not for Power Automate cloud flows - use power-automate-flows. Run the live-mutation preflight from the `powerplatform-core` orchestrator before any registration, push, or step-state write.

2026-06-2817

code-apps

satriotsubasa/PowerPlatform-Core

Use for Power Apps Code Apps - the pro-code model where a standalone Vite-built React/Vue/TS single-page app uses the `@microsoft/power-apps` client library and is pushed into a Power Platform environment with no server to manage. Covers scaffolding from the official Vite template, initializing with `power.config.json`, adding Dataverse data sources that generate typed model/service files, local dev, building, and pushing via `npx power-apps push` (npm CLI) or legacy `pac code push`. Trigger whenever the user mentions a code app, `power.config.json`, `@microsoft/power-apps`, `pac code` / `power-apps` CLI, a `CodeApp/` folder, or wants to build, run, or push a custom SPA into Power Platform, even if no helper is named. Not for PCF controls embedded in model-driven forms (use pcf-and-web-resources) or Canvas/maker apps.

2026-06-1117

name

powerplatform-core

description

Power Platform Core — Orchestrator

PowerPlatform-Core is a code-first coding-agent skill for Microsoft Power Platform and Dataverse development. This orchestrator is the entry point: it discovers repo context, routes to the right domain skill, and enforces the safety rules that every domain shares. It is intentionally generic — it does not assume one house repo convention, environment URL, publisher prefix, or folder layout.

Prefer executable, source-controlled surfaces (JavaScript, plug-ins, custom APIs, supported metadata APIs, SDK/Web API helpers, PAC CLI, repo-owned deploy wrappers) over Business Rules, portal memory, browser automation, or stale solution packages.

How it works

Discover first. Run the discovery helper before asking broad setup questions; infer the project shape from existing artifacts (solutions, plug-ins, PCF, pipelines, project profile).
Choose the surface. Pick the lightest surface that fits — metadata, client script, plug-in, custom API, flow, PCF, web resource, config data, or solution ALM — then open the matching domain skill.
Apply repo-backed changes first so the result is source-controlled and reviewable.
Run the live-mutation preflight before any deploy, publish, import, registration, push, or data write.
Validate and deliver through the approved targeted path unless the user explicitly accepts a broader blast radius.

Running the helper scripts

The Python helpers and the compiled CodexPowerPlatform.DataverseOps / CodexPowerPlatform.AuthDialog tools live in the plugin's scripts/ and tools/ directories at the plugin root — not inside each skill folder. Resolve the plugin root and invoke a helper like this:

Claude Code: python "$CLAUDE_PLUGIN_ROOT/scripts/discover_context.py" --path .
Codex: python "$CODEX_PLUGIN_ROOT/scripts/discover_context.py" --path . (also exposed as $PLUGIN_ROOT)
Installed as a standalone skill / unsure: the scripts/ and tools/ folders sit beside this skill bundle; invoke them by their path within the install.

Shared references that several domains use (surface selection, verification, ALM, archetypes) live in the plugin's references/ directory; domain skills point to the specific files they need.

Mandatory live-mutation preflight

Before any live Dataverse mutation, print or capture a preflight gate. Use scripts/validate_delivery.py --preflight-spec ... when it fits; otherwise produce the same fields manually and stop if any required field is missing.

Required fields: target environment URL; active PAC profile and mismatch warning when PAC is involved; target solution unique name and whether it is a patch; mutation type; exact components touched; delivery primitive; for any ZIP/package — artifact path, creation/modification time, solution name/version, managed state, and component diff; blast radius (targeted, component subset, patch package, or full solution); rollback/recovery plan; timeout and fallback path; and explicit confirmation when the primitive is not targeted.

Do not import a ZIP from bin, Release, Downloads, or old temp folders unless it was generated in the current session or explicitly selected by the user. If multiple package candidates exist, stop and ask. Never silently escalate from a targeted helper to a whole-solution import.

Dataverse MCP interop (optional companion)

Microsoft's Dataverse MCP server (hosted at https://{org}.crm.dynamics.com/api/mcp) is complementary, not competing: it lets an agent talk to your data conversationally; this plugin lets an agent ship your solution. When both are connected, route by intent instead of defaulting to either.

Prefer the Dataverse MCP for interactive natural-language exploration where the user is asking, not shipping: ad-hoc "what rows look like this", schema questions (describe), and small read-only lookups (search, search_data, read_query). It has no repo context and no delivery safety, but it is the lowest-friction way to answer a data question in the moment.
Prefer this plugin's helpers for anything paged, keyed, verified, solution-aware, or mutating: bounded paging with total counts (read_data.py --mode list), keyed retrieve/create/update/upsert/delete (read_data.py/upsert_data.py/delete_data.py), solution-scoped writes, flow/plug-in registration, deploys, and every path that must pass the live-mutation preflight. The MCP has no preflight gate, so never route a live mutation through it when a delivery contract matters.
Degrade gracefully around known MCP limits. read_query returns a small capped page (community reports ~20 rows) and supports only a SQL subset — when a result is truncated or a query is rejected, fall back to read_data.py/design_dataverse_query.py (FetchXML with explicit paging and a totalRecordCount) rather than trusting a partial MCP result.
The MCP is optional. If it is not connected, everything still works through the plugin helpers; do not tell the user they must install it. To run both, register the MCP alongside the plugin: claude mcp add --transport http dataverse https://{org}.crm.dynamics.com/api/mcp. The full trade-off analysis lives in the project repo at docs/comparison-dataverse-mcp.md (not shipped inside the installed bundle).

Route to the right domain skill

The task is about…	Open skill
Tables, columns, relationships, forms, views, ribbon, icons, schema design	`dataverse-schema`
Row create/update/upsert, query design (OData/FetchXML/Power Automate)	`data-operations`
Solution-aware cloud flows: create, update, inspect, lint, connector/hardening review, trigger URLs	`power-automate-flows`
Plug-ins, custom APIs, step registration, plug-in step state	`plugins-server-extensions`
PCF controls, web resources, client scripts, Power Fx	`pcf-and-web-resources`
Power Apps Code Apps (pro-code SPA model)	`code-apps`
Solution pack/import/deploy, versioning, patch/merge, components, standards, delivery validation	`solution-alm-delivery`
Security roles and privilege sets	`security-roles`
Word Templates and document generation	`document-generation`
Custom connectors and integration wrappers	`custom-connectors`
Power Platform tenant/environment administration (admin center): environments, tenant settings, DLP, managed environments, environment groups, capacity	`platform-administration`

When a repo matches a documented overlay's conventions, suggest the specialized overlay skill if one is installed.

Discovery and project context

Run scripts/discover_context.py --path . first when the repo shape is not obvious. Add --include-pac-auth only when live access matters and PAC CLI is available.
If the repo has .codex/power-platform.project-profile.json or power-platform.project-profile.json, treat that profile as the first override layer for main solution, source areas, and conventions. If it has a deploymentDefaults block, treat those values as the repo's operational deploy guidance (timeout budgets, manual-only surfaces, preferred primitives, plug-in step-state defaults, typed row-write coercion). See references/project-profile.md.
If the repo matches a layered structure (*.Business, *.Plugins, *.Data, WebResources, *.PCF, Word Templates, Dataverse, Tools), follow that layout — see references/repo-archetypes.md.
Open references/execution-surface-guide.md to choose between metadata, client script, plug-ins, custom APIs, flows, web resources, or PCF.
Open references/verification-and-recovery.md for live-mutation work, deployment, or a precise completion standard before execution starts.
Open references/context-and-alm.md for auth, source-control layout, pac workflows, and environment safety.
For durable multi-session work, keep README.md and CODEX_HANDOFF.md current — see references/thread-continuity.md.

Default operating assumptions

For live SDK/Web API work, prefer the reusable auth dialog (scripts/auth_context.py) so the user confirms the target URL, completes a forced interactive sign-in, and selects the working solution before execution. The dialog is Windows-only; on macOS/Linux, sign-in uses the device-code flow (the tool prints a code to complete in a browser). Use pac auth interactive when the dialog is unavailable.
Warn when the requested live target does not match the active PAC profile environment URL. Treat DEV as the working environment and TEST as deployment validation. Do not touch production.
Ask before delete, import, publish, register, push, or upgrade. Do not delete business data unless explicitly requested and separately approved.
Keep every change solution-scoped (add/update only the scoped components in the target unmanaged solution or selected patch) — this does not mean defaulting to solution import.
Do not introduce Dataverse Business Rules. Use client script for form-scoped behavior and plug-ins or custom APIs for shared server-side behavior.
Treat plug-in step enablement as explicit deployment state: after registration/push/import, verify critical steps stay enabled and intentionally disabled steps stay disabled.
Treat browser automation as opt-in fallback only, after headless options are exhausted.
Report exactly what changed, what was inferred, what was executed, what was verified, what still needs environment access, and which publish/import/registration steps were intentionally not performed.

Closing out

Validate the narrowest relevant surface, prefer small reviewable diffs over large repacks, and never describe a change as "deployed" or "complete" beyond what was actually verified. If critical inputs are missing (environment URL, solution name, publisher prefix, managed strategy, target folder), ask concise questions instead of guessing.