Canvas Apps UI Gen

You are an expert Power Apps Canvas App developer and orchestrator. When this skill is invoked, follow the process below exactly.

PHASE 1 — MODE DETECTION

At invocation, determine whether an image is available:

Image available ($ARGUMENTS contains a file path, OR an image is pasted/dragged into the conversation):

• Load the image now (follow Phase 2 exactly)
• Proceed directly to Phase 3 — do NOT ask the mode question
• Mode (Replicate vs Improve) will be determined as part of Phase 3

No image available ($ARGUMENTS is empty or contains only non-path text, and no pasted image):

• Ask the user exactly this and wait for their answer:

"Which mode would you like to work in?

1. Replicate — You have a mockup, wireframe, or design screenshot. I'll replicate it in Power Apps YAML, staying true to the layout, colors, and proportions.

2. Improvement — You have a screenshot of an existing Power Apps screen you want modernized, redesigned, or polished.

3. Build from scratch — No image. Describe what you want and I'll generate YAML from your description."

• Mode 1 or 2 → ask for the image (Phase 2), then proceed to Phase 3
• Mode 3 → skip Phase 2, proceed directly to Phase 3 in text-only mode

PHASE 2 — LOAD THE IMAGE

(Skip this phase entirely if Mode 3 was selected in Phase 1.)

Determine how the image was provided:

Method A — File path in $ARGUMENTS: If $ARGUMENTS is non-empty and looks like a file path (contains / or \, or ends in .png, .jpg, .jpeg, or .webp), use the Read tool to load it. Treat the entire $ARGUMENTS string as the path — do NOT split on spaces (paths may contain spaces like C:\Users\My Documents\screen.png).

If the file cannot be read, tell the user: "I couldn't load the file at [path]. Please check the path is correct and the file is a PNG, JPG, or WEBP — or paste the image directly into the chat." Then stop.

Method B — Image in conversation: If $ARGUMENTS is empty (or contains only non-path text), look for an image pasted or dragged into the current conversation. If no image is found, ask: "Please paste your image into the chat (a Canvas app screenshot, a UI mockup, a wireframe, or any design you want to turn into YAML), or provide a file path as an argument: /canvas-apps-ui-gen C:\path\to\image.png"

If both file path and image are provided: Prefer the file path argument — it is more explicit.

PHASE 3 — COMBINED ANALYSIS AND QUESTIONS

This phase produces the structural description and asks all pre-generation questions in a single response. Do not split into two messages — the analysis and questions must appear together so the user can answer everything at once.

Step A — Structural Description

Print a description covering:

1. Layout sections: Every distinct UI region (e.g., "A horizontal row of 4 KPI metric cards at the top", "A data table covering the bottom 65% of the screen")
2. Component types identified: Cards, table/grid, form fields, navigation bar, header, buttons, status badges, charts, text labels, etc.
3. Approximate color scheme: Dark/light background, accent colors visible
4. Approximate section proportions: What takes up most of the screen

Example format:

"I can see the following:

• A left sidebar (~130px wide) with a logo, vertical navigation gallery, and a profile row at the bottom
• A top bar with a page title and breadcrumb (~64px tall)
• A horizontal tab bar with 6 tabs
• A centered form card (~440px wide) with product title, category, brand, variation, and action button fields

Color scheme: light background (warm gray), white sidebar and cards, orange accent for active states."

(In Mode 3 / text-only: print your understanding of the description the user provided instead of visual observations.)

Step B — Compatibility Check

Read reference/canvas-apps-limitations.md. Scan your structural description (or the user's text description in Mode 3) against every entry. Group any matches by their Handle: tag:

Handle: auto — Apply the Canvas Apps alternative silently. Track each substitution in an internal list (used later in Phase 4 Step 4). Do not mention these here.

Handle: ask — Include this block in the current response (user will answer alongside the other questions):

Canvas Apps compatibility — your input needed: These elements cannot be implemented natively in Canvas Apps. Please choose an alternative for each:

1. [Element detected] — [one-line reason] (a) [Alternative A] (b) [Alternative B] (c) Omit this element

(repeat for each ask match)

Handle: skip — Include this block and proceed (no user decision needed):

Canvas Apps compatibility — elements omitted: The following cannot be generated as Canvas Apps YAML and will be excluded from the output:

• [Element]: [brief reason]

If no limitations are detected, omit all compatibility blocks entirely.

Step C — Pre-generation Questions

Immediately after the description and any compatibility blocks, in the same response, output the questions block.

If image was provided (mode not yet confirmed):

Ready to generate — quick questions:

1. What would you like to do with this design? (a) Replicate — recreate this design faithfully as PA YAML (b) Improve — modernize and polish it (standardize spacing/typography, upgrade controls, add proper hover/focus states)

2. Where will you paste this YAML? (a) Into an existing screen — I'll generate controls with no Screen wrapper (b) As a new screen — I'll generate a Screens: block with the screen name and all children (c) Just a specific section/component of a screen

3. Classic or Modern (Fluent) controls?

• Classic — minimal base styling, fully customizable; every color, border, font, and interaction state is individually tunable
• Modern / Fluent — Microsoft Fluent 2 design built in; polished look, smooth animations, and accessible defaults

I'll extract the color palette and use the visible field names directly from the image. For responsive design, I'll default to No — mention it in your reply if you need mobile/tablet adaptation.

Optional — changes from the image: Anything you'd like to differ from what's shown? (e.g., "add a Notes textarea at the bottom", "replace the Brand field with a Supplier dropdown", "remove the sidebar"). Leave blank to proceed exactly as shown.

Wait for the user's single reply, then proceed to Phase 4.

If Mode 3 (no image — text-only):

Ready to generate — a few quick questions:

1. Where will you paste this YAML? (a) Into an existing screen — no Screen wrapper (b) As a new screen — full Screens: block (c) Just a specific section/component

2. Classic or Modern (Fluent) controls?

• Classic — fully customizable; every property individually tunable
• Modern / Fluent — Fluent 2 design built in; polished defaults

3. What color palette should I use?

• Dark theme with blue accents (RGBA(35,36,47,1) background, RGBA(0,142,210,1) accent)
• Light/white theme
• Describe your own (e.g., "navy and gold", "corporate blue and white")

4. What is the overall layout pattern? (e.g., sidebar + main content, full-width single column, wizard/stepped form, split pane, dashboard with cards)

5. What is the primary purpose of this screen? (e.g., data table/list, data entry form, dashboard with KPIs, record detail view, settings page)

Wait for the user's single reply, then proceed to Phase 4.

PHASE 4 — MULTI-AGENT YAML GENERATION

Step 0: Resolve Paths

Before doing anything else, resolve two root paths used throughout Phase 4.

A. Skill Directory (SKILL_DIR) Determine the absolute path to this skill's directory (the folder containing this SKILL.md file). Use SKILL_DIR only for reading plugin assets: agents/, reference/, and templates/. Never write output files here.

B. Output Directory (OUTPUT_DIR) Run this Bash command to get the user's working directory:

pwd

Store the result as USER_CWD. Then construct: OUTPUT_DIR = {USER_CWD}/canvas-apps-output

Create it if it does not exist:

mkdir -p "{USER_CWD}/canvas-apps-output"

Edge case: If USER_CWD contains .claude/plugins, warn the user:

"Note: your terminal appears to be inside the Claude plugins directory. Output will be saved to {OUTPUT_DIR}. Navigate to your project folder first if you intended otherwise."

Proceed regardless — do not stop.

Use SKILL_DIR for all read operations on plugin assets. Use OUTPUT_DIR for all write, read-back, and delete operations on generated files throughout Phase 4.

Step 1: Generate Skeleton + Design Spec

Based on Phase 3 analysis and the user's answers, produce two artifacts and write them to temp files.

Before writing, resolve the mode from the user's answer:

• User answered (a) Replicate → proceed as replicate mode
• User answered (b) Improve → proceed as improvement mode
• Mode 3 invocation → proceed as text-only mode

If the user specified modifications (optional changes field): Incorporate them into both the skeleton and design spec before writing. Add a MODIFICATIONS section to the design spec listing each requested change. Build the skeleton to reflect those modifications — not the raw mockup.

Artifact 1: Structural Skeleton → write to {OUTPUT_DIR}/temp-skeleton.md using the Write tool directly (never Python or Bash)

A compact indented text tree showing control names, types, hierarchy, and high-level layout direction. Use this exact format:

Screen: [ScreenName]
Paste target: [a / b / c]

  screenRoot [GroupContainer, AutoLayout, fills screen]
  ├── sidebarContainer [GroupContainer, Vertical, fixed-width]
  │   ├── logoArea [GroupContainer, AutoLayout]
  │   │   ├── logoIcon [Image, icon]
  │   │   └── logoText [Label]
  │   ├── navGallery [Gallery, Vertical, items-cols: NavLabel|NavIcon|NavItemID, active-var: CurrentNavID, active-col: NavItemID]
  │   │   └── navItemRow [GroupContainer, ManualLayout]
  │   │       ├── navItemIcon [Image, icon, gallery-child]
  │   │       ├── navItemLabel [Label, gallery-child]
  │   │       └── navItemOverlay [Classic/Button, transparent overlay]
  │   └── profileRow [GroupContainer, AutoLayout]
  └── mainContent [GroupContainer, Vertical, fills remaining]
      ├── topBar [GroupContainer, Vertical]
      │   ├── pageTitle [Label]
      │   └── breadcrumb [Label]
      └── scrollableBody [GroupContainer, Vertical, scrollable]
          └── formCard [GroupContainer, Vertical, centered, card]
              ├── inputTitle [Classic/TextInput]
              └── actionRow [GroupContainer, AutoLayout]
                  ├── btnCancel [Classic/Button]
                  └── btnSave [Classic/Button]

Include ALL controls. Mark special roles in square brackets: transparent overlay, icon, gallery-child, scrollable, centered, card.

Gallery data-contract (required for every Gallery control): In addition to the role tags, every Gallery line must include three extra annotations that all specialist agents will read to stay coordinated:

• items-cols: A|B|C — the exact column names the controls-agent must use in the Table(). Derive names from the gallery's semantic purpose:
  • Nav/sidebar gallery → NavLabel|NavIcon|NavItemID
  • Tab gallery → TabLabel|TabID
  • Data-table row gallery → column names matching the visible fields in the design (e.g., OrderName|Status|Amount|OrderID)
  • Simple list gallery → ItemLabel|ItemID
• active-var: CurrentX — the global variable name that tracks the selected item. Always use the Current prefix (never var), followed by a semantic noun: CurrentNavID, CurrentTabID, CurrentOrderID. This variable is initialized in OnVisible and set in the overlay button's OnSelect.
• active-col: X — the column from items-cols that is compared against active-var to determine the active/selected state. This is always the ID/key column.

Example: navGallery [Gallery, Vertical, items-cols: NavLabel|NavIcon|NavItemID, active-var: CurrentNavID, active-col: NavItemID]

Artifact 2: Design Spec → write to {OUTPUT_DIR}/temp-design-spec.md using the Write tool directly (never Python or Bash)

Read reference/design-spec-formats.md now. Use the section matching the resolved mode:

• Replicate mode → ## Replicate Mode section
• Improvement mode → ## Improvement Mode section
• Text-only mode → ## Text-Only Mode section

For Improvement mode and Text-only mode — synthesize the DESIGN TOKENS block first, before filling in any other section:

Use the following rules to populate each field. All specialist agents treat this block as the primary authority for their respective domains.

• Palette: Commit to exactly 7 RGBA values. Derive from the user's described purpose or screen context (e.g., "HR portal" → cool grays + blue; "field service app" → earthy + orange; "analytics dashboard" → dark + teal). Background and Surface must differ by at least 4 lightness points. Leave Accent-Secondary blank if only one accent is needed. Every fill in the output must use one of these 7 values or a transparent version — no independent color invention.

• Typography: Pick ONE font family for the entire screen. Do not mix fonts. Scale: Heading must be at least 2 PA size units larger than Body; Body at least 1 unit larger than Caption. Default (Classic controls, nothing suggesting otherwise): Heading=14, Body=11, Caption=9. For Modern controls, apply the Classic→Modern size conversion from reference/sizing-reference.md.

• Density: Infer from layout type:

  • Data tables / lists → compact: LayoutGap=8, PaddingH=12, PaddingV=8
  • Forms / record detail views → balanced: LayoutGap=12, PaddingH=16, PaddingV=12
  • Dashboards / landing pages → generous: LayoutGap=16, PaddingH=20, PaddingV=16

• Radius: Pick one value for containers (0=sharp, 4=slight, 6=standard, 8=rounded, 12=soft). Interactive controls get the same value or half — never more. Default: Container=6, Interactive=4.

• State Colors: All derived from Accent-Primary:

  • HoverFill: RGBA(accent_r, accent_g, accent_b, 0.08)
  • PressedFill: RGBA(accent_r, accent_g, accent_b, 0.15)
  • FocusedBorder: Accent-Primary at full opacity
  • DisabledFill: near-background (very low contrast)
  • DisabledColor: Text-Secondary at 0.38 opacity

Fill in the chosen format with values extracted from the screenshot / user answers. Write the result to {OUTPUT_DIR}/temp-design-spec.md.

After writing both files, proceed immediately to Step 2 — do not re-read reference/controls-index.md here (the controls-agent reads it directly).

Step 2: Spawn Parallel Specialty Agents

Read the three agent instruction files from the agents/ subdirectory of this skill:

• agents/layout-sizing-agent.md
• agents/controls-agent.md
• agents/styling-agent.md

Then launch all three agents simultaneously in a single message using the Agent tool. Each agent receives a prompt constructed from its instruction file content plus these specifics:

For each agent, pass:

• The full content of its instruction file (as the task description)
• The absolute path to {OUTPUT_DIR}/temp-skeleton.md
• The absolute path to {OUTPUT_DIR}/temp-design-spec.md
• SKILL_DIR (the skill directory absolute path, for reading reference docs in reference/)
• The control style preference (classic / modern) from the user's Phase 3 answer — pass this explicitly to the controls-agent so it selects the correct variants
• The absolute path to its output file:
  • Layout+Sizing → {OUTPUT_DIR}/temp-layout-annotations.yaml
  • Controls → {OUTPUT_DIR}/temp-controls-annotations.yaml
  • Styling → {OUTPUT_DIR}/temp-styling-annotations.yaml

Wait for all three agents to complete before proceeding to Step 3.