power-platform-solution-builder

name

power-platform-solution-builder

description

Plan, build, validate, package, and import complete Microsoft Power Platform solutions from user requirements, including solution-aware canvas apps, Power Automate cloud flows, connection references, environment variables, responsive Power Apps design, PAC CLI auth/import/export, and Docker-based validation fallback. Use when a user wants an import-ready Power Platform solution zip or .msapp, asks to fix Power Apps checker, formula, or layout issues, or needs end-to-end Power Platform implementation guidance.

Power Platform Solution Builder

Overview

Use this skill to turn a brief, PDF, or existing app into a validated Power Platform delivery: solution-aware canvas app, cloud flow, solution package, deployment settings, and environment import verification.

Prefer a solution-first workflow. Treat standalone .msapp files as intermediate artifacts unless the user explicitly wants only the app file.

Trigger Examples

• "Create a full Microsoft Power Platform solution from this take-home PDF."
• "Build the missing Power Automate flow and give me an import-ready solution zip."
• "Fix the formula errors in this Power App and rerun the checker."
• "Make this canvas app responsive and repack the solution."
• "Import the updated solution into my environment without touching the others."

Start Here

0. If starting a new repo, scaffold it first:
   • python3 scripts/scaffold_power_platform_project.py /path/to/new-project --project-name "My Project" --preset enterprise
   • Then read references/project-scaffold.md
1. Read references/requirements-and-research.md and create a requirement matrix before building.
2. Read references/environment-and-tooling.md and run scripts/power_platform_preflight.sh.
3. If the host .NET or PAC installation is unreliable, use scripts/power_platform_docker.sh for PAC and PASopa instead of trusting the local runtime.
4. Read only the references needed for the current phase:
   • Canvas app UX, formulas, or responsiveness: references/canvas-app-design.md
   • Live imported-app screenshots, Dia browser capture, or image-based visual QA: references/live-visual-qa.md
   • Flow design, connectors, or connection references: references/flow-and-connectors.md
   • Packaging, checker, import/export, solution versioning: references/validation-and-alm.md
   • Formula failures, packaging oddities, auth issues, or visual regressions: references/troubleshooting.md

Workflow

1. Isolate the target environment

• Confirm the exact environment before any import or maker action.
• Prefer a dedicated environment or, at minimum, a dedicated solution name and publisher prefix.
• Avoid editing unrelated existing solutions unless the user explicitly approves it.
• If the flow needs Teams, Planner, or mailbox targets, prefer dedicated project assets instead of reusing the user's live operational assets.

2. Map requirements before building

• Extract every explicit requirement from the brief.
• Add inferred technical requirements only when they are necessary to make the solution importable, supportable, or testable.
• Record each requirement, implementation decision, validation method, and unresolved assumption.
• Do not start building until every requirement has an owner and a verification path.

3. Research from primary sources

• Use official Microsoft Learn pages and official Microsoft repositories first.
• Re-check time-sensitive topics such as PAC CLI flags, solution settings, responsive-layout guidance, connection-reference behavior, and current source formats.
• Prefer environment URL or environment ID over friendly names in CLI workflows when scripting auth and imports.

4. Design the solution architecture

• Decide the solution name, publisher prefix, versioning scheme, data model, connectors, connection references, environment variables, and deployment settings strategy.
• Choose whether to use Dataverse tables, standard tables, or external sources. If custom schema is required, include it in the solution instead of relying on manual post-import setup.
• Keep the canvas app, flow, and supporting configuration solution-aware from the start.

5. Build the canvas app

• Make the app look like a finished production app, not a walkthrough or submission guide.
• Use responsive formulas, not desktop-only fixed geometry.
• Keep labels, cards, forms, galleries, and action areas resilient to different widths.
• Treat formula errors, clipped text, overlap, and broken navigation as ship blockers.

6. Build the flow and connectors

• Create the flow inside the solution or move it into the solution immediately.
• Use connection references and environment variables where appropriate.
• Make the flow idempotent when duplicate triggers or replays would create bad side effects.
• Separate business logic from environment-specific identifiers so the solution can be imported cleanly.

7. Validate aggressively

• Rebuild the .msapp.
• Run PASopa round-trip validation if the project uses extracted msapp sources.
• Run pac canvas validate on official unpacked app source.
• Run pac solution check on the packaged solution.
• Capture live screenshots from the imported app when responsiveness or visual quality matters.
• Fix every formula error, binding error, import-time dependency issue, and obvious design regression before handoff.

8. Package, import, and verify

• Produce the standalone .msapp if the user asked for it or it is useful for review.
• Produce the unmanaged solution zip, and a managed zip if explicitly requested.
• Generate or update the deployment settings file for connection references and environment variables.
• Import into the approved environment, publish changes, and verify the solution version and key components afterward.
• Only declare delivery complete after import and post-import verification succeed, or state exactly what remains unverified.

Guardrails

• Do not hand-author unsupported solution internals when the official tooling or maker portal must generate them.
• Do not treat unstable generated .msapp JSON as the source of truth when Src files or solution source are available.
• Do not assume the local PAC or .NET installation works; verify it. On macOS, Docker fallback is often safer.
• Do not leave stale checker artifacts, sample files, or inherited placeholders in the final package.
• Do not claim the app is responsive without testing multiple widths and checking for clipping, overlap, scroll traps, and truncated labels.
• Do not treat source inspection as enough visual QA when you can attach to a live authenticated browser session and capture the real player.

Quick Commands

# Scaffold a new project
python3 scripts/scaffold_power_platform_project.py /path/to/new-project --project-name "My Project" --preset enterprise

# Preflight local machine and workspace
scripts/power_platform_preflight.sh /path/to/project

# Run PAC in Docker with persistent auth cache
scripts/power_platform_docker.sh pac auth create --deviceCode --environment <env-id-or-url>
scripts/power_platform_docker.sh pac solution import --environment <env-url> --path output/MySolution.zip --settings-file output/MySolution.settings.json --publish-changes

# Run PASopa in Docker
POWERAPPS_TOOLING_DIR=/path/to/PowerApps-Tooling \
scripts/power_platform_docker.sh pasopa -pack output/MyApp.msapp powerapps_app_src

Resources

• references/requirements-and-research.md
• references/environment-and-tooling.md
• references/project-scaffold.md
• references/canvas-app-design.md
• references/live-visual-qa.md
• references/flow-and-connectors.md
• references/validation-and-alm.md
• references/troubleshooting.md
• scripts/power_platform_preflight.sh
• scripts/power_platform_docker.sh
• scripts/relaunch_dia_for_powerapps.sh
• scripts/powerapp_live_capture.js
• scripts/scaffold_power_platform_project.py