---

name: canvas-app version: 3.1.0 description: Creates or edits a Power Apps Canvas App through the Canvas Authoring MCP coauthoring session. Handles new app generation, direct targeted edits, complex multi-screen changes, responsive layout, per-screen self-QA, and compile-error convergence. Trigger on requests to create, build, generate, modify, update, change, fix, or edit a Canvas App or .pa.yaml files. author: Microsoft Corporation user-invocable: true allowed-tools: Read, Write, Edit, apply_patch, Bash, AskUserQuestion, Task, TaskCreate, TaskUpdate, TaskList, EnterPlanMode, ExitPlanMode, mcp__canvas-authoring__sync_canvas, mcp__canvas-authoring__compile_canvas, mcp__canvas-authoring__list_controls, mcp__canvas-authoring__describe_control, mcp__canvas-authoring__list_apis, mcp__canvas-authoring__describe_api, mcp__canvas-authoring__list_data_sources, mcp__canvas-authoring__get_data_source_schema

---

Create or Edit a Canvas App

Create or edit a Power Apps canvas app for:

$ARGUMENTS

Establish the Workspace

Canvas Authoring tools operate on a local directory containing the app YAML.

1. Treat ${PLUGIN_ROOT} as immutable runtime provenance. Never derive it from the current directory, app workspace, repository root, or a sibling worktree.
2. Read ${PLUGIN_ROOT}/references/QAChecks.md and require QACHK-SHARED-SOURCE-DERIVATION. If the check fails, stop with the observed path; do not mix prompt generations.
3. Reuse the current directory when it already contains App.pa.yaml and every existing file in that directory is a .pa.yaml file.
4. Otherwise, reuse the single immediate child directory containing App.pa.yaml, when exactly one exists and every existing file in it is a .pa.yaml file.
5. Otherwise, derive a short kebab-case folder name from the app name or requirements, create a new empty directory with Bash, and resolve its absolute path. If that name already exists and contains non-YAML files, choose a fresh suffixed name rather than synchronizing into it.
6. Call sync_canvas with that absolute working directory before reading or editing app files. The directory must be dedicated to this app and contain no non-.pa.yaml files when synchronization starts; never pass the repository root or ${PLUGIN_ROOT}. Do not call sync_canvas against the working directory again after planning or acceptance documents have been created there. Do not proceed if the initial sync fails.

Always use absolute paths for app files.

Route the Request

Inspect the synced .pa.yaml files before choosing a workflow. A blank app normally contains App.pa.yaml, Screen1.pa.yaml, and _EditorState.pa.yaml.

Treat the app as empty when it has no screens with meaningful leaf controls. Containers without leaf controls do not make the app non-empty.

• Empty app: read ${PLUGIN_ROOT}/references/CreateWorkflow.md and follow it.
• Existing app: read ${PLUGIN_ROOT}/references/EditWorkflow.md and follow it.

Do not load both workflow documents.

Planned Build Handoff

CREATE and complex EDIT workflows return here after the planner finishes.

1. Read the orchestrator-authored [working directory]/canvas-app-requirements.md and [working directory]/canvas-app-plan.md returned by the planner. The requirements artifact must already exist before planner delegation, use contract version 1, preserve the original request, identify the target device, and assign stable requirement, action, scenario, and specialized-contract mappings. Do not let the planner create, rewrite, or replace this upstream artifact.
2. Verify ## Original Request Capability Inventory was captured from the original request before planner reduction. Every stable key must appear in ## Requirement Coverage and map to existing Action Contract key(s), named observer(s), and Functional Test Matrix scenario key(s). Reject dropped clauses and unknown mappings; do not add universal CRUD absent from the request.
3. Verify its ## Requirement Coverage table maps every concrete requested noun and interaction to a visible affordance. Any approximation must be explicit and must not use UI copy that claims the unavailable interaction is exact.
4. When the app contains record cards, rows, lists, or details, verify its ## Required Record Fields table has one stable key for the canonical identity and every field the requirements say users must see. Reject a time-only, identity-only, or action-only surface when additional title, person, time, description, status, or other values are requested.
5. Verify its ## Action Contracts table:
   • Every requested or approved action has its own row and reachable entry point.
   • Create, edit, delete, search, filter, approve, reject, period, and export behaviors are not collapsed into vague combined rows.
   • When review distinguishes approved and rejected outcomes, Approve and Reject/Decline have separate contracts owned by the same eligible record surface.
   • Opposing transitions such as Receive/Issue, Increase/Decrease, Credit/Debit, Allocate/Release, Check-in/Check-out, and Enable/Disable have separate contracts even when one shared form implements both.
   • When opposing actions use a shared-operation flow — directional selector events commit operation state and a distinct guarded event consumes that state to mutate — each selector is selection-only and that distinct event is the single mutation entry point, regardless of control name or label. Both contracts name that same mutation event and operation state. A selector that calls Patch, SubmitForm, Collect, Remove, RemoveIf, UpdateIf, or a connector mutation is invalid. Separate direct-action controls remain valid when no distinct shared mutation event exists and each action has its own selected-ID and amount eligibility gates. Their control identity commits direction, so they need no shared operation variable/reset.
   • Every mutation names an observable bound result, not only a confirmation message.
   • Every mutation declares a write set and receipt proof set. For create/edit, reject the plan when any user-entered or user-selected write-set field is absent from the proof set.
   • Every mutation has an additive lifecycle row naming its receipt, canonical source, requested destination, same stable ID, and exact synchronization/focus behavior when the destination differs or contains multiple records.
   • Every mutation has a Changed/Preserved field ledger. Changed rows match handler writes and receipt proofs one-for-one; Preserved rows retain canonical pre-state and name post-state evidence.
   • Conditional stable-ID continuation exists only when create feeds a later edit, delete, relationship, approval, or transition. It binds that action to the returned create ID and clears continuation state on downstream completion or cancellation.
   • Every plan-declared state-driven UI surface names the surface control and its exact state predicate. Recognize either the dedicated table or an exact Surface.Visible=state predicate Action Contract observer. Do not add rows for always-visible surfaces, child-only visibility, navigation-based disclosure, or visibility not declared by the plan.
   • Supporting setup actions exist when required to exercise an explicitly requested lifecycle, relationship, comparison, or ranking.
   • Role-scoped management of all primary records includes separate visible select/edit/save and remove/cancel paths, not only review or status controls.
   • Create/edit contracts define required inputs, directly selectable finite choices, stable identity, edit prepopulation, cancel/reset behavior, and post-save evidence.
   • Every row names a precondition, source and stable identity, exact transition and postcondition, observer reading that source, and visible evidence.
6. Verify its ## Functional Test Matrix:
   • Every Action Contract has at least one deterministic Given/When/Then success row.
   • Every required invalid, blocked, empty, clear/reset, or boundary path has a row.
   • Every direction of an opposing pair has its own concrete scenario with explicit old value/state, selected operation, amount when applicable, and expected new value/state.
   • Every Then names a source postcondition and an evidence surface that reads it.
   • Local/mock scenarios use concrete seeded IDs and values. Filter scenarios include at least two matching records and one non-matching record.
   • EDIT scenarios cover existing behavior touched by changed sources, fields, controls, or observer formulas.
   • When a continuation contract is present, scenarios cover the returned-ID-bound downstream completion and non-mutating cancellation paths, including continuation-state clear.
7. When the plan contains an opposing directional pair, require ## Directional Mutation Evidence before dispatch. It must state a nullable selected-ID state with blank reset and row assignment, the actual operation state with an entry/success Blank() reset event, representable blank/non-positive amount bindings, a disabled invalid submission gate, exact final formulas for both directions, a canonical-source observer, and receipt bindings for operation, old value, amount, expected value, and actual persisted value. For a shared-operation flow, the plan must also identify each selection-only binding, the common guarded mutation event, and their common operation state.
8. Verify every responsive or unknown-device screen has a ## Viewport Containment Contracts row naming one sole top-level AutoLayout root with exact Width: =Parent.Width and Height: =Parent.Height. All visible and conditional surfaces must be nested below it.
9. When requested behavior orders or compares time-of-day values, require ## Temporal Ordering Contracts. Sort typed Date/Time fields directly, or require validated input normalization to a zero-padded 24-hour HH:mm sort key with explicit invalid/blank behavior. Reject direct sorting of 12-hour, non-padded, or mixed display strings.
10. Verify its ## Dispatch table:
    • Every row has Action, Screen, Target File, YAML Key, Name Prefix, and Screen Brief.
    • CREATE rows use Create; EDIT rows use Modify or Create.
    • Target files and screen briefs are absolute paths under [working directory].
    • No two rows target the same file.
    • No two rows share a Name Prefix.
    • In CREATE mode the first row targets [working directory]/Screen1.pa.yaml with YAML key Screen1.
    • ## Editor State Changes exists and contains exact final order lists or None.
11. Confirm [working directory]/canvas-app-shared.md and every dispatch row's Screen Brief exists. Verify each brief's assignment matches its dispatch row and includes every Action Contract owned by that screen under ## Required Actions and every scenario it exercises under ## Functional Test Scenarios. It also includes every ## Required Record Fields row owned by that screen with an exact bound control, formula, hierarchy, visibility rule, and layout budget.
12. Before dispatch, read every brief and reject it when:
    • a used control lacks its exact creation keywords, supported input-property names, or the full Enum name: and compile-ready enum literal required by discovery;
    • a Required Action is only an identifier or summary instead of its complete precondition, event, source/stable identity, postcondition, observer, and evidence;
    • a Functional Test Scenario is only an identifier instead of complete Given/When/Then text, boundary conditions, and expected evidence; or
    • it contains an unreso