systematic-testing

Validates multi-layer architectures bottom-up by testing domain plugins, proxy routes, browser capture, and dashboard UI independently.

Updated Mar 16, 2026
One-click install
npx skills add https://github.com/adam-s/api-interceptor --skill systematic-testing-adam-s
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-testing
Source: https://github.com/adam-s/api-interceptor/tree/main/.claude/skills/systematic-testing
Command: npx skills add https://github.com/adam-s/api-interceptor --skill systematic-testing-adam-s

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Debugging failures in multi-layer systems is difficult because errors at a lower layer (like a broken route handler) surface as confusing symptoms at higher layers (like an empty dashboard). This Skill enforces a bottom-up validation sequence so each layer is verified before the next is tested, isolating failures to the layer where they actually occur. ## Core Features & Use Cases - Four-Layer Validation Model: Defines L1 (domain plugin routes), L2 (API proxy), L3 (browser and traffic capture), and L4 (dashboard UI) with per-layer curl commands and expected outputs. - Failure Diagnosis Guides: Lists common failure modes per layer, such as 503 browser-not-connected errors, unregistered routes, empty traffic buffers, and CAPTCHA-blocked pages. - Gate Sequence: Provides a four-gate checklist (routes registered, proxy works, real data returned, detail data returned) that must pass before building UI. - Use Case: After generating proxy routes for a new website, run the gate sequence to confirm each layer works before asking the dashboard builder to render the data. ## Quick Start Ask the agent to systematically validate the new domain's API routes layer by layer before building the dashboard.

Frequently Asked Questions about systematic-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a multi-layer API architecture systematically?▼

Test bottom-up: verify the domain plugin routes first (L1), then the API proxy responses (L2), then browser navigation and traffic capture (L3), and finally the dashboard UI (L4). Never test a higher layer until the layer below passes.

How to debug a 503 browser not connected error from an API proxy?▼

A 503 error means the browser is not connected to the proxy server. Connect the browser via the WebSocket endpoint at ws://localhost:3001/browser/stream with a profile and URL, then verify health with curl to /browser/health.

Why is my browser traffic capture buffer empty after navigation?▼

An empty traffic buffer usually means the page's XHR or fetch calls did not fire during navigation. Increase the wait time in the handler, verify the page actually loads content, and clear the buffer with a DELETE request before retesting.

What does a 404 versus 500 error mean when testing proxy routes?▼

A 404 means the route is not registered in register-domains.ts or the path has a typo. A 500 means the handler function threw an error, so check the server logs for the exception details.

When should I fix a lower layer before testing the dashboard UI?▼

Always fix failures at the layer where they occur before ascending. If traffic capture is empty at L3, check the L2 proxy route and L1 handler logic first; building L4 UI on broken lower layers only produces misleading symptoms.