---

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 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:

   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 (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 has meaningful content (not blank, not a generic error page).
  • Look for common error indicators: "404", "Page not found", "500", "Internal Server Error", "This site can't be reached".
• If the page shows an error, report it to the user and ask whether to continue or stop.

2.5 Capture Console Errors

• Use browser_console_messages with level: "error" to check for JavaScript errors on initial load.
• Record any errors found — these will be included in the final report.

2.6 Capture Initial Network Requests

• Use browser_network_requests with includeStatic: false to capture the initial page load API calls.
• Record any /_api/ or OData requests and their status codes for Phase 5 analysis.

Output

• Browser launched at correct viewport size
• Homepage loaded and verified via snapshot
• Initial console errors and network requests recorded
• If the homepage shows a login screen, noted for Phase 3

---

Phase 3: Authentication Check

Goal: Detect if the site requires authentication and handle login if needed. Power Pages sites can have two layers of authentication:

1. Private site gate — The entire site is private. Navigating to the site redirects to an identity provider (Azure AD B2C, etc.) before any site content is visible. The browser URL will typically change to a different domain (e.g., login.microsoftonline.com, *.b2clogin.com).
2. Site-level authentication — The site is publicly accessible (homepage loads), but certain pages or features require a logged-in user with a specific web role. Indicated by "Sign in" / "Log in" links in the navigation, or pages that show restricted-access messages.

Actions

3.1 Analyze Homepage Snapshot for Private Site Gate

Review the browser snapshot from Phase 2.4 and the current browser URL for signs of a private site redirect:

• The page content shows an identity provider login form (Azure AD B2C, Azure AD, etc.)
• The browser URL has changed to a different domain than SITE_URL (e.g., login.microsoftonline.com, *.b2clogin.com, or a custom identity provider domain)
• A 401/403 response was returned before any site content loaded
• The page is blank or shows "Access denied" / "You do not have access" with no site navigation visible

3.2 Handle Private Site Gate

<!-- gate: test-site:3.2.private-gate-login | category=pause | cancel-leaves=nothing -->

🚦 Gate (pause · test-site:3.2.private-gate-login): External wait — site redirected to identity provider; skill pauses until user completes login or cancels.

If a private site gate is detected, use AskUserQuestion:

| Question | Header | Options | |----------|--------|---------| | This site is private — it redirected to an identity provider login page before any content could load. A browser window should be open showing the login page. Please log in there using credentials that have access to this site. Once you have successfully logged in and can see the site homepage, select "I have logged in" below. | Private Site Login | I have logged in (Recommended) — I've completed the login and can see the site, Cancel testing — Stop the test |

If "I have logged in":

1. Use browser_snapshot to verify the user is now on the actual site (site content visible, navigation present, URL is back on the SITE_URL domain).

2. If still on the identity provider login page:

   <!-- gate: test-site:3.2.login-retry | category=pause | cancel-leaves=nothing -->

   🚦 Gate (pause · test-site:3.2.login-retry): Login not yet complete — re-prompt or cancel.

   • Use AskUserQuestion again: "It looks like the login hasn't completed yet. The browser should still be open — please complete the login and try again."
   • Repeat until login is confirmed or user cancels.

3. Once confirmed, re-run Phase 2.5 and 2.6 (capture console errors and network requests on the now-loaded homepage).

4. Continue to step 3.3 to check for site-level authentication.

If "Cancel testing":

• Stop the skill and inform the user they can re-run it after resolving access.

3.3 Analyze for Site-Level Authentication

After the homepage is loaded (either directly for public sites, or after passing the private site gate), review the snapshot for signs of site-level authentication:

• "Sign in" / "Log in" / "Register" links or buttons in the site navigation
• Pages that show "You must be signed in to view this page" or similar messages
• Content that indicates some areas are restricted to authenticated users

3.4 Handle Public Site (No Authentication Needed)

If neither a private site gate nor site-level authentication indicators are found:

• Inform the user: "Site is publicly accessible. Proceeding with page and API testing."
• Skip to Phase 4.

3.5 Handle Site-Level Authentication

<!-- gate: test-site:3.5.public-vs-auth | category=plan | cancel-leaves=nothing -->

🚦 Gate (plan · test-site:3.5.public-vs-auth): Site has Sign-in UI — test as authenticated user, skip auth-gated pages, or canc