Add wizard input experience for canvas app generation (#110)

Author: shivanichander

plugins/canvas-apps/agents/canvas-app-planner.md

@@ -34,6 +34,7 @@ each screen in parallel without needing to call MCP tools themselves.
 You will be invoked by the `generate-canvas-app` skill with a prompt that includes:
 
 - The user's app requirements (`$ARGUMENTS`)
+- User preferences collected by the skill's wizard (target users, aesthetic direction, features, reference image observations)
 - The working directory where `.pa.yaml` files should be written
 - The plugin root directory (`${CLAUDE_PLUGIN_ROOT}`), from which you must read `references/TechnicalGuide.md` and `references/DesignGuide.md`
 
@@ -76,12 +77,13 @@ Call `TaskCreate` once per task:
 
 ## Step 4 — Design and Present Plan for Approval
 
-Based on discovery and the user's requirements, reason through:
+Based on discovery, the user preferences passed in the prompt, and the user's requirements, reason through:
 
 - How many screens are needed and what each does
 - Which controls will drive each screen's layout
 - What aesthetic direction fits the app's purpose
 - How data will flow (data sources, collections, or mock data)
+- **Layout strategy** — default to **AutoLayout** (responsive) using `GroupContainer` with `Variant: Horizontal` or `Variant: Vertical`. Only use ManualLayout if the user explicitly requests pixel-perfect positioning or the app is a fixed-size desktop dashboard. Mobile and cross-device apps MUST use AutoLayout.
 
 Enter plan mode (`EnterPlanMode`) and present the following to the user:
 
@@ -234,7 +236,7 @@ App file written: [working directory]/App.pa.yaml
 
 ## Critical Constraints
 
-- **Do NOT ask questions.** The one user interaction is the plan mode approval in Step 4.
+- **Do NOT ask questions.** The one user interaction is the plan mode approval in Step 4. User preferences are passed to you in the prompt — do not re-ask them.
 - **Do NOT write any screen `.pa.yaml` files.** Screen builders own all screen-level files.
 - **Do NOT call `compile_canvas` or instruct any other agent to call it.** Compilation/validation is performed exclusively by the orchestrating `generate-canvas-app` skill after all screens have been generated.
 - **Embed full `describe_control` output** in the plan document — never summarize property names.

plugins/canvas-apps/skills/generate-canvas-app/SKILL.md

@@ -4,7 +4,7 @@ version: 2.0.0
 description: Generate a complete, visually distinctive Power Apps canvas app with YAML. USE WHEN the user wants to create, build, or generate a Canvas App or pa.yaml files.
 author: Microsoft Corporation
 user-invocable: true
-allowed-tools: Read, Write, Edit, Bash, Task, TaskCreate, TaskUpdate, TaskList, mcp__canvas-authoring__compile_canvas
+allowed-tools: Read, Write, Edit, Bash, AskUserQuestion, Task, TaskCreate, TaskUpdate, TaskList, mcp__canvas-authoring__compile_canvas
 ---
 
 # Generate a Canvas App
@@ -40,13 +40,52 @@ Pass this absolute path as the working directory in every agent prompt below.
 
 ---
 
-## Phase 1 — Plan
+## Phase 1 — Gather Preferences (Wizard)
+
+Before invoking the planner, 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 2.
+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.
+
+**Layout strategy rule of thumb:** Default to **AutoLayout** (responsive) unless the user explicitly chose desktop-only or requested pixel-perfect positioning. AutoLayout uses `GroupContainer` with `Variant: Horizontal` or `Variant: Vertical` and `LayoutDirection`, which adapts to different screen sizes. ManualLayout uses fixed `X`/`Y`/`Width`/`Height` values that do not reflow.
+
+---
+
+## Phase 2 — Plan
 
 Invoke the `canvas-app-planner` agent using the `Task` tool.
 
 Pass a prompt that includes:
 
 - The user's requirements: `$ARGUMENTS`
+- The wizard answers collected in Phase 1 (target users & device, aesthetic direction, features, and any screenshot observations)
 - The working directory (the absolute path resolved in Phase 0)
 - The plugin root path: `${CLAUDE_PLUGIN_ROOT}`
 
@@ -56,19 +95,25 @@ Example prompt:
 >
 > [paste $ARGUMENTS here]
 >
+> User preferences (from wizard):
+> - Target users & device: [answer or "not specified" — e.g., "Front desk staff on desktop/tablet"]
+> - Aesthetic direction: [answer or "not specified"]
+> - Features: [answer or "not specified"]
+> - Reference image: [observations from screenshot, or "none provided"]
+>
 > Working directory: [absolute path from Phase 0]
 > Plugin root: ${CLAUDE_PLUGIN_ROOT}
 >
 > Follow the instructions in your agent file. Write canvas-app-plan.md and App.pa.yaml to
 > the working directory. Return the screen list and plan document path when complete.
 
 **Wait for the planner to finish.** The planner will present the screen plan to the user via
-plan mode and wait for approval before returning. Do not proceed to Phase 2 until the planner
+plan mode and wait for approval before returning. Do not proceed to Phase 3 until the planner
 task completes successfully.
 
 ---
 
-## Phase 2 — Build
+## Phase 3 — Build
 
 After the planner completes, read `canvas-app-plan.md` from the working directory.
 
@@ -100,12 +145,12 @@ Wait for all screen-builder tasks to complete before proceeding.
 
 ---
 
-## Phase 3 — Validate and Fix
+## Phase 4 — Validate and Fix
 
 After all screen-builders have finished writing their files, call `compile_canvas` on the
 working directory.
 
-**On success:** Proceed to Phase 4.
+**On success:** Proceed to Phase 5.
 
 **On failure:** Read every error in the output. Errors will reference specific files and
 line numbers. For each error:
@@ -121,7 +166,7 @@ Track how many `compile_canvas` passes were needed.
 
 ---
 
-## Phase 4 — Summary
+## Phase 5 — Summary
 
 Delete `canvas-app-plan.md` from the working directory using `Bash`:
 `rm <working-directory>/canvas-app-plan.md`