canvas-app

# 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):

| Question | Header | When to Ask | Options |
|----------|--------|-------------|---------|
| Who will primarily use this app, and on what device? | Target Users & Device | Only if not clear from `$ARGUMENTS` | *(3–4 dynamically inferred options that combine the user role with their likely device, e.g., for "visitor check-in": Front desk staff on desktop/tablet, Security team on tablet, Self-service kiosk on tablet, Visitors on their phone)* |
| Do you have a screenshot or mockup for reference? (paste an image or provide a file path) | Reference | Only if user has NOT already attached/pasted an image with their request | Yes I'll share one now, No just pick a direction for me |
| What aesthetic direction? | Aesthetic | Only if not clear from `$ARGUMENTS` (skip if user already described a visual direction like "dark themed", "minimal", "corporate style", or provided a reference image) | Clean & Professional (Recommended), Bold & High-Contrast, Soft & Approachable, Dense & Utilitarian |
| Which features do you need? (multi-select) | Features | Only if `$ARGUMENTS` is vague on features | *(3–4 dynamically inferred options based on app purpose + target users)* |

**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