Test Site
Smoke-test an activated Power Pages site in a real browser, crawl links, inspect network calls, and produce a runtime verification report.
Overview
test-site is an agent skill for the Ship phase that browser-tests a deployed Power Pages site with Playwright crawling and network verification.
Install
npx skills add https://github.com/microsoft/power-platform-skills --skill test-siteWhat is this skill?
- Playwright-driven navigation, snapshots, clicks, and console/network capture on a deployed site URL
- Crawls discoverable links and verifies pages load with comprehensive test report output
- Expects deployed and activated Power Pages site—documented prerequisite for deploy-site and activate flows
- Plugin version check script must run before proceeding when using the Power Pages Claude plugin
Adoption & trust: 72 installs on skills.sh; 349 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You deployed Power Pages but lack a structured runtime pass that proves pages, links, and APIs work on the live URL.
Who is it for?
Builders with an already deployed and activated Power Pages site who need automated smoke testing from the agent.
Skip if: Local portal authoring only, unit tests in repo, or sites that have not completed deploy and activate prerequisites.
When should I use this skill?
User wants to test, verify, or smoke-test their deployed, activated Power Pages site at runtime with browser navigation and API verification; argument hint is site URL.
What do I get? / Deliverables
You get a browser-based crawl with network and console signals plus a comprehensive test report for the activated site.
- Comprehensive runtime test report
- Screenshots and network/console capture from crawl
Recommended Skills
Journey fit
Post-deploy verification belongs in Ship testing after the site is live, not during initial idea research. Browser navigation, page crawl, API request checks, and screenshots are classic shipped-product smoke and regression testing.
How it compares
Runtime portal smoke tests via Playwright, not static code review or Infrastructure-as-code deploy skills.
Common Questions / FAQ
Who is test-site for?
Power Pages owners and indie consultants who ship customer-facing portals and want agent-driven verification after activation.
When should I use test-site?
In Ship testing after /deploy-site and activation when you want to test, verify, or smoke-test the deployed site URL with browser navigation and API checks.
Is test-site safe to install?
The skill uses browser MCP tools and Bash for version checks; review Security Audits on this Prism page and scope automation to URLs you control.
Workflow Chain
Requires first: deploy site
SKILL.md
READMESKILL.md - Test Site
> **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 phas