Skip to main content
ClaudeWave
Skill358 repo starsupdated today

test-site

The test-site skill validates a deployed Power Pages site by navigating it in a browser, crawling up to 25 discoverable pages, verifying successful page loads, capturing network traffic to test API requests, and generating a comprehensive JSON test report. Use this skill after deploying and activating a Power Pages site to confirm pages render correctly, authentication flows work as expected, and Web API endpoints return successful responses with accurate response shapes for frontend integration.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/microsoft/power-platform-skills /tmp/test-site && cp -r /tmp/test-site/plugins/power-pages/skills/test-site ~/.claude/skills/test-site
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

> **Plugin check**: Run `node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"` — if it outputs a message, show it to the user before proceeding.

# Test Power Pages Site

Test a deployed, activated Power Pages site at runtime. Navigate the site in a browser, crawl all discoverable links, verify pages load correctly, capture network traffic to test API requests, and generate a comprehensive test report.

> **Prerequisite:** This skill expects a deployed and activated Power Pages site. Run `/deploy-site` and `/activate-site` first if the site is not yet live.

## Core Principles

- **Non-destructive**: This skill is read-only — it does not create, modify, or delete any files or data. It only observes the site via the browser.
- **API-first testing**: The primary goal beyond page loads is verifying that all `/_api/` (Web API / OData) requests return successful responses.
- **Response-shape discovery**: For `/_api/serverlogics/` endpoints the test run must also capture and report the actual response body shape so frontend integrations can be written against the real response, not a guessed one. If frontend parsing or field access does not match the observed shape, report the mismatch and describe the parsing or field-access changes needed — this skill does not modify any code.
- **User-controlled authentication**: Never attempt to log in automatically. Always ask the user to log in via the browser window when authentication is required.
- **Bounded crawling**: Cap page crawling at 25 pages to prevent infinite loops on sites with dynamic or paginated URLs.

## Validation Test Categories

Every run produces a categorized test report (`docs/alm/last-test-site.json` — see Phase 6.7a). Stable category IDs and the source phase that produces each:

| Category `id` | Display Name | Source phase | What it covers |
|---|---|---|---|
| `site-load` | **Site Load** | Phase 2 | Homepage HTTP status, redirect handling, initial render. One card for the homepage; failures are critical. |
| `authentication` | **Authentication** | Phase 3 | Anonymous-to-Entra redirect, private-site gate detection, login flow integrity. Critical for private sites. |
| `page-crawl` | **Page Crawl** | Phase 4 | One card per page tested (up to 25). Each card carries the page URL, HTTP status, and any console errors. Severity scales with HTTP class (5xx → critical, 4xx on public → high). |
| `web-api` | **Web API** | Phase 5 | One card per `/_api/` endpoint observed during the run. Captures status code, response shape, and remediation hints (table-permissions / site-settings / inner-error settings). |
| `auth-pages` | **Authenticated Pages** | Phase 5.6 | Pages that only became reachable after login. Skipped when the user opts out of authenticated testing. |
| `auth-api` | **Authenticated API** | Phase 5.6 | API endpoints that only became callable after login. Skipped when authenticated testing is skipped. |
| `console` | **Console Health** | Aggregated | Rolled-up count of console errors observed across all phases. Severity is medium by default. |

`plan-alm`'s Validation tab consumes this shape directly — each category becomes a collapsible group in the per-stage sub-tab, and the rolled-up `runOutcome` (`passed` / `passed-with-warnings` / `failed`) drives the green / yellow / red Outcome badge in both the Validation tab and the Execution checklist substep.

**Initial request:** $ARGUMENTS

---

## Phase 1: Resolve Site URL

**Goal:** Determine the live URL of the Power Pages site to test.

### Actions

#### 1.1 Create Task List

Create the full task list with all 6 phases before starting any work (see [Progress Tracking](#progress-tracking) table).

#### 1.2 Check User Input

If the user provided a URL in `$ARGUMENTS`:

1. Validate it starts with `https://`.
2. Store it as `SITE_URL` and skip to Phase 2.

#### 1.3 Auto-Detect from Activation Status

If no URL was provided, attempt auto-detection:

1. Locate the project root by searching for `powerpages.config.json`:

   ```
   **/powerpages.config.json
   ```

2. Run the activation status check script:

   ```bash
   node "${CLAUDE_PLUGIN_ROOT}/scripts/check-activation-status.js" --projectRoot "<PROJECT_ROOT>"
   ```

3. Evaluate the JSON result:
   - **If `activated` is `true` and `websiteUrl` is present**: Use `websiteUrl` as `SITE_URL`. Inform the user: "Detected your site URL: **<websiteUrl>**"
   - **If `activated` is `false`**: Inform the user: "Your site is not yet activated. Please run `/activate-site` first, then re-run this skill."  Stop the skill.
   - **If `error` is present**: Fall through to step 1.4.

#### 1.4 Ask the User

<!-- not-a-gate: site-URL fallback prompt — data-gathering when auto-detection fails; no Dataverse/state change -->

If auto-detection failed or was inconclusive, use `AskUserQuestion`:

| Question | Header | Options |
|----------|--------|---------|
| What is the URL of the deployed Power Pages site you want to test? (e.g., <https://contoso.powerappsportals.com>) | Site URL | I'll paste the URL (description: Select "Other" below and paste your site URL), I don't know my URL (description: Run `/activate-site` to get your site URL, or check the Power Platform admin center) |

Store the user-provided URL as `SITE_URL`.

### Output

- `SITE_URL` resolved and ready for testing

---

## Phase 2: Launch Browser & Initial Load

**Goal:** Open the site in a browser, verify the homepage loads, and capture baseline errors.

### Actions

#### 2.1 Resize Browser

Set the browser to a standard desktop viewport:

- Use `browser_resize` with **width: 1280, height: 720**.

#### 2.2 Navigate to Site

- Use `browser_navigate` to open `SITE_URL`.

#### 2.3 Wait for Page Load

- Use `browser_wait_for` with **time: 5** seconds to allow the page to fully render (SPAs may need time for client-side routing and API calls).

#### 2.4 Verify Homepage

- Use `browser_snapshot` to take an accessibility snapshot.
- Check the snapshot for signs of a working page:
  - Page h
add-data-sourceSkill

Guide the user to add a data source, connection, or API connector to a Canvas App via Power Apps Studio, then verify and continue. USE WHEN the user asks to add a data source, add a connection, add an API, add a connector, connect to SharePoint / Dataverse / SQL / Excel / OneDrive / Teams / Office 365, or any similar request to make new data available to the app. DO NOT USE WHEN the user is asking to list or describe existing data sources — call list_data_sources or list_apis directly instead.

canvas-appSkill

Creates or edits a Power Apps Canvas App through the Canvas Authoring MCP coauthoring session. Handles new app generation from requirements, simple inline edits, and complex multi-screen changes with parallel screen builders. Triggers on requests to create, build, generate, modify, update, change, or edit a Canvas App or .pa.yaml files.

configure-canvas-mcpSkill

Configure the Canvas Authoring MCP server for the current coauthoring session. USE WHEN "configure MCP", "set up MCP server", "MCP not working", "connect Canvas Apps MCP", "canvas-authoring not available", "MCP not configured", "set up canvas apps". DO NOT USE WHEN prerequisites are missing — direct the user to install .NET 10 SDK first.

generate-canvas-appSkill

[DEPRECATED — use canvas-app instead] Generate a complete Power Apps canvas app.

report-issueSkill

>

add-azuredevopsSkill

Adds Azure DevOps connector to a Power Apps code app. Use when querying work items, creating bugs, managing pipelines, or making ADO API calls.

add-connectorSkill

Adds any Power Platform connector to a Power Apps code app. Generic fallback for connectors not covered by a specific skill.

add-datasourceSkill

Adds a data source or connector to a Power Apps code app. Asks what the user wants to accomplish and routes to the appropriate specialized skill.