Claude-skill-registry auth-verify
Authenticate to web app and verify session state with Chrome DevTools session sharing
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/auth-verify" ~/.claude/skills/majiayu000-claude-skill-registry-auth-verify && rm -rf "$T"
skills/data/auth-verify/SKILL.mdAuthenticate 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:
- Check auth, navigate to /app/scheduler if authenticated/auth-verify
- Check auth, navigate to specific page/auth-verify http://localhost:3000/app/settings
- Force new login even if session exists/auth-verify --force-login
Prerequisites
- Chrome DevTools MCP enabled:
(for session sharing)claude --chrome - Application running on localhost:3000
- Test credentials available:
/Renee.Waters61@gmail.compassword
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
present → Already authenticated ✅[data-slot="avatar"] - If URL redirected to
→ Not authenticated ❌/auth/sign-in - 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
flag provided--force-login - 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 | Still at or error page |
| 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
→ No redirect to login/app/*
present[data-slot="avatar"]- User remains on protected page
Token Cost: ~450 tokens (70% savings) Action: Skip login, return success
State 2: Not Authenticated
Indicators:
- Navigate to
→ Redirected to/app/*/auth/sign-in - OR no
element[data-slot="avatar"] - 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 as authenticated user)/debug-console
→/auth-verify http://localhost:3000/app/settings
(test settings UI)/visual-test-figma
→ Manual testing (session ready for exploration)/auth-verify
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)