---
name: project-standup
description: Build a Dataverse Model-Driven App end-to-end from any input — specs, plans, ADO items, or SharePoint docs. Use for ALL Dataverse app builds, plan execution, and project standups.
argument-hint: "[project-name] [path-filter] [optional: --ado-project NAME] [optional: --environment-url URL] [optional: --skip-to PHASE]"
---

# Project Standup Pipeline

Stand up a complete Dataverse Model-Driven App project from source documentation through to a working app with full ADO backlog traceability.

## Arguments

- `$ARGUMENTS[0]` — Project name (e.g., `SBA Cash App`, `ClientX Portal`). Used for directory naming and solution naming.
- `$ARGUMENTS[1]` — Path filter for documents in AI Search index (e.g., `/SBA_Demo/`, `/ClientX/Requirements/`)
- `--ado-project NAME` — ADO project name (default: `ADO MCP Demo`)
- `--environment-url URL` — Target Dataverse environment URL (default: `https://org209ecb48.crm.dynamics.com`)
- `--publisher-prefix PREFIX` — Publisher prefix for schema names (e.g., `mcpd`, `clx`)
- `--skip-to PHASE` — Resume from a specific phase (e.g., `--skip-to 3` to start at ADO creation)
- `--dry-run` — Plan and review only, no creation actions

## Pipeline Overview

```
Phase 0: INITIALIZE        → Create working directory, gather inputs, validate access
Phase 1: EXTRACT            → Scan documents, extract all requirements (→ /extract-requirements)
Phase 2: ARCHITECT          → Architecture review team validates & refines (→ /architect-app)
Phase 3: CREATE ADO         → Build ADO backlog from architecture spec (→ /create-ado-work-items)
Phase 4: BUILD APP          → Execute Dataverse operations per ADO stories (→ /build-dataverse-app)
Phase 5: BUILD FLOWS        → Create Power Automate flows per ADO stories (→ /build-power-automate-flows)
Phase 6: BUILD EXTENDED     → Plugins, web resources, PCFs, BPFs, Power Pages (→ domain skills)
Phase 7: VERIFY & CLOSE     → Validate deployment, close remaining ADO items, generate report
```

Each phase writes output files that the next phase reads. This file-based handoff pattern avoids context window limits and enables parallel processing.

### Superpowers Plugin Integration — Consolidated Design Session

The `superpowers` plugin is used for **brainstorming and planning only** — NEVER for plan execution (see Skill Routing Rules in CLAUDE.md).

**Consolidated Design Session (One Brainstorm, All Visual Decisions):**

Before building anything, run a SINGLE `superpowers:brainstorming` session that covers ALL visual/UI/design decisions together. Do NOT scatter brainstorming across phases — the user should not be interrupted mid-build for design input. One upfront session, then uninterrupted execution.

The design session should cover all of the following in one sitting:

| Topic | What to decide |
|---|---|
| **Form Layouts** | Multi-tab form arrangements, field placement, header fields, which forms get complex treatment vs simple, subgrid placement |
| **Dashboard/App Home** | Chart types, KPI card arrangements, view selections, color themes |
| **PCF Controls** | Visual design for each custom control — colors, grid styling, interaction model, chart types, hover effects |
| **Web Resource UX** | Color coding schemes (e.g., expiry date colors), notification banner styles, conditional visibility behavior |
| **Power Pages** | Page layouts, navigation flow, branding/theme, card designs, form wizard UX, color palette, typography |
| **Ribbon Commands** | Button labels, icons, placement, confirmation dialog wording |

The design session produces a consolidated visual spec that all downstream build phases reference. Pattern: **one brainstorm → approve all designs → build everything**.

**When to skip the design session entirely:**
- Skip if the input spec/plan already includes detailed visual mockups, color palettes, CSS themes, wireframes, or explicit layout instructions for all UI components
- Skip for schema-only or backend-only work (tables, relationships, security, flows, plugins with no UI component)

**When to run the design session:**
- ALWAYS run when the spec describes *what* to build but not *how it should look* — e.g., "Risk Matrix Heatmap PCF" without colors/styling, or "5 Power Pages" without layout mockups
- ALWAYS run when the project includes both MDA forms AND Power Pages — the visual language should be consistent across both
- Ask the user: "The spec describes several UI components (forms, PCF controls, Power Pages). Want to run a quick design session to align on look and feel before I start building, or should I use my best judgment?"

---

## File Handoff Convention

All pipeline artifacts live in `./project-runs/{project-slug}/`:

```
project-runs/{project-slug}/
├── status.json                      ← Pipeline state tracking (Phase 0+)
├── _plan.json                       ← Document batch plan (Phase 1)
├── batch-001.json ... batch-NNN.json← Raw extracted requirements (Phase 1)
├── _hierarchy_plan.json             ← Deduplicated hierarchy (Phase 1 consolidation)
├── _review_data_architect.json      ← Data architecture review (Phase 2)
├── _review_field_matrix.json        ← Field matrix review (Phase 2)
├── _review_forms_ux.json            ← Forms & UX review (Phase 2)
├── _review_security.json            ← Security architecture review (Phase 2)
├── build-specification.json         ← Final merged build spec (Phase 2)
├── field-matrix.md                  ← Human-readable field matrix (Phase 2)
├── formatted/                       ← HTML-formatted ADO stories (Phase 2→3)
│   ├── scaffold-epics.json
│   ├── {epic-slug}.json ...
├── ado-work-items.json              ← ADO work item ID mapping (Phase 3)
├── build-log.json                   ← Dataverse build action log (Phase 4-5)
└── standup-report.md                ← Final verification report (Phase 6)
```

### status.json Schema

```json
{
  "project_name": "SBA Cash App",
  "project_slug": "sba-cash-app",
  "created_at": "ISO timestamp",
  "ado_project": "ADO MCP Demo",
  "environment_url": "https://org209ecb48.crm.dynamics.com",
  "tenant_id": "c1cedd73-d687-4c40-89f5-7fbbb48a8af3",
  "publisher_prefix": "mcpd",
  "solution_name": "SBACashApp",
  "path_filter": "/SBA_Demo/",
  "phases": {
    "0_initialize": { "status": "completed", "completed_at": "ISO" },
    "1_extract": { "status": "completed", "completed_at": "ISO", "doc_count": 5, "req_count": 198 },
    "2_architect": { "status": "in_progress", "started_at": "ISO" },
    "3_create_ado": { "status": "pending" },
    "4_build_app": { "status": "pending" },
    "5_build_flows": { "status": "pending" },
    "6_build_extended": { "status": "pending" },
    "7_verify": { "status": "pending" }
  }
}
```

Update `status.json` at the start and end of each phase. This enables `--skip-to` resume capability.

---

## Phase 0: INITIALIZE

**Goal:** Set up the working directory, validate access, gather configuration.

1. **Create project directory:** `./project-runs/{project-slug}/`
   - Slugify project name: lowercase, spaces to hyphens, strip special chars
2. **Validate access:**
   - `dataverse_test_connection` to target environment
   - `search_get_index_stats` to confirm AI Search index is accessible
   - Verify ADO project exists via `wit_query_work_items` (simple test query)
3. **Detect process template:** Query ADO to determine Scrum (PBI) vs Agile (User Story)
4. **Gather publisher info:** `dataverse_list_publishers` to find/confirm publisher prefix
5. **Write `status.json`** with all configuration captured
6. **Show configuration summary to user** and confirm before proceeding

---

## Phase 1: EXTRACT REQUIREMENTS

**Goal:** Scan indexed documents and extract all requirements with source traceability.

**Delegate to:** `.claude/skills/extract-requirements/SKILL.md`

Invoke the extract-requirements skill with the path filter. The skill handles:
- Phase 1: Scan & plan document batches
- Phase 2: Parallel extraction subagents
- Phase 3 Pass 1: Deduplication & hierarchy plan
- Phase 3 Pass 1.5: App Architect + Database Architect review (lightweight pre-review)

**Source traceability enhancement:** Every extracted requirement MUST include:
```json
{
  "source_doc": "Requirements.docx",
  "source_url": "https://sharepoint.com/.../Requirements.docx",
  "snippet_range": "snippets 12-15 of 38"
}
```

These fields propagate through all downstream phases and appear as footers on ADO work items.

**Output:** `_hierarchy_plan.json` with deduplicated, cross-referenced requirements

**Decision gate:** Review hierarchy summary with user before proceeding to Phase 2.

---

## Phase 2: ARCHITECTURE REVIEW

**Goal:** Apply Dataverse domain expertise to validate and refine the requirements into a buildable specification.

**Delegate to:** `.claude/skills/architect-app/SKILL.md`

This phase spawns a team of specialist agents that review the hierarchy plan through different lenses simultaneously. The output is a comprehensive `build-specification.json` that precisely defines every Dataverse artifact to create.

Key responsibilities:
- Filter out OOB entities (Contact, Account, etc.) — no table creation PBIs for standard entities
- Identify custom fields on OOB entities — these DO get PBIs
- Validate field types, sizes, option sets against Dataverse best practices
- Design form layouts with proper tabs/sections/subgrids
- Define security role matrix
- Produce human-reviewable field matrix
- Resolve cross-entity dependencies

**Output:** `build-specification.json` + `field-matrix.md`

**Decision gate:** RECOMMENDED — Review build spec + field matrix with user before Phase 3. This is the last checkpoint before ADO work items are created.

---

## Phase 3: CREATE ADO WORK ITEMS

**Goal:** Create a structured ADO backlog from the architecture specification.

**Delegate to:** `.claude/skills/create-ado-work-items/SKILL.md`

**Input:** `build-specification.json` from Phase 2 (NOT raw requirements from Phase 1)

The skill creates:
1. **Standard scaffold** — 5 mandatory Epics with Features (Infrastructure, Security, Documentation, Templates, Enhancements)
2. **Custom Epics/Features** — Per functional areas from the build spec
3. **PBIs/User Stories** — Using PBI templates from `pbi-templates.md`, populated with exact schema details from the build spec

**Source reference footers** on every PBI description:
```html
<hr/><em>Source: Requirements.docx (snippets 12-15) | <a href="URL">Original Document</a></em>
```

**Story formatting phase:** After the hierarchy is created, spawn parallel formatting agents (one per Epic group) to generate full HTML descriptions and acceptance criteria using the PBI templates. Each story includes the specific field types, option values, relationship targets, form layouts, etc. from the build specification.

**Output:** `ado-work-items.json` — mapping of every created work item with `{ id, title, type, state, epic, feature, category }`

---

## Phase 4: BUILD DATAVERSE APP

**Goal:** Execute Dataverse operations per ADO stories with full traceability.

**Delegate to:** `.claude/skills/build-dataverse-app/SKILL.md`

**Input:** `ado-work-items.json` + `build-specification.json`

**Tandem execution pattern** — every Dataverse action ties back to an ADO PBI:

```
For each dependency tier:
  1. Read ADO PBIs for this tier from ado-work-items.json
  2. For each PBI: wit_get_work_item → read Implementation Details
  3. Update PBI state: wit_update_work_item → "Active"
  4. Execute Dataverse MCP operations (batch where possible)
  5. Update PBI state: wit_update_work_item → "Closed"
  6. Add completion comment: wit_add_work_item_comment
  7. Update ado-work-items.json with new state
  8. Append to build-log.json
```

**Dependency tiers (execution order):**

| Tier | Operations | Can Batch? |
|------|-----------|------------|
| 1 | Create solution, publisher validation | No |
| 2 | Create tables (all at once) | Yes — `bulk_create_tables` |
| 3 | Create columns, relationships | Yes — `bulk_create_columns` per table |
| 4 | Create views | Parallel per table |
| 5 | Build forms | Parallel per table |
| 6 | Create security roles + privileges | Parallel per role |
| 7 | Create/update app, sitemap | No |
| 8 | Publish all | No |

**Parallel subagent strategy for large projects (50+ stories):**
- Tiers 2-3: Single agent (batch tools handle volume)
- Tiers 4-5: Parallel agents per table group (views agent, forms agent)
- Tier 6: Parallel agents per security role

**Output:** Updated `ado-work-items.json` (states), `build-log.json` (action log)

---

## Phase 5: BUILD FLOWS

**Goal:** Create Power Automate cloud flows per ADO stories.

**Delegate to:** `.claude/skills/build-power-automate-flows/SKILL.md`

**Input:** Flow-related PBIs from `ado-work-items.json` + `build-specification.json`

Same tandem execution pattern as Phase 4:
1. Filter `ado-work-items.json` for flow/automation PBIs
2. For each: read ADO story → match template → create flow → activate → update ADO
3. Discover connection references first (`dataverse_list_connection_references`)

**Output:** Updated `ado-work-items.json`, appended `build-log.json`

---

## Phase 6: BUILD EXTENDED

**Goal:** Build all remaining components that require specialized skills — plugins, web resources, PCF controls, BPFs, and Power Pages.

This phase handles everything that `/build-dataverse-app` (Phase 4) and `/build-power-automate-flows` (Phase 5) do not cover. Execute in this order (each step depends on the prior):

### Step 6a: Plugins (if spec requires server-side logic)

**Delegate to:** `.claude/skills/build-plugins/SKILL.md`

For each plugin requirement in the build spec or ADO stories:
1. Invoke `/build-plugins` — it handles scaffolding, C# code generation, build, assembly registration, and step configuration
2. **Mandatory smoke test:** After registration, create a test record on the trigger table to verify the plugin fires correctly and produces expected results. Delete the test record. Metadata-only verification (step exists) is NOT sufficient — runtime errors (InvalidProgramException, sandbox verification failures) only surface when the plugin actually executes.
3. Update ADO story state

### Step 6b: Web Resources (if spec requires JS form scripts)

**Delegate to:** `.claude/skills/build-web-resources/SKILL.md`

For each web resource requirement:
1. Invoke `/build-web-resources` — it handles JS code generation following Client API patterns, web resource creation, and form event registration (OnLoad/OnChange/OnSave)
2. After registering form events, offer `/validate-ui` to screenshot the form and verify scripts load without browser console errors
3. Update ADO story state

### Step 6c: Ribbon / Command Bar Commands (if spec requires custom buttons)

**Delegate to:** `.claude/skills/build-web-resources/SKILL.md` (ribbon commands are web resource-based)

For each ribbon command:
1. Create the supporting JS web resource with the command handler logic
2. Create the ribbon command via `dataverse_create_ribbon_command`
3. Offer `/validate-ui` to verify the button appears on the form command bar
4. Update ADO story state

### Step 6d: PCF Controls (if spec requires custom UI controls)

**Delegate to:** `.claude/skills/build-pcf-controls/SKILL.md`

For each PCF control:
1. Invoke `/build-pcf-controls` — it handles scaffolding, TypeScript/React implementation, solution packaging, import, and form binding via the `uniqueid` + `controlDescriptions` pattern
2. After form binding, offer `/validate-ui` to screenshot the form and verify the control renders
3. Update ADO story state

### Step 6e: Business Process Flows (if spec requires BPFs)

For each BPF requirement:
1. Create via `dataverse_create_bpf` with all stages, step fields, and required field configuration
2. Activate via `dataverse_activate_bpf`
3. **Smoke test:** Create a test record on the BPF entity and verify a BPF instance is created with the correct active stage
4. Update ADO story state

### Step 6f: Power Pages (if spec requires a portal)

**Delegate to:** `.claude/skills/build-power-pages/SKILL.md`

For each portal page:
1. Invoke `/build-power-pages` — it handles web templates, page templates, page creation via `powerpagecomponents` (NOT virtual entities), entity permissions, web roles, and custom JS/CSS
2. The skill chains to `frontend-design:frontend-design` for professional HTML/CSS/JS output
3. After building all pages, offer `/validate-ui` to screenshot each portal page
4. Update ADO story state

**IMPORTANT:** Power Pages MUST use the `/build-power-pages` skill. Direct MCP calls without this skill will miss critical patterns (powerpagecomponents vs virtual entities, web template hierarchy, table permissions scoping).

**Output:** Updated `ado-work-items.json`, appended `build-log.json`

---

## Phase 7: VERIFY & CLOSE

**Goal:** Validate the deployed app matches the spec and close out remaining work items.

1. **Validate deployment** against `build-specification.json`:
   - `dataverse_list_tables` — confirm all custom tables exist
   - `dataverse_list_columns` on each table — confirm columns match spec
   - `dataverse_list_views` — confirm views created
   - `dataverse_list_forms` — confirm forms exist (and for complex forms, verify each tab has fields via `dataverse_get_form`)
   - `dataverse_list_security_roles` — confirm roles exist, `dataverse_get_role_privileges` to spot-check privilege depth
   - `dataverse_get_app` — confirm MDA app
   - `dataverse_list_flows` — confirm flows active
   - `dataverse_list_plugin_assemblies` / `dataverse_list_plugin_steps` — confirm plugins registered
   - `dataverse_list_web_resources` — confirm JS/CSS assets created
   - `dataverse_list_form_events` on key forms — confirm event handlers registered
   - `dataverse_list_bpfs` — confirm BPFs active
   - `dataverse_list_power_pages` — confirm portal pages exist
   - Offer `/validate-ui` for visual verification of forms, views, and portal pages

2. **Create seed data and run functional tests:**

   Metadata checks (step 1) confirm components exist. Seed data confirms they actually WORK. This is NOT optional — it is the only way to catch runtime errors in plugins, flow logic bugs, BPF stage misconfigurations, and web resource script failures.

   **a) Create seed records** across the entity hierarchy using `dataverse_create_record` and `dataverse_batch_operations`:
   - Start at the top of the relationship chain (parent entities first) and work down
   - Create realistic, varied test data — not just one record per table, but enough to exercise different paths:
     - Multiple status values (active, inactive, completed, overdue, etc.)
     - Records that trigger different flow conditions (e.g., high severity vs low severity incidents)
     - Records with and without optional lookups populated
     - Date values that trigger scheduled flow logic (e.g., permits expiring within the warning window)
   - Suggested volume: 3-5 records per key entity, 1-2 per lookup/config table
   - Log all created record GUIDs for cleanup

   **b) Verify plugin execution:**
   - After creating trigger records (e.g., an Incident with Severity + Probability), verify the plugin-calculated fields are populated (e.g., Risk Score is set, Is Reportable is correct)
   - If any plugin-calculated field is null or wrong → the plugin has a runtime error. Check `dataverse_list_plugin_steps` to see if the step was auto-disabled (Dataverse disables steps that throw unhandled exceptions)
   - Create a record that SHOULD trigger cross-entity plugin behavior (e.g., an Emission Reading above threshold should auto-create an Incident)

   **c) Verify flow execution:**
   - After creating trigger records, call `dataverse_list_flow_runs` for each flow and verify:
     - A run was triggered (run exists)
     - The run succeeded (status = Succeeded, not Failed)
     - Expected side effects occurred (e.g., Notification records created, child records auto-created, status fields updated)
   - For scheduled flows: these can't be triggered by data alone. Verify they are active and note them for manual testing or wait for next scheduled run.

   **d) Verify BPF attachment:**
   - After creating records on BPF-enabled tables, verify a BPF instance was auto-created
   - Check the active stage is correct (should be Stage 1 for new records)

   **e) Verify web resource behavior (via /validate-ui if available):**
   - Open forms with registered scripts and check browser console for JavaScript errors
   - Verify conditional visibility works (e.g., toggling a boolean field shows/hides dependent fields)

   **f) Verify Power Pages (via /validate-ui if available):**
   - Screenshot each portal page
   - Verify entity lists show seed data
   - Verify entity forms load without errors
   - Verify create forms submit successfully

   **g) Cleanup (optional):**
   - Delete seed records after verification if this is a clean environment handoff
   - Or leave them as demo data if the user prefers (ask before deleting)

3. **Reconcile ADO items:**
   - Query all PBIs from `ado-work-items.json`
   - Any still "New" or "Active" → investigate and update
   - Manual items (BPFs, complex integrations) → add comment with guidance, tag `Manual-Action-Required`
   - Update Epic/Feature states based on child completion

3. **Generate standup report** (`standup-report.md`):
   ```markdown
   # Project Standup Report: {project_name}

   ## Summary
   - Documents processed: N
   - Requirements extracted: N
   - Requirements after architecture review: N
   - ADO work items created: N (Epics: X, Features: Y, Stories: Z)
   - Dataverse artifacts built: N tables, N columns, N views, N forms, N roles
   - Flows created: N
   - Manual items remaining: N

   ## What Was Built
   [Table of all created artifacts with ADO story references]

   ## Functional Test Results
   - Seed records created: N across M tables
   - Plugin tests: N/N passed (list any failures with error details)
   - Flow tests: N/N triggered successfully (list any failed runs)
   - BPF tests: N/N attached correctly
   - Web resource tests: N/N loaded without console errors
   - Power Pages tests: N/N pages rendered correctly

   ## Manual Action Required
   [List of items needing human intervention with ADO links]

   ## Verification Results
   [Pass/fail for each metadata validation check]
   ```

4. **Show report to user**

---

## Resumability

If a pipeline is interrupted (context compaction, error, user pause):

1. Read `status.json` to determine last completed phase
2. Use `--skip-to N` to resume from the appropriate phase
3. Each phase reads its input files (not in-memory state), so resuming is safe
4. `ado-work-items.json` tracks which items are done vs pending for Phase 4 resumability

---

## Example Invocation

```
/project-standup "SBA Cash App" "/SBA_Demo/" --ado-project "ADO MCP Demo" --publisher-prefix mcpd
```

This will:
1. Create `./project-runs/sba-cash-app/`
2. Extract requirements from `/SBA_Demo/` documents
3. Run architecture review team
4. Create ADO backlog in `ADO MCP Demo` project
5. Build the Dataverse app (tables, columns, forms, views, security, app)
6. Create Power Automate flows
7. Build extended components (plugins, web resources, PCFs, BPFs, Power Pages)
8. Create seed data, run functional tests, generate verification report