comet-browser-testing

name: comet-browser-testing description: "Use when testing web apps with Perplexity/Comet browser automation, debugging with real browsers, verifying authenticated flows, or when client-side visual verification is needed. Load for dynamic content testing, form automation, console error checking, or when server-side logs alone are insufficient. This skill provides a 3-phase token-efficient methodology: (1) Server-side checks via process_logs MCP and curl, (2) Client-side verification via Comet MCP with specific prompts, (3) Learning loop via context graph storage." context: fork agent: general-purpose

Comet Browser Testing

3-phase token-efficient methodology for web application testing using Comet/Perplexity MCP.

Overview

Prerequisites

Fallback Options (When Comet MCP Unavailable)

If mcp__comet-bridge__ tools are NOT available, use these alternatives:

Fallback Workflow (No Comet MCP)

# Option 1: Use dev-browser skill
Skill: dev-browser

# Option 2: Execute Playwright script via execute_code
execute_code("""
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("http://localhost:3000")
    page.screenshot(path="/tmp/test.png")
    print(page.content())
""")

Critical: If no browser automation tools available, fall back to:

1. Phase 1 (server-side only) - parse logs, check curl endpoints
2. Report that client-side verification requires browser automation MCP

Quick Reference

3-Phase Workflow

Phase 1: Server-Side Pre-Check (Optional but Fast)

Purpose: Catch known issues and server errors before browser testing.

# 1. Check context graph for similar issues
context_query_traces(query="error description", category="frontend")

# 2. Parse server logs for errors (99% token savings)
process_logs(file_path="app.log", pattern="ERROR|WARN", limit=20)

# 3. Quick health check
curl -s http://localhost:3000/api/health

Exit codes: 0=proceed to Phase 2, 1=block (fix server issues first)

Phase 2: Client-Side Testing (Required)

Purpose: Visual verification, console errors, functionality testing.

Connect:

comet_connect()

Test with specific prompts (see Testing Patterns below):

comet_ask(prompt="Navigate to URL and test X", newChat=true, timeout=30000)

Monitor progress (limit to 10-15 polls):

comet_poll()  # Repeat until complete or timeout

Capture evidence:

comet_screenshot()

Phase 3: Learning Loop

Purpose: Store findings for future reference and continuous improvement.

Store issues found:

context_store_trace(
  decision="Issue description and fix applied",
  category="frontend|hydration|css|framework|testing|deployment",
  outcome="pending"  # Update to "success" after fix
)

Update after fixes:

context_update_outcome(trace_id="trace_abc123...", outcome="success")

Testing Patterns (Critical)

Key insight: Generic prompts like "does it work?" produce false positives. Use specific prompts that ask for evidence.

Initial Load Check

Navigate to {URL} and report:
1. Does the page fully load? (yes/no)
2. Any console errors? (list them)
3. What specific elements are visible? (describe 3-5 elements)
4. Is there a loading state that doesn't resolve? (describe)

Styling Verification

Navigate to {URL} and check styling:
1. Are there any obvious layout breaks? (describe)
2. Do colors/theme appear consistent? (yes/no with details)
3. Are there any unstyled elements? (describe)
4. Is text readable against backgrounds? (yes/no)

Functionality Test

Navigate to {URL} and test functionality:
1. Can you click {button/element}? (yes/no)
2. What happens when you click? (describe)
3. Any console errors on interaction? (list them)
4. Does the action complete? (describe result)

Multi-Page Check

Navigate to {URL} and test navigation:
1. Click on {navigation element}
2. Does the URL change? (yes/no, what to)
3. Does the new page load? (yes/no)
4. Any errors during navigation? (describe)

Visual Completeness

Navigate to {URL} and verify:
1. Are all expected sections visible? (describe)
2. Any broken images or icons? (describe)
3. Is content truncated or hidden? (describe)
4. Any obvious visual bugs? (describe)

Feature Behavior

Navigate to {URL} and test {feature}:
1. What specific action did you take? (describe)
2. What was the expected behavior? (describe)
3. What actually happened? (describe)
4. Any console errors during test? (list them)

Feature Testing Templates

Authentication/Authorization

Test authentication on {URL}:
1. Is there a login button/form visible? (yes/no, describe)
2. Click the login button - what happens? (describe)
3. Any auth-related console errors? (list)
4. Does the page indicate authenticated state? (describe)

Form Submission

Test form on {URL}:
1. Fill in the form with test data (describe fields)
2. Click submit - what happens? (describe)
3. Any validation errors? (list)
4. Does submission complete? (describe result)

Navigation/Routing

Test navigation on {URL}:
1. Click {navigation item} - what happens?
2. Does URL change? (to what)
3. Does new page load correctly? (describe)
4. Any console errors during navigation? (list)

Data Display

Test data display on {URL}:
1. Is data visible on the page? (describe what data)
2. Does data appear complete? (yes/no with details)
3. Any loading states or skeletons? (describe)
4. Any console errors related to data fetching? (list)

User Interactions

Test {interaction} on {URL}:
1. What element did you interact with? (describe)
2. What was the expected result? (describe)
3. What actually happened? (describe)
4. Any console errors during interaction? (list)

MCP Tools Reference

Comet MCP Tools

Token-Efficient MCP Tools

Context Graph MCP Tools

Resource Loading Guide

Common Workflows

Quick Health Check (Phase 1 only)

# Use when: Just checking if apps are running
scripts/pre-check.sh my-app

Full Browser Test (All phases)

# Use when: Comprehensive testing needed
scripts/pre-check.sh my-app && \
scripts/browser-test.sh visual http://localhost:3000 && \
scripts/store-findings.sh frontend "Issue description"

Regression Test (Phase 1 + 3)

# Use when: Verifying fixed issue
context_query_traces(query="original issue", category="frontend")
# Then run Phase 2 to verify fix
context_update_outcome(trace_id="...", outcome="success")

Best Practices

Error Handling

Token Efficiency Summary