TenantAtlas/.github/skills/browsertest/SKILL.md

name	description	license	metadata
browsertest	Führe einen vollständigen Smoke-Browser-Test im Integrated Browser für das aktuelle Feature aus, inklusive Happy Path, zentraler Regressionen, Kontext-Prüfung und belastbarer Ergebniszusammenfassung.	MIT	author GitHub Copilot

Browser Smoke Test

What This Skill Does

Use this skill to validate the current feature end-to-end in the integrated browser.

This is a focused smoke test, not a full exploratory test session. The goal is to prove that the primary operator flow:

• loads in the correct auth, workspace, and tenant context
• exposes the expected controls and decision points
• completes the main happy path without blocking issues
• lands in the expected end state or canonical drilldown
• does not show obvious regressions such as broken navigation, missing data, or conflicting actions

The skill should produce a concrete pass or fail result with actionable evidence.

When To Apply

Activate this skill when:

• the user asks to smoke test the current feature in the browser
• a new Filament page, dashboard signal, report, wizard, or detail flow was just added
• a UI regression fix needs confirmation in a real browser context
• the primary question is whether the feature works from an operator perspective
• you need a quick integration-level check without writing a full browser test suite first

What Success Looks Like

A successful smoke test confirms all of the following:

• the target route opens successfully
• the visible context is correct
• the main flow is usable
• the expected result appears after interaction
• the route or drilldown destination is correct
• the surface does not obviously violate its intended interaction model

If the test cannot be completed, the output must clearly state whether the blocker is:

• authentication
• missing data or fixture state
• routing
• UI interaction failure
• server error
• an unclear expected behavior contract

Do not guess. If the route or state is blocked, report the blocker explicitly.

Preconditions

Before running the browser smoke test, make sure you know:

• the canonical route or entry point for the feature
• the primary operator action or happy path
• the expected success state
• whether the feature depends on a specific tenant, workspace, or seeded record

When available, use the feature spec, quickstart, tasks, or current browser page as the source of truth.

Standard Workflow

1. Define the smoke-test scope

Identify:

• the route to open
• the primary action to perform
• the expected end state
• one or two critical regressions that must not break

The smoke test should stay narrow. Prefer one complete happy path plus one critical boundary over broad exploratory clicking.

2. Establish the browser state

• Reuse the current browser page if it already matches the target feature.
• Otherwise open the canonical route.
• Confirm the current auth and scope context before interacting.

For this repo, that usually means checking whether the page is on:

• /admin/... for workspace-context surfaces
• /admin/t/{tenant}/... for tenant-context surfaces

3. Inspect before acting

• Use read_page before interacting so you understand the live controls, refs, headings, and route context.
• Prefer read_page over screenshots for actual interaction planning.
• Use screenshots only for visual evidence or when the user asks for them.

4. Execute the primary happy path

Run the smallest meaningful flow that proves the feature works.

Typical steps include:

• open the page
• verify heading or key summary text
• click the primary CTA or row
• fill the minimum required form fields
• confirm modal or dialog text when relevant
• submit or navigate
• verify the expected destination or changed state

After each meaningful action, re-read the page so the next step is based on current DOM state.

5. Validate the outcome

Check the exact result that matters for the feature.

Examples:

• a new row appears
• a status changes
• a success message appears
• a report filter changes the result set
• a row click lands on the canonical detail page
• a dashboard signal links to the correct report page

6. Check for obvious regressions

Even in a smoke test, verify a few core non-negotiables:

• the page is not blank or half-rendered
• the main action is present and usable
• the visible context is correct
• the drilldown destination is canonical
• no obviously duplicated primary actions exist
• no stuck modal, spinner, or blocked interaction remains onscreen

7. Capture evidence and summarize clearly

Your result should state:

• route tested
• context used
• steps executed
• pass or fail
• exact blocker or discrepancy if failed

Include a screenshot only when it adds value.

Tool Usage Guidance

Use the browser tools in this order by default:

1. read_page
2. click_element
3. type_in_page
4. handle_dialog when needed
5. navigate_page or open_browser_page only when route changes are required
6. run_playwright_code only if the normal browser tools are insufficient
7. screenshot_page for evidence, not for primary navigation logic

Repo-Specific Guidance For TenantPilot

Workspace surfaces

For /admin pages and similar workspace-context surfaces:

• verify the page is reachable without forcing tenant-route assumptions
• confirm any summary signal or CTA lands on the canonical destination
• verify calm-state versus attention-state behavior when the feature defines both

Tenant surfaces

For /admin/t/{tenant}/... pages:

• verify the tenant context is explicit and correct
• verify drilldowns stay in the intended tenant scope
• treat cross-tenant leakage or silent scope changes as failures

Filament list or report surfaces

For Filament tables, reports, or registry-style pages:

• verify the heading and table shell render
• verify fixed filters or summary controls exist when the spec requires them
• verify row click or the primary inspect affordance behaves as designed
• verify empty-state messaging is specific rather than generic when the feature defines custom behavior

Filament detail pages

For detail or view surfaces:

• verify the canonical record loads
• verify expected sections or summary content are present
• verify critical actions or drillbacks are usable

Result Format

Use a compact result format like this:

Browser smoke result: PASS
Route: /admin/findings/hygiene
Context: workspace member with visible hygiene issues
Steps: opened report -> verified filters -> clicked finding row -> landed on canonical finding detail
Verified: report rendered, primary interaction worked, drilldown route was correct

If the test fails:

Browser smoke result: FAIL
Route: /admin/findings/hygiene
Context: authenticated workspace member
Failed step: clicking the summary CTA
Expected: navigate to /admin/findings/hygiene
Actual: remained on /admin with no route change
Blocker: CTA appears rendered but is not interactive

Examples

Example 1: Smoke test a new report page

Use this when the feature adds a new read-only report.

Steps:

• open the canonical report route
• verify the page heading and main controls
• confirm the table or defined empty state is visible
• click one row or primary inspect affordance
• verify navigation lands on the canonical detail route

Pass criteria:

• report loads
• intended controls exist
• primary inspect path works

Example 2: Smoke test a dashboard signal

Use this when the feature adds a summary signal on /admin.

Steps:

• open /admin
• find the signal
• verify the visible count or summary text
• click the CTA
• confirm navigation lands on the canonical downstream surface

Pass criteria:

• signal is visible in the correct state
• CTA text is present
• CTA opens the correct route

Example 3: Smoke test a tenant detail follow-up

Use this when a workspace-level surface should drill into a tenant-level detail page.

Steps:

• open the workspace-level surface
• trigger the drilldown
• verify the target route includes the correct tenant and record
• confirm the target page actually loads the expected detail content

Pass criteria:

• drilldown route is canonical
• tenant context is correct
• destination content matches the selected record

Common Pitfalls

• Clicking before reading the page state and refs
• Treating a blocked auth session as a feature failure
• Confusing workspace-context routes with tenant-context routes
• Reporting visual impressions without validating the actual interaction result
• Forgetting to re-read the page after a modal opens or a route changes
• Claiming success without verifying the final destination or changed state

Non-Goals

This skill does not replace:

• full exploratory QA
• formal Pest browser coverage
• accessibility review
• visual regression approval
• backend correctness tests

It is a fast, real-browser confidence pass for the current feature.