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.

• 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.
• 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.

$ARGUMENTS

1. Validate it starts with

   https://

   .
2. Store it as

   SITE_URL

   and skip to Phase 2.

1. Locate the project root by searching for

   powerpages.config.json

   :

   **/powerpages.config.json

2. Run the activation status check script:
   powershell

   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.

• SITE_URL

  resolved and ready for testing

• Use

  browser_resize

  with width: 1280, height: 720.

• Use

  browser_navigate

  to open

  SITE_URL

  .

• 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).

• 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.

• 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.

• 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.

• 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

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.

• 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

AskUserQuestion

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

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

• "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

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

AskUserQuestion

1. Use

   browser_snapshot

   to verify the user is now logged in (login link replaced with user name/profile, or authenticated content is visible).
2. If the login form is still showing:
   • 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. Create an additional task for testing authenticated scenarios using

   TaskCreate

   :

   Task subject	activeForm	Description
   Test authenticated pages and APIs	Testing authenticated scenarios	Re-crawl site as logged-in user, verify auth-gated pages load and authenticated API calls succeed

• Note that only public pages will be tested. Some API calls may return 401/403 — these will be flagged but not treated as failures.
• Do not create the authenticated testing task.
• Continue to Phase 4.

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

• Authentication status resolved for both layers:
  • Private site gate: passed, not needed, or cancelled
  • Site-level auth: logged in, skipped, or not needed
• If authenticated: additional task created for authenticated testing in Phase 5.6

browser_evaluate

() => {
  const links = Array.from(document.querySelectorAll('a[href]'));
  return links
    .map(a => a.href)
    .filter(href => href.startsWith(window.location.origin))
    .filter(href => !href.includes('#') || href.split('#')[0] !== window.location.href.split('#')[0])
    .map(href => href.split('#')[0])
    .filter((href, i, arr) => arr.indexOf(href) === i);
}

"Found X internal links on the homepage. Testing each page..."

1. Navigate: Use

   browser_navigate

   to go to the URL.
2. Wait: Use

   browser_wait_for

   with time: 3 seconds for the page to render.
3. Snapshot: Use

   browser_snapshot

   to verify the page rendered content.
4. Check for errors: Look for error indicators in the snapshot (404, 500, blank page, error messages).
5. Console errors: Use

   browser_console_messages

   with level: "error" to check for JavaScript errors.
6. Discover new links: Use

   browser_evaluate

   (same script as 4.1) to find any new internal links not already in the queue.
7. Record result: URL, status (Pass/Fail), error count, notes.

• Add any newly discovered links from step 4.2.6 to the test queue.
• Continue testing until all links are visited or the 25-page cap is reached.
• If the cap is hit, inform the user: "Reached the 25-page testing limit. Y additional links were discovered but not tested."

• URL tested
• Load status (Pass / Fail)
• Number of console errors
• Notes (error messages, blank page, redirect, etc.)

• All discoverable pages crawled (up to 25)
• Pass/fail status recorded for each page
• New links discovered during crawl added to results

/_api/

1. Use

   browser_navigate

   to go to the page.
2. Use

   browser_wait_for

   with time: 5 seconds to allow API calls to complete.

• Use

  browser_network_requests

  with includeStatic: false to get all network requests.
• Filter for API requests matching these patterns:

  • /_api/

    — Power Pages Web API / OData endpoints

  • /api/

    — Custom API endpoints
  • URLs containing

    odata

    or

    $filter

    ,

    $select

    ,

    $expand

    query parameters

• 401 Unauthorized: "This endpoint requires authentication. If you skipped login in Phase 3, try re-running with authentication. Otherwise, check that the auth token is being passed correctly."
• 403 Forbidden on

  /_api/

  calls: "Check the following:\n 1. Table permissions — Ensure a table permission exists for this table with the correct scope and privileges (Read, Write, etc.) assigned to the appropriate web role.\n 2. Site settings — Verify

  Webapi/<tablename>/enabled

  is set to

  true

  and

  Webapi/<tablename>/fields

  lists the required columns (exact Dataverse LogicalNames, all lowercase, comma-separated). If the failing request uses aggregate OData (

  $apply

  ,

  aggregate

  , grouped totals), set

  Webapi/<tablename>/fields

  to

  *

  .\n 3. Web role assignment — Confirm the authenticated user has the correct web role assigned."
• 404 Not Found: "Verify the entity set name (should be the plural form of the table logical name). Check that the table exists in Dataverse and is published."
• 500 Internal Server Error: "Enable the

  Webapi/error/innererror

  site setting (set to

  true

  ) to get detailed error messages. Redeploy and retest to see the inner error details."

browser_snapshot

1. Use

   browser_click

   to interact with form submit buttons.
2. Use

   browser_wait_for

   to wait for the form response.
3. Use

   browser_network_requests

   to capture the resulting POST/PATCH requests.
4. Analyze responses using the same criteria as 5.3.

• All API endpoints discovered and tested
• Pass/fail status with HTTP status codes recorded
• Actionable remediation guidance provided for each failure

Skip this step entirely if the user chose "Skip authenticated pages" in Phase 3.5, or if no site-level authentication was detected in Phase 3.3.

in_progress

1. Navigate back to

   SITE_URL

   (homepage).
2. Use

   browser_snapshot

   to capture the authenticated navigation.
3. Use

   browser_evaluate

   (same link extraction script as Phase 4.1) to discover internal links.
4. Compare against the links already tested in Phase 4. Identify any new links that were not visible before authentication.

"Found X additional pages visible after login that were not accessible anonymously. Testing each page..."

1. Navigate, wait, snapshot, check for errors, capture console errors.
2. Record results separately as authenticated page tests.
3. Respect the same 25-page cap (counting pages already tested in Phase 4).

/_api/

1. Use

   browser_network_requests

   with includeStatic: false to capture API calls.
2. Compare against API calls captured in Phase 5 — identify any new endpoints or endpoints that previously returned 401/403 and now succeed.
3. Analyze responses using the same criteria as Phase 5.3.

• Authenticated pages discovered and tested (count, pass/fail)
• Authenticated API calls (count, pass/fail, any endpoints that changed from fail to pass after login)

completed

• Authenticated pages crawled and tested
• Authenticated API endpoints captured and analyzed
• Results recorded separately for the test report

Reference:

${CLAUDE_PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "TestSite"

• Table permissions issues →

  /create-webroles

  or manually configure table permissions
• Site settings issues → Check

  Webapi/<table>/enabled

  and

  Webapi/<table>/fields

  settings
• Authentication issues →

  /setup-auth

• Missing endpoints → Verify table exists in Dataverse via

  /setup-datamodel

• Server errors → Enable

  Webapi/error/innererror

  site setting for diagnostics

• Use

  browser_close

  to clean up the browser session.

• If API failures were found:

  /integrate-webapi

  — Fix Web API site settings and table permissions
• If authentication issues:

  /setup-auth

  — Configure authentication providers
• If pages had errors: Review the site code and redeploy with

  /deploy-site

• If all tests passed: Site is working correctly! Consider

  /add-seo

  for search engine optimization

• Comprehensive test report presented with pass/fail for pages and APIs
• Actionable recommendations for each failure
• Browser session closed
• Next steps suggested

• Use TaskCreate/TaskUpdate to track progress at every phase
• This skill is read-only — it does not modify any files or data
• Never attempt to log in on behalf of the user — always ask them to log in via the browser window
• Present errors clearly — when a page or API fails, include the specific URL and error details

1. Phase 1.3: If the site is not activated, stop and redirect to

   /activate-site

2. Phase 1.4: If no URL can be auto-detected, must ask the user
3. Phase 3.2: If the site is private (redirects to identity provider), must ask the user to log in — cannot bypass
4. Phase 3.5: If site-level authentication is available, must ask the user whether to log in or skip — cannot auto-login
5. Phase 4.3: Stop crawling at 25 pages to prevent infinite loops
6. Phase 5.5: Before interacting with forms (which may create/modify data), must get explicit user permission