team-planning

name	team-planning
description	Collaborative planning for Dataverse or Azure SQL backed Power Apps Code Apps and Power Pages code sites using runSubagent. Multiple specialists (Data Modeler, UX Designer, Tester, The Critic) debate and refine a no-code implementation plan before build. Falls back to structured single-agent planning if runSubagent is not available. Triggers on "plan my app", "plan with team", "team planning", "planning team", "plan code app", "plan power pages", "plan dataverse app", "plan azure sql app", "design app navigation", "design data model".
user-invocable	true

Plan With Team — Agent Team Planning Skill

You orchestrate a 4-agent planning team that debates and refines an application plan before any code is written. The default planning target is a Power Apps Code App or a Power Pages code site backed by Dataverse, Azure SQL, or both.

The goal is to produce a battle-tested plan where permanent platform decisions, architectural risks, security gaps, edge cases, UX gaps, and testing strategy are challenged and resolved before implementation.

CRITICAL RULES

1. No code is written during planning. The output is a plan document only.
2. The Critic writes NO artifacts. Their only job is to challenge and find flaws.
3. Diagrams first. Every concept, workflow, data model, and user journey MUST be communicated via Mermaid diagrams before or alongside prose. Diagrams are the primary communication tool — text descriptions supplement diagrams, not the other way around. Use renderMermaidDiagram to render them visually. At minimum the plan must include:
   • ERD (erDiagram) for the data model (Data Modeler)
   • User journey flowcharts (flowchart) for each key workflow (UX Designer)
   • Process/status flow (stateDiagram or flowchart) for approval and lifecycle states
   • Data interaction flow showing which screens read/write which entities
   • Navigation map (flowchart) showing screen-to-screen links This is non-negotiable. If an agent's output lacks diagrams, the Lead must reject it and re-invoke the agent with explicit instructions to produce diagrams.
4. Immutable decisions must be captured and approved early. Existing solution reuse, publisher prefix, solution unique name, table logical names, and ownership choices must be explicitly confirmed before downstream design.
5. Every agent must reference the relevant skills. Data Modeler uses dataverse-solution-web-api (Dataverse path) or SQL planning constraints (Azure SQL path), UX Designer uses power-apps-code-apps and/or power-pages and ui-wireframes, and all roles align with ioc-development-pattern for service boundaries.
6. Include low-fidelity HTML wireframes with links between screens. Use the ui-wireframes skill for conventions, templates, and validation. Planning output must include navigable mockups for key flows.
7. The plan must be consolidated by the Lead into a single structured document before presenting to the user for approval.
8. If runSubagent is not available, fall back to single-agent structured planning using the same framework. See the Fallback Planning Mode section below.
9. Schema creation can be parallelized. When implementation starts, reference ../dataverse-solution-web-api/resources/ops-parallelization.md for the dependency graph. Multiple tables can be built simultaneously by separate agents.
10. Persist planning state to disk. Use the shared workflow-state skill (../workflow-state/SKILL.md) and keep state synchronized with manage_todo_list and phase transitions.

The Team

Role	Agent Name	Mandate
Data Modeler	[Power Platform] Data Modeler	Design tables, columns, relationships, option sets, security model
UX/Flow Designer	[Power Platform] UX Designer	Design navigation, routes, screen inventory, wireframes, user journeys
ALM Engineer	[Power Platform] ALM Engineer	Define environment strategy, solution architecture, deployment pipeline, source control, and governance
Tester	[Power Platform] Tester	Produce a comprehensive test plan: unit, integration, browser, usability, large-dataset, edge cases, and mocking strategy
The Critic	[Power Platform] The Critic	Challenge everything. Find security holes, edge cases, ALM issues, performance traps

Workflow

Before Phase 1, load ../workflow-state/SKILL.md, then initialize planning state and keep it synchronized with manage_todo_list.

Phase 1 — Gather Requirements (Lead)

Before spawning the team, the Lead must understand:

• Who uses this app/site? (personas/roles)
• What data does it manage? (entities/relationships)
• What are the key workflows? (create, submit, review, approve, report)
• Where is the data source? (Dataverse, Azure SQL, or hybrid)
• What existing assets already exist? (solution, publisher, tables, app/site, SQL schema)

Ask the user these questions if the prompt is vague. Do NOT delegate to the team until you have enough context to write meaningful runSubagent prompts.

Phase 1b — Determine Build Path

Ask early: "What build path are we planning?"

IMPORTANT — Supported Build Paths Only: This team builds Power Apps Code Apps and Power Pages code sites. Do NOT recommend model-driven apps with PCF components — that is a different development paradigm not covered by this team's skills. If the user describes an internal business app, default to Power Apps Code App. If they describe an external/public site, default to Power Pages code site.

Code Apps ≠ PCF Components. These are completely different technologies:

• Code Apps are standalone React/TypeScript web applications (@microsoft/power-apps SDK). They have their own URL, navigation, and layout. Data access uses connectors and getContext().
• PCF components are reusable controls embedded inside model-driven or canvas app forms. They use the ComponentFramework SDK (context.webAPI, context.parameters) and cannot exist standalone.

Never plan a PCF component when the user wants a standalone app, and vice versa.

Build Path	Key Skills	UX Designer Focus
Power Apps Code App	power-apps-code-apps, ioc-development-pattern, vite-react	React routes, feature modules, service interfaces, query strategy
Power Pages code site	power-pages, ioc-development-pattern, vite-react	Site navigation, public/authenticated routes, web roles, Web API boundaries
Hybrid (Code App + Power Pages)	Above combined	Shared domain model with separate UX surfaces

This decision affects:

• Data Modeler: Dataverse schema and/or Azure SQL contract plan
• UX Designer: Navigation IA + screen inventory + linked low-fi wireframes
• The Critic: Additional checklist items for chosen build path
• Plan template: Wireframe and Mermaid sections are mandatory for all build paths

Include the build path choice in every agent's runSubagent prompt.

Phase 1c — Immutable Decisions Checkpoint

Before design deep-dive, ask and lock decisions that are costly/impossible to change later:

1. Existing solution strategy: Reuse an existing solution or create new?
2. Publisher strategy: Existing publisher or new publisher?
3. Prefix confirmation: What published prefix will be used for all artifacts?
4. Dataverse immutables: Table logical names, ownership types, core data types.
5. Azure SQL immutables: Database/schema naming, key strategy, tenancy partitioning approach.
6. Environment/tenant constraints: Target environments, DLP, auth boundaries.

Record these under "Immutable Decisions" in the consolidated plan and require explicit user confirmation.

Phase 1d — Skill-Aligned Discovery Questions

The Lead must ask a structured questionnaire before delegating to agents via runSubagent:

Business & UX

• What are the top 3 user journeys that must be excellent on day 1?
• Which personas are internal vs external users?
• Do you need anonymous access (Power Pages) or authenticated-only?
• For each list/grid screen: what are the expected record counts, and which columns should be sortable/searchable/filterable? (This drives server-side vs client-side pagination decisions)

Data & Integration

• Is the system of record Dataverse, Azure SQL, or split by domain?
• If Azure SQL is involved, will access be direct API-backed or connector-based (shared_sql)?
• What existing tables/entities should be reused instead of recreated?

Use this table to capture integration dimensions explicitly:

Dimension	What to Capture
Connectors	Which Power Platform connectors are needed? (SharePoint, SQL, HTTP, etc.)
External APIs	REST or SOAP endpoints the app must call
Authentication	OAuth, API key, or certificate requirements for external systems
Data direction	Read-only, write-back, or bidirectional sync
AI Builder	Does the scenario benefit from GPT prompts, document processing, or prediction models?
Environment variables	API base URLs, feature flags, or secrets that change per environment

Server-Side Logic

• Are there operations that require elevated privileges (acting on records the caller can't directly access)?
• Are there multi-record operations that must succeed or fail atomically (transactional)?
• Is there performance-sensitive batch logic that would be too slow as individual client HTTP calls?
• Are there business logic operations that must be reusable across multiple app types (Code App, Power Pages, Power Automate, model-driven)?
• Are there security-sensitive business rules that must be enforced server-side (not bypassable from the client)?
• Are there capacity, inventory, booking, or quota operations where a value is read, checked, and decremented? (e.g., "check places available → create booking → decrement places") These MUST be server-side — client-side read-check-write is a race condition and abuse vector on public sites.
• For Power Pages: which Web API write operations are exposed to anonymous or authenticated external users? For each, confirm whether the client-side operation is safe (simple single-record CRUD) or unsafe (multi-step, stateful, or involving shared counters/capacity). Unsafe operations must use Server Logic or Custom API plugins.

Guidance: If any answer is yes, the Solution Architect should plan Dataverse Custom API plugins for those operations. Reference ../dataverse-solution-web-api/resources/logic-custom-api-plugins.md for implementation details.

ALM & Governance

• Which existing solution (if any) should contain this work?
• What publisher prefix is approved and already in use?
• What environments (Dev/Test/Prod) and deployment gates are required?

Security & Compliance

• Which roles can read/create/update/approve?
• Are there columns requiring elevated protection (financial, PII, legal)?
• Any audit, retention, or regional data residency constraints?

Implementation Readiness

• Do we need an IoC-first delivery (in-memory before real backend)?
• Which skill will own each phase: planning, schema, UI, backend integration, deployment?
• What smoke tests must pass in browser-automation before sign-off?

Phase 2 — Spawn the Team

Use runSubagent to delegate to all three agents with detailed context. Wait for each agent's response before consolidating. Each agent gets:

• The user's requirements (from Phase 1)
• Their role-specific instructions from agents/
• Instructions to load the relevant domain skill

Use runSubagent with agentName "[Power Platform] Data Modeler" and this prompt:
[Read agents/DataModeler.agent.md and include its full content]
[Read skills/team-planning/resources/schema-output-format.md and include as the output format reference]

Use runSubagent with agentName "[Power Platform] UX Designer" and this prompt:
[Read agents/UXDesigner.agent.md and include its full content]
[Read skills/team-planning/resources/ux-output-format.md and include as the output format reference]
[Read skills/ui-wireframes/SKILL.md and include as the wireframe and Mermaid diagram reference]
[Instruct: For every list/grid screen, produce a LIST SCREEN spec with sortable columns,
 default sort, pagination strategy, scroll behavior, empty states, and loading behavior.
 Wireframes must show sort indicators, pagination rows, and scroll areas on list screens.]

Use runSubagent with agentName "[Power Platform] ALM Engineer" and this prompt:
[Read agents/ALMEngineer.agent.md and include its full content]
[Provide the immutable decisions from Phase 1c, discovery answers from Phase 1d, and build-path choice from Phase 1b]
[Instruct: Define the ALM strategy for this project — environment topology, solution architecture,
 deployment pipeline, source control approach, environment variables/connection references,
 and governance controls. Reference the powerplatform-alm skill for best practices.
 Output the ALM Strategy section for the consolidated plan.]

Use runSubagent with agentName "[Power Platform] Tester" and this prompt:
[Read agents/Tester.agent.md and include its full content]
[Read skills/team-planning/resources/test-plan-output-format.md and include as the output format reference]
[Provide the Data Modeler's schema summary and UX Designer's screen inventory as context]
[Instruct: Produce a test plan covering unit tests, integration tests, browser tests (Playwright),
 usability tests (tasks for Usability Engineer), large-dataset scenarios, edge cases, and mocking strategy.
 Reference the ioc-development-pattern skill for mock boundaries.]

Use runSubagent with agentName "[Power Platform] The Critic" and this prompt:
[Read agents/TheCritic.agent.md and include its full content]
[Read skills/team-planning/resources/critic-checklist.md and include as the review checklist]

Phase 3 — Parallel Design (Agents Work)

• Data Modeler designs the schema and returns their proposal via runSubagent response
• UX Designer designs the app structure and creates low-fidelity HTML wireframe files on disk via runSubagent response. Wireframes are not optional — they must be written to docs/wireframes/ as navigable HTML files, not just described in the plan text
• ALM Engineer defines the environment strategy, solution architecture, deployment pipeline, and governance controls
• Tester produces a comprehensive test plan based on the schema and UX proposals
• The Critic reads all proposals (including the ALM strategy and test plan) and challenges them with specific questions

The orchestrator (Lead) passes each agent's output to dependent agents via runSubagent prompts. The Lead monitors and re-invokes agents if issues need resolution.

Phase 4 — Critic Review Round

The Critic performs a structured review using the checklist in resources/critic-checklist.md. They return findings in their response, which the orchestrator passes to all other agents.

Data Modeler, UX Designer, ALM Engineer, and Tester must respond to every finding with either:

• ACCEPTED — change incorporated into their design / test plan / ALM strategy
• REJECTED (reason) — justified pushback

The Critic also specifically challenges the ALM Engineer on:

• Is the environment strategy realistic for the team's size and maturity?
• Is the solution architecture over-segmented or under-segmented?
• Are environment variables defined for all environment-specific config?
• Is the deployment pipeline achievable with available tooling (Power Platform Pipelines, Azure DevOps, GitHub Actions)?
• Is source control strategy defined, and is it the source of truth (not maker environments)?
• Are managed properties and solution layering concerns addressed?
• Is rollback capability planned?

The Critic also specifically challenges the Tester on:

• Are there missing edge cases for any data entity or workflow?
• Is the mocking strategy realistic? Are there subsystems that can't be easily mocked?
• Are the large-dataset scenarios using realistic volume numbers for this domain?
• Are the usability test tasks actually goal-oriented (not step-by-step instructions)?
• Are browser tests covering the right flows, or are they duplicating unit test coverage?

Phase 4 Quality Gate — All Findings Must Be Resolved

After all agents have responded to The Critic's findings, the Lead reviews the resolution status of every finding regardless of severity.

Gate rule: The workflow MUST NOT proceed to Phase 4b or Phase 5 while any finding remains unresolved. A finding is unresolved if:

• The agent has not responded at all
• The agent responded ACCEPTED but the design/plan has not been updated to reflect the change
• The agent responded REJECTED but the justification is weak, vague, or missing evidence

Resolution loop:

1. The Lead lists all unresolved findings grouped by severity with their current status
2. The Lead routes each unresolved finding back to the responsible agent with explicit instructions: "This finding is not fully addressed. Update your proposal or provide a stronger rejection rationale."
3. The Critic re-reviews only the updated responses
4. Repeat until every finding is either:
   • ACCEPTED with the change visibly incorporated into the proposal, OR
   • REJECTED with a specific, evidence-based justification that The Critic acknowledges as reasonable

The Lead must not consolidate the plan with any unresolved findings. This gate is non-negotiable — all severities (Critical, High, Medium, Low) must be fully addressed before proceeding.

Phase 4b — Data Model Review

After the Critic review, run the Data Modeler's schema through the dataverse-data-review skill for an automated 74+ rule assessment.

1. Load the dataverse-data-review skill
2. Feed it the Data Modeler's latest schema proposal
3. The skill produces a structured Overall good: Yes/No assessment with bullet points
4. If No — route findings back to the Data Modeler for revision before consolidation
5. If Yes with suggestions — include suggestions in the plan's "Open Questions" section

This catches naming violations, normalization issues, type mismatches, and Dataverse-specific pitfalls that even experienced architects miss. It complements (not replaces) the Critic's review which focuses on security, UX, ALM, and performance concerns.

Phase 5 — Consolidation (Lead)

Phase 5 Quality Gate — Wireframes Are Mandatory

The Lead MUST NOT present the consolidated plan to the user until low-fidelity HTML wireframes have been created on disk. This is non-negotiable.

Before consolidation, verify:

1. A docs/wireframes/ directory exists with .html files for every screen in the screen inventory
2. All wireframe pages are linked to each other (clickable navigation between screens)
3. Mermaid diagrams have been produced for: ERD, user journey flows, process/status flows, data interaction flows, and navigation map. If any are missing, re-invoke the responsible agent with explicit instructions to produce them
4. Every section of the consolidated plan that describes a workflow, data model, or user journey includes a rendered Mermaid diagram — not just prose

If the UX Designer's output did not include wireframe files, re-invoke the UX Designer via runSubagent with explicit instructions to create them before proceeding. Do not substitute wireframe descriptions in the plan document for actual HTML files — the files must exist and be navigable.

The Lead collects all five agents' final outputs and consolidates into the plan template defined in resources/plan-template.md. Save the consolidated plan to docs/plan.md — all planning deliverables live in the docs/ folder, not .copilot/. The Tester's test plan is included as a dedicated section (Section 15: Test Plan) and the ALM Engineer's strategy is included as a dedicated section (Section 16: ALM Strategy) in the consolidated plan.

As part of consolidation, produce a technology proposal — a list of the platform objects the solution requires. Match each need to the best-fit technology:

Object Type	Description
Model-driven app	Data-first app built on Dataverse forms & views
Code app	React/TypeScript app using @microsoft/power-apps
Power Pages site	External-facing website with Dataverse backend
Custom API plugin	C# server-side logic for transactions, elevated privileges, and reusable cross-app operations (see logic-custom-api-plugins.md)
Power Automate flow	Automated business process or integration
Copilot Studio agent	Conversational agent with knowledge sources
Power BI dashboard	Analytics and reporting
AI Builder prompt	Custom AI model or GPT prompt for intelligent processing

The user can replace, remove, or add technologies before confirming. Existing apps can be attached to the plan rather than creating new ones.

Present the consolidated plan to the user for approval.

Phase 6 — Handoff

Once approved, the plan document serves as the implementation spec. Each section maps directly to implementation workstreams across selected skills (power-apps-code-apps, power-pages, dataverse-solution-web-api, and Azure SQL integration choices).

Parallelization: Consider which implementation steps can run in parallel vs must be sequential. Multiple table/domain agents can create schema + contracts in parallel. Cross-cutting concerns (shared relationships, navigation map, integration boundaries, deployment orchestration) must be handled by the main agent after domain agents complete.

Using Agent Mode in VS Code

GitHub Copilot in VS Code supports agent spawning via the runSubagent tool in Agent Mode.

To enable Agent Mode:

1. Open GitHub Copilot Chat (Ctrl+Alt+I)
2. Select Agent mode from the mode selector dropdown
3. The runSubagent tool will be available automatically

Planning Template

Read resources/plan-template.md for the full consolidated plan template. The Lead uses this template to merge all four agents' outputs into one document.

For persistence and resume behavior, read ../workflow-state/SKILL.md.

Required outputs in the template:

• Immutable decisions and existing-solution strategy
• Skill-aligned discovery answers
• Navigation model for app/site
• Low-fidelity HTML wireframes with links between screens (see ui-wireframes skill)
• Mermaid flowcharts for user, process, and integration flows (see ui-wireframes skill)
• Test plan covering unit, integration, browser, usability, and large-dataset tests (Tester output)
• Build/deploy handoff plan across selected implementation skills

Fallback Planning Mode

Fallback Mode: Single-Agent Structured Planning

Use this when runSubagent is not available or Agent Mode is not enabled. First warn the user and ask if they want to proceed with single-agent planning or switch to Agent Mode for better quality. If they choose to proceed, follow the workflow below.

How It Works

Instead of using runSubagent to delegate to four agents, the Lead performs all four roles sequentially using runSubagent for parallel research where possible.

Workflow

Step 1 — Requirements Gathering

Same as Phase 1 in the team workflow. Ask the user about personas, data, workflows.

Step 2 — Data Architecture Pass

Put on the "Data Modeler" hat. Read agents/DataModeler.agent.md for the output format and domain knowledge references.

Design the full schema: tables, columns, relationships, option sets.

Step 3 — UX Design Pass

Put on the "UX Designer" hat. Read agents/UXDesigner.agent.md for the output format and domain knowledge references.

Design the full experience structure: routes/navigation, key screens, linked wireframes, and user flows. Load the ui-wireframes skill for wireframe HTML conventions and Mermaid diagram patterns. You MUST create the wireframe HTML files on disk in a docs/wireframes/ directory — do not skip this step or substitute with descriptions. Every screen in the inventory must have a corresponding .html file with working links to related screens.

Step 4 — ALM Strategy Pass

Put on the "ALM Engineer" hat. Read agents/ALMEngineer.agent.md for the role definition and skills/powerplatform-alm/SKILL.md for best practices.

Define the ALM strategy: environment topology, solution architecture, deployment pipeline, source control approach, environment variables/connection references, and governance controls.

Step 5 — Critic Review Pass

Put on the "Critic" hat. Read agents/TheCritic.agent.md for the persona and resources/critic-checklist.md for the full review checklist.

Go through EVERY item on the checklist. Document findings. Revise the schema, UX design, ALM strategy, and test plan to address Critical and High findings.

Step 6 — Test Planning Pass

Put on the "Tester" hat. Read agents/Tester.agent.md for the persona and resources/test-plan-output-format.md for the output format.

Using the schema and UX design as inputs, produce a comprehensive test plan covering:

• Unit tests for service layer and components
• Integration tests with mocking strategy
• Browser tests (Playwright) for critical paths and visual validation
• Usability test tasks for the Usability Engineer agent
• Large-dataset and edge-case scenarios
• Quality gates and performance budgets

Step 7 — Consolidation

Merge everything into the plan template from resources/plan-template.md.

Present to user for approval.

Quality Notes

Single-agent planning produces good results but has one weakness compared to agent teams: the same "mind" that designed the schema is reviewing it. Agent teams provide genuinely independent perspectives that catch more blind spots.

To compensate:

• Be extra rigorous on the Critic pass — go through EVERY checklist item
• Consider using runSubagent specifically for the Critic review and Test planning pass, giving it the schema and UX design as input
• Ask the user to review the Critic findings and test plan themselves before finalizing

Suggesting Agent Mode

If the user seems to be planning a complex app (5+ tables, multiple personas, approval workflows) and Agent Mode is not currently active, suggest using it:

"This is a complex app. For better planning quality, you could use Agent Mode by switching to Agent mode in GitHub Copilot Chat (press Ctrl+Alt+I and select 'Agent' from the mode dropdown). This enables the runSubagent tool, which lets four independent AI specialists debate the design before implementation."

Prompt Guidance for Vague Descriptions

When the user's problem description is vague, use these patterns to extract better requirements.

Seed Prompt Pattern

Ask the user to fill in this template:

"[Role] needs a way to [primary action] involving [key entities].
The process requires [business rules or approval steps].
[Additional roles] need [their specific views or capabilities]."

Reference existing paper forms, spreadsheets, or legacy app screenshots for richer context.

Refinement Prompts

During review, guide the user with:

"Add a requirement for [role] to [capability]."
"Remove the [table] — that data already lives in [existing system]."
"Split [broad requirement] into separate needs for [role A] and [role B]."

Technology Adjustment Prompts

During the technology proposal review:

"Use a code app for [workflow] — we need custom UI."
"Add a Power Automate flow to notify [role] when [event] occurs."
"Include a Power BI dashboard for [reporting need]."

---

Solution Archetypes

Common solution patterns that pair a primary app with supporting platform services. Use these to guide the technology proposal during Phase 5.

Operational Hub

Stack: Primary app + Dataverse + Power Automate flows Pattern: Rich record-management — searchable lists, detail forms, inline editing, bulk actions — with automated background processes (assignment rules, SLA escalations, status transitions). When: Standard model-driven forms feel too rigid, or the UX needs custom layouts, drag-and-drop, or multi-record operations.

Approval & Workflow Manager

Stack: Primary app + Power Automate flows + Copilot Studio agent Pattern: A submission form feeds into a multi-stage approval pipeline with visual status tracking, delegation, and escalation. A conversational agent handles status inquiries and nudges approvers. When: Requests pass through structured review stages with role-based routing, SLA monitoring, and audit trails.

Interactive Dashboard

Stack: Primary app + Dataverse (aggregated views) + Power BI embedded Pattern: KPI cards, trend charts, filterable grids, and drill-through panels. Power BI handles heavy analytical queries while the app provides interactive filtering, cross-highlighting, and contextual actions. When: Users need to both visualize data and act on it in the same surface.

Guided Data Capture

Stack: Primary app + Dataverse + Power Automate flow Pattern: A multi-step wizard for complex data entry with per-step validation, conditional branching, interim draft persistence, and a confirmation summary before final submission. A flow handles post-submission processing. When: The data model is complex (parent record with multiple child collections) and the entry process benefits from a structured, step-by-step experience.

Portal with Back Office

Stack: Internal app + Power Pages (external) + Power Automate flows Pattern: External users interact through a Power Pages site for self-service submissions and status checks. Internal staff manage, review, and process those submissions in a richer internal app. When: Both public-facing access and an internal operations interface are needed, sharing the same Dataverse backend.

AI-Assisted Experience

Stack: Primary app + AI Builder prompts + Dataverse + Power Automate flow Pattern: The app integrates AI Builder custom prompts for intelligent features — summarizing records, classifying requests, extracting data from documents, or generating draft responses. Flows orchestrate heavier AI workloads asynchronously. When: The app's core value depends on AI capabilities — smart triage, content generation, document processing, or natural-language search.

---

Planning Specialist Roles

The planning team uses agent definition files from agents/. When spawning each agent (or adopting their role in fallback mode), read the corresponding agent file for the full role definition, output format, domain knowledge references, communication protocol, and checklists.

Role	Agent File	Key Skills to Load
Data Modeler	DataModeler.agent.md	dataverse-solution-web-api (Dataverse path), power-apps-code-apps (Azure SQL path constraints)
UX/Flow Designer	UXDesigner.agent.md	power-apps-code-apps (Code App), power-pages (Power Pages), ioc-development-pattern, ui-wireframes
ALM Engineer	ALMEngineer.agent.md	powerplatform-alm
The Critic	TheCritic.agent.md + resources/critic-checklist.md	(reviews only — no skills needed)

Note: If the discovery questions in Phase 1d identify server-side logic needs (elevated privileges, transactions, reusable cross-app operations), the Lead should use runSubagent to delegate to the Solution Architect agent to design the Custom API surface. The Solution Architect references ../dataverse-solution-web-api/resources/logic-custom-api-plugins.md for implementation patterns and produces a server-side logic section in the architecture document.

When using runSubagent to delegate to agents, include the full content of their agent file in the prompt, along with the user's requirements from Phase 1, immutable decisions from Phase 1c, discovery answers from Phase 1d, and build-path context from Phase 1b.

In fallback mode, read each agent file before performing that role's pass.