toluvictor/canvas-apps-tools/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: