Authenticate and Verify

Handles authentication to localhost:3000 and verifies successful login state.

Token Efficiency: With Chrome DevTools session sharing, skips auth workflow 70% of the time (1,500 → 450 tokens)

Usage

Invoke with: /auth-verify [optional-url]

Examples:

• /auth-verify - Check auth, navigate to /app/scheduler if authenticated
• /auth-verify http://localhost:3000/app/settings - Check auth, navigate to specific page
• /auth-verify --force-login - Force new login even if session exists

Prerequisites

• Chrome DevTools MCP enabled: claude --chrome (for session sharing)
• Application running on localhost:3000
• Test credentials available: Renee.Waters61@gmail.com / password

Workflow

Step 1: Check Existing Session (Chrome DevTools Only)

With Chrome DevTools MCP:

// Navigate to protected page
mcp__playwright__browser_navigate({
  url: "http://localhost:3000/app/scheduler"
})

// Take snapshot to check auth state
mcp__playwright__browser_snapshot()

// Check for authenticated indicators:
// 1. [data-slot="avatar"] element present
// 2. URL remains /app/* (not redirected to /auth/sign-in)
// 3. "Schedule" heading visible

Authentication check logic:

• If [data-slot="avatar"] present → Already authenticated ✅
• If URL redirected to /auth/sign-in → Not authenticated ❌
• If error page shown → Auth service down ⚠️

With Playwright MCP (no session sharing):

• Skip to Step 2 (always perform login)

Step 2: Perform Login (if needed)

Only execute if:

• No existing session found (Step 1 failed)
• OR --force-login flag provided
• OR using Playwright MCP (no session sharing)

2a. Navigate to Login Page

mcp__playwright__browser_navigate({
  url: "http://localhost:3000/app/auth/sign-in"
})

2b. Take Snapshot for Form References

mcp__playwright__browser_snapshot()

// Extract refs for:
// - Email input: [aria-label="Work Email Address"] or [name="email"]
// - Password input: [aria-label="Password"] or [name="password"]
// - Submit button: [type="submit"] with text "Sign in"

2c. Fill Login Form (Batch Operation)

mcp__playwright__browser_fill_form({
  fields: [
    {
      name: "Work Email Address",
      type: "textbox",
      ref: "[email-input-ref-from-snapshot]",
      value: "Renee.Waters61@gmail.com"
    },
    {
      name: "Password",
      type: "textbox",
      ref: "[password-input-ref-from-snapshot]",
      value: "password"
    }
  ]
})

2d. Submit Form

mcp__playwright__browser_click({
  element: "Sign in button",
  ref: "[submit-button-ref-from-snapshot]"
})

2e. Wait for Navigation

mcp__playwright__browser_wait_for({ time: 2 })

Step 3: Verify Authentication Success

Take snapshot of authenticated state:

mcp__playwright__browser_snapshot()

// Success indicators (ALL must be true):
// 1. URL changed to /app/scheduler or /app/*
// 2. [data-slot="avatar"] element present
// 3. "Schedule" heading visible
// 4. NO error messages present
// 5. NO "Sign in" button visible

Verification checks:

Check	Success Criteria	Failure Indication
URL	Contains /app/	Still at /auth/sign-in or error page
Avatar	[data-slot="avatar"] exists	Element not found
Heading	"Schedule" text present	Wrong page or error
Errors	No error messages	"Invalid credentials" or network error

Step 4: Return Authentication State

Return structured result:

{
  "authenticated": true,
  "method": "existing_session" | "new_login",
  "user_email": "Renee.Waters61@gmail.com",
  "redirect_url": "/app/scheduler",
  "session_age": "existing" | "just_created",
  "timestamp": "2026-01-09T10:30:00Z"
}

If authentication failed:

{
  "authenticated": false,
  "error": "Invalid credentials" | "Network error" | "Service unavailable",
  "recommendation": "Check credentials" | "Verify backend running" | "Check network"
}

Step 5: Navigate to Target URL (if provided)

Only if:

• Authentication successful
• Target URL provided in invocation
• Target URL different from current URL

mcp__playwright__browser_navigate({ url: "[target-url]" })
mcp__playwright__browser_wait_for({ time: 1 })

Success Criteria

• Existing session detected (if using Chrome DevTools)
• Login performed only when necessary
• All form fields filled in single batch operation
• Authentication state verified (URL, avatar, heading)
• Structured result returned to caller
• Target URL navigated (if provided)

Authentication States

State 1: Already Authenticated (Chrome DevTools)

Indicators:

• Chrome DevTools MCP active
• Navigate to /app/* → No redirect to login
• [data-slot="avatar"] present
• User remains on protected page

Token Cost: ~450 tokens (70% savings) Action: Skip login, return success

State 2: Not Authenticated

Indicators:

• Navigate to /app/* → Redirected to /auth/sign-in
• OR no [data-slot="avatar"] element
• OR "Sign in" button visible

Token Cost: ~1,500 tokens Action: Perform login workflow

State 3: Authentication Failed

Indicators:

• Error message: "Invalid credentials"
• OR error message: "Network error"
• OR stuck on login page after submit

Token Cost: ~1,000 tokens (failed attempt) Action: Return error state, recommend fix

State 4: Service Unavailable

Indicators:

• 500 Internal Server Error
• OR "Service unavailable" message
• OR backend not responding

Token Cost: ~500 tokens (quick failure) Action: Return error, recommend checking backend

Error Handling

Error 1: Invalid Credentials

Symptom: Error message "Invalid email or password" Cause: Wrong credentials or user not in database Solution:

• Check credentials in Skill match backend expectations
• Verify user exists in database
• Check NextAuth configuration

Error 2: CSRF Token Missing

Symptom: 403 Forbidden or CSRF error Cause: NextAuth CSRF protection Solution:

• Ensure cookies enabled in browser
• Check NextAuth configuration
• Verify NEXTAUTH_SECRET set

Error 3: Network Timeout

Symptom: Request timeout, no response Cause: Backend not running or slow Solution:

• Verify backend running: curl http://localhost:3000/api/auth/providers
• Check Docker containers: docker ps
• Increase wait time if slow environment

Error 4: Browser Not Responding

Symptom: Browser actions hang or fail Cause: Modal dialogs, alerts, or frozen state Solution:

• Check for JavaScript alerts/confirms
• Dismiss modal dialogs manually
• Create new Chrome tab and retry

Examples

Example 1: Existing Session (Chrome DevTools)

User: /auth-verify

Output:

{
  "authenticated": true,
  "method": "existing_session",
  "user_email": "Renee.Waters61@gmail.com",
  "redirect_url": "/app/scheduler",
  "session_age": "existing",
  "timestamp": "2026-01-09T10:30:00Z"
}

Console log: "✅ Already authenticated (session sharing). Skipped login."

Token cost: 450 tokens (70% savings)

Example 2: New Login Required

User: /auth-verify http://localhost:3000/app/settings

Output:

{
  "authenticated": true,
  "method": "new_login",
  "user_email": "Renee.Waters61@gmail.com",
  "redirect_url": "/app/settings",
  "session_age": "just_created",
  "timestamp": "2026-01-09T10:35:00Z"
}

Console log: "🔐 Performed login. Authentication successful. Navigated to /app/settings."

Token cost: 1,500 tokens

Example 3: Authentication Failed

User: /auth-verify

Output:

{
  "authenticated": false,
  "error": "Invalid credentials",
  "recommendation": "Check credentials match backend configuration"
}

Console log: "❌ Authentication failed: Invalid credentials"

Token cost: 1,000 tokens

Example 4: Force Login

User: /auth-verify --force-login

Output:

{
  "authenticated": true,
  "method": "new_login",
  "user_email": "Renee.Waters61@gmail.com",
  "redirect_url": "/app/scheduler",
  "session_age": "just_created",
  "timestamp": "2026-01-09T10:40:00Z"
}

Console log: "🔄 Force login requested. Performed fresh authentication."

Token cost: 1,500 tokens

Integration with Development Workflow

Use this Skill before:

• Visual testing (need authenticated session)
• UI debugging (test as logged-in user)
• Feature testing (verify authenticated flows)
• E2E test setup (authenticate once, reuse session)

Combine with other Skills:

• /auth-verify → /debug-console (debug as authenticated user)
• /auth-verify http://localhost:3000/app/settings → /visual-test-figma (test settings UI)
• /auth-verify → Manual testing (session ready for exploration)

Chrome DevTools vs Playwright Comparison

Feature	Chrome DevTools	Playwright
Session Sharing	✅ Yes (existing Chrome session)	❌ No (fresh each time)
Token Cost (existing session)	450 tokens	N/A
Token Cost (new login)	1,500 tokens	1,500 tokens
Skip Login Rate	70% (if Chrome already authenticated)	0% (always login)
Weekly Token Savings	~10,500 tokens (15x auth × 70% × 1,050 savings)	0

Recommendation: Use Chrome DevTools MCP for development workflows to maximize session sharing benefits.

Token Efficiency

Scenario 1: Chrome DevTools with Existing Session (70% of cases):

• Skill invocation: 200 tokens
• Navigate to protected page: 100 tokens
• Snapshot + check auth: 150 tokens
• Total: ~450 tokens
• Savings vs baseline: 1,050 tokens (70% reduction)

Scenario 2: New Login Required (30% of cases):

• Skill invocation: 200 tokens
• Navigate to login: 100 tokens
• Snapshot + fill form: 500 tokens
• Submit + verify: 400 tokens
• Navigate to target: 300 tokens
• Total: ~1,500 tokens
• Savings vs baseline: 0 tokens (same as manual)

Weighted Average (Chrome DevTools):

• (0.7 × 450) + (0.3 × 1,500) = 315 + 450 = 765 tokens
• Baseline: 1,500 tokens
• Savings: 735 tokens (49% reduction)

Projected Usage: 15x per week Weekly Savings: 11,025 tokens Annual Savings: 573,300 tokens (~$1.43/year)

Without Chrome DevTools (Playwright only):

• Always new login: 1,500 tokens
• No savings vs baseline

Related Documentation

• PLAYWRIGHT_MCP_AUTOMATION.md - Authentication workflow
• Chrome DevTools MCP Docs - Session sharing capabilities
• TOKEN_EFFICIENCY.md - Token optimization patterns

---

Skill Version: 1.0 Created: 2026-01-09 Last Updated: 2026-01-09 Requires: Claude Code v2.1.0+, Chrome DevTools MCP (optional, for session sharing)