Test Site

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: critical finding, no behavioural pass, undeclared transfer.

If the token endpoint is unavailable or the observed URL is not same-origin, report the replay as blocked instead of importing cookies or making an unauthenticated request.

Audit 0.4.1 · source sha 8075ef5705c5 · 18 Oct 2026Report an issue or request a re-scan

• Publishermicrosoft GitHub organizationOwner of the repository this skill is read from
• Source foldermicrosoft/power-platform-skills/plugins/power-pages/skills/test-siteThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict8075ef5705c5A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Tests a deployed, activated Power Pages site at runtime using browser-based navigation, page crawling, and API request verification via Playwright. Use when the user wants to test, verify, or smoke-test their deployed…

---
name: test-site
description: >-
  Tests a deployed, activated Power Pages site at runtime using browser-based navigation,
  page crawling, and API request verification via Playwright. Use when the user wants to
  test, verify, or smoke-test their deployed site.
user-invocable: true
argument-hint: "<site-url>"
allowed-tools: Read, Bash, Glob, Grep, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, mcp__plugin_power-pages_playwright__browser_navigate, mcp__plugin_power-pages_playwright__browser_snapshot, mcp__plugin_power-pages_playwright__browser_click, mcp__plugin_power-pages_playwright__browser_close, mcp__plugin_power-pages_playwright__browser_network_requests, mcp__plugin_power-pages_playwright__browser_console_messages, mcp__plugin_power-pages_playwright__browser_wait_for, mcp__plugin_power-pages_playwright__browser_take_screenshot, mcp__plugin_power-pages_playwright__browser_resize, mcp__plugin_power-pages_playwright__browser_evaluate
model: opus
---

> **Plugin check**: Run `node "${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 "${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 (desc

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/microsoft/power-platform-skills
git -C power-platform-skills checkout 8075ef5705c5

Works in

1. 2026-10-18
   ✕BLOCK D 69 / 100

   first audit · source 8075ef5705c5

Questions about Test Site

• github.com/microsoft/power-platform-skills/tree/main/plugins/pow — the audited source at commit 8075ef5705c5 and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology