Create or Edit a Canvas App

Create or edit a Power Apps canvas app for the following requirements:

$ARGUMENTS

Overview

This skill handles both creating and editing canvas apps through a unified workflow. It syncs the current app state to detect whether the app has existing content, then routes accordingly:

• CREATE mode — the app is empty or has no meaningful content; a new app is generated from scratch using a preferences wizard and parallel screen builders.
• EDIT mode (simple) — the app has existing content and the requested changes are small; edits are applied inline without planning agents.
• EDIT mode (complex) — the app has existing content and the requested changes are substantial; a planner designs the changes and parallel screen builders execute them.

Two specialist agents are used for planned work:

1. canvas-app-planner — discovers available controls, APIs, and data sources; gathers control property definitions; and writes the shared plan document (canvas-app-plan.md) and App.pa.yaml. Receives the approved plan from the skill.
2. canvas-screen-builder — writes or modifies exactly one screen's YAML; multiple builders run in parallel after the plan is approved

You (the skill) coordinate the agents, detect mode, design and present the plan for user approval, and own the compilation + error-fixing loop after all screens are written.

Phase 0 — Create App Folder

Before syncing or editing, create a subfolder to contain the app's YAML files:

1. Extract the app name or a 2–4 word summary from $ARGUMENTS
2. Convert to kebab-case (e.g., "Expense Tracker" → expense-tracker, "my travel planner" → my-travel-planner)
3. Create the folder using Bash: mkdir -p <folder-name>
4. Resolve its absolute path — this is the working directory for all subsequent phases

Pass this absolute path as the working directory in every agent prompt below.

Phase 1 — Sync

Call the sync_canvas MCP tool targeting the working directory. This pulls the current app state from the coauthoring session into local .pa.yaml files. Only proceed after sync_canvas completes successfully.

Phase 2 — Detect Mode

After sync_canvas completes, read the synced .pa.yaml files and check whether the app has meaningful content. An app is considered empty if:

• No .pa.yaml files were written, or
• The only files present contain no screens, or
• Every screen present has no controls (only bare screen-level YAML with no children), or
• Every screen's controls consist solely of containers (e.g., GroupContainer) with no leaf controls inside them

If the app is empty → CREATE mode. Proceed to Phase 3.

If the app has meaningful content → EDIT mode. Skip Phase 3 and proceed to Phase 4.

Phase 3 — Gather Preferences (CREATE mode only)

Use AskUserQuestion to collect design preferences that cannot be reliably inferred from $ARGUMENTS. Parse $ARGUMENTS first to determine which questions to skip — but a short request like "visitor check-in app" or "expense tracker" leaves most preferences unspecified and you MUST ask.

Call AskUserQuestion with the applicable questions from the table below (include only the ones that need answers):

Rules:

1. If the user provides a screenshot (either attached with their original request or via the wizard), examine it to extract structural cues (layout, navigation pattern) and visual cues (color palette, density, typography). Use these to inform the aesthetic direction — do not ask the aesthetic question separately.
2. If all questions are already answered by $ARGUMENTS and any attached images, skip the wizard entirely and proceed directly to Phase 5.
3. Ask all applicable questions in a single AskUserQuestion call — do not ask them one at a time.
4. Store all answers for use in the planner prompt below.

Target users & device influence design decisions:

• Desktop users → data-dense layouts, tables, keyboard-friendly, multi-column. ManualLayout acceptable for pixel-perfect dashboards.
• Tablet users → touch-friendly targets, medium density, AutoLayout (responsive) so the app adapts to landscape/portrait.
• Phone users → large touch targets, single-column, simplified navigation, AutoLayout (responsive), minimal typing.
• Multi-device / unknown → AutoLayout (responsive) required.

After collecting preferences, proceed to Phase 5 (Plan).

Phase 4 — Assess Complexity (EDIT mode only)

Read all synced .pa.yaml files. Based on $ARGUMENTS and the current app state, determine whether this is a simple or complex edit:

Simple — all of the following are true:

• Changes affect ≤ 2 controls or properties
• Changes are confined to ≤ 1 screen
• No new screens are being added
• No new data sources or connectors are needed
• No structural layout changes (e.g., not changing ManualLayout to AutoLayout)

Examples: change a button color, update label text, fix a formula, adjust a control size.

Complex — any of the following are true:

• Changes span multiple screens
• One or more new screens need to be created
• New data sources or connectors are required
• Structural layout changes are involved
• Significant visual redesign of a screen

Examples: add a settings screen, redesign the home screen layout, integrate a new connector, change the navigation flow across the app.

• If simple: proceed to Phase 4a.
• If complex: proceed to Phase 5 (Plan).

Phase 4a — Simple: Direct Edit

Read ${CLAUDE_PLUGIN_ROOT}/references/TechnicalGuide.md before making changes.

Apply the changes directly:

1. Edit the relevant .pa.yaml files with the required changes, following conventions from TechnicalGuide.md.

2. Validate by calling compile_canvas on the working directory after making changes. On failure, read the errors, fix with Edit, and re-compile. Iterate until clean.

3. Present a brief summary:

   Edit complete. [1-2 sentence description of what was changed.] Compiled clean after [N] pass(es).

Stop here. The simple edit path is complete — do not continue to Phase 5 or beyond.

Phase 5 — Plan

You (the skill) own plan design and user approval. After approval, invoke the canvas-app-planner agent to discover resources, gather control definitions, and write the plan document.

Step 5.1 — Read Reference Documents

Read both reference documents before designing the plan:

• ${CLAUDE_PLUGIN_ROOT}/references/TechnicalGuide.md
• ${CLAUDE_PLUGIN_ROOT}/references/DesignGuide.md

Internalize both. These gover