Team Planning

> Model note: This skill is written to be model-agnostic. Wherever it says > "delegate to the ` subagent," do this with whichever delegation > mechanism your host agent provides — the Agent tool and a named subagent in > agents/.md in Claude Code, or a spawned custom agent defined in > .codex/agents/.toml in Codex. See docs/MODEL-COMPATIBILITY.md` > at the repo root for the full mapping table.

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. Render every diagram as a fenced `mermaid code block directly in the response (both Claude Code and Codex render these inline; no special tool call is needed). 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.

1. 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.

1. 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.

1. 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.

1. The plan must be consolidated by the Lead into a single structured document before

presenting to the user for approval.

1. If subagent delegation is not available, fall back to single-agent structured planning

using the same framework. See the Fallback Planning Mode section below.

1. 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.

1. Persist planning state to disk. Use the shared workflow-state skill (../workflow-state/SKILL.md) and keep state synchronized with your todo list and phase transitions.

The Team

| Role | Agent Slug | Mandate | |---|---|---| | Data Modeler | data-modeler | Design tables, columns, relationships, option sets, security model | | UX/Flow Designer | ux-designer | Design navigation, routes, screen inventory, wireframes, user journeys | | ALM Engineer | alm-engineer | Define environment strategy, solution architecture, deployment pipeline, source control, and governance | | Tester | tester | Produce a comprehensive test plan: unit, integration, browser, usability, large-dataset, edge cases, and mocking strategy | | The Critic | 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 your 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 delegation 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 delegation 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:

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

Delegate to all four specialist subagents 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 (already baked into their agent definition —

agents/data-modeler.md / .codex/agents/data-modeler.toml, etc.)

• Instructions to load the relevant domain skill

Delegate to the `data-modeler` subagent with this prompt:
[Read skills/team-planning/resources/schema-output-format.md and include as the output format reference]

Delegate to the `ux-designer` subagent with this prompt:
[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.]

Delegate to the `alm-engineer` subagent with this prompt:
[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.]

Delegate to the `tester` subagent with this prompt:
[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.]

Delegate to the `the-critic` subagent with this prompt:
[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 in their subagent response
• UX Designer designs the app structure and creates low-fidelity HTML wireframe files on disk as part of their subagent 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 their delegation 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 usabili

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: RyanMakesAndBreaksStuff
• Source: RyanMakesAndBreaksStuff/Custom-Codex-Claude-Plugins-and-Skills
• License: MIT

Install and usage instructions live in the source repository linked above.