Spider King

Spider King

Mission

Turn hostile web clients into stable protocol collectors.

This is a pure-web protocol-recovery skill, not a browser-automation skill and not an APK/mini-program reverse skill. Use browser tooling only to gather web evidence. Deliver raw HTTP plus narrow local sign, bootstrap, decode, or transport helpers. If the primary target is APK, native app, or mini-program, state out-of-scope instead of inventing a web dual-browser first-pass.

Non-Negotiables

• Before any tool choice on a fresh task, run the Auto Judge Card in this file and references/mcp-routing-playbook.md: decide intake, whether a browser is needed, which baseline host to use, and whether js-reverse is required. Do not open tools first and rationalize later.
• Start every fresh web target classified as live-target with sequential evidence for both roles before claiming that live web target is understood: fingerprint-baseline then debugger-trace. Default means are chrome-devtools then js-reverse. When fingerprint pressure is proved, the baseline host may be Camoufox or another managed profile; debugger-trace still prefers js-reverse only after a real handoff and only when a debug attach surface exists. This skill's primary scope is web clients only; APK, native app, and mini-program primary tasks are out of scope and must not invent paired-browser proof as ceremony. If a required role or its available means is missing for a web live-target, report the blocker before claiming the live target is understood.
• Keep browser evidence collection target-serial: at most one tool family may be TARGET_ACTIVE, and never place both families in the same parallel tool batch. Apply the handoff gate in references/tool-playbook.md; preserve unique unreplayable state with RETAINED_EXCEPTION instead of destroying it for cleanup.
• For compact-replay and collector, deliver a browser-free Python run path. Never use browser automation, Playwright, Selenium, CDP page-driving, page-context fetch, browser profiles, or manual browser state as the final replay path or fallback.
• Prefer pure Python for HTTP, orchestration, parsing, retries, persistence, and output.
• Keep JS or WASM only as a tiny local helper when a verified Python port would currently be riskier. Helpers must not depend on live window, document, browser storage, page driving, or manual clicks.
• A local bootstrap executor may emulate required host semantics, but Python must own live HTTP. State clearly whether delivery is browser-free only or fully runtime-free.
• Recover one stable business request before pagination, concurrency, submission, or runtime shrinking.
• Back every conclusion with the evidence its declared shape requires. Require repeated live replay only when claiming current live acceptance. Keep raw sensitive values local; redact credentials, tokens, personal data, and cookie values from chat, reports, and version control.
• Never hardcode rotating state before proving its writer, slot, scope, expiry, and refresh path.
• Preserve one session chain for bootstrap-heavy flows until cross-session reuse is proven.
• Stop only when the declared shape passes its capability-specific gate or a real external blocker is proved. Do not label evidence or local-proof as a collector, and do not disguise incomplete automation as a temporary collector.
• compact-replay and collector delivery include a PyCharm right-click runnable Python entrypoint, normally project-root main.py or collector/main.py, with no required terminal arguments. evidence and local-proof do not require an entrypoint unless the requested artifact is executable code.
• Route only MCP families confirmed available in the current agent tool registry or schema. Source trees on disk are not availability.
• Passive wire stores such as Reqable or HAR may coexist with a browser TARGET_ACTIVE owner, but they do not replace web live first-pass evidence and must not become the final run path.
• compact-replay and collector must remain free of MCP browser runtime, page driving, and profile-bound operation.

For failure-shaped counterexamples, read references/anti-patterns-playbook.md. Before packaging a result, apply only the matching capability gate from references/delivery-gate-playbook.md.

Lightweight Dispatch

Use these labels internally to keep the first move small. Do not force a rigid machine header in normal user replies.

Default to the smallest shape that answers the user. User-provided HAR, packet capture, request text, JS/WASM, cookie/token sample, fixed vector, or existing project artifact starts as evidence or local-proof; do not open a browser just to satisfy live-target ceremony. A bare URL by itself does not authorize browser navigation, live replay, writes, account/session use, dependency installation, or broad collection.

Route names describe the current capability owner, not the gate family: evidence-reuse, chromium-recon, browser-hook, static-ast, env-patch, iv8-local-runtime, verifier, transport, pure-python-rebuild, or python-collector. Run one route until it returns evidence or a named blocker. If two routes look plausible, pick the smaller offline route first and record what proof would justify escalation.

Before any route writes files, sends live egress, executes target-supplied code, uses account/session state, installs dependencies, or changes runtime state, apply the compact contract in references/provider-work-order.md.

Fast Routes and Ownership

Use a focused route when the goal is already narrow. Do not restart full unknown-target discovery for these cases.

Focused profile rules:

• Browser-hook, static-ast, and env-patch routes may skip the full unknown-target Startup Gate ceremony only for artifact-only or already-proved known-boundary work, but still require reversible changes and secret-safe logs. Structure-only static AST detection may begin from the supplied file alone; require fixed samples before behavioral claims or dynamic escalation. If the route needs fresh interaction with a current target, classify it as live-target and apply the paired sequential browser rule above.
• If a profile uncovers missing bootstrap, session, transport, decode, or pagination state, exit the profile and return to the Universal Reverse Loop.
• Process artifacts go under the executing project js_reverse_cache/tasks/<task-id>/ (task.json, network.jsonl, runtime-evidence.jsonl, handoff.json, fixtures/, report.md). Delivery proof remains analysis/proof_manifest.json and related analysis files. Never write task secrets into this skill directory. Apply references/project-artifact-contract.md before the first save or promotion.

Auto Route Card

Use this before tool choice. It does not relax any delivery gate. Full signal tables and host-upgrade rules live in references/mcp-routing-playbook.md and references/startup-triage-playbook.md.

Auto Judge Card (signal-driven)

Judge in this order and record the branch before the first target action:

1. Intake: enough offline samples and no live acceptance need -> artifact-only; bare URL or fresh page/session proof -> web live-target; same target/env/goal -> continuation; APK/app/mini-program primary -> out of scope.
2. Browser needed?: pure offline explain/restore/fixed-vector work -> no browser; need current request/page/wire proof -> baseline host; known-boundary debugger only -> js-reverse after attach owner is confirmed.
3. Baseline host: default chrome-devtools; upgrade to Camoufox/managed host only on fingerprint pressure or clean-baseline failure; never default Camoufox for ordinary low-risk work.
4. Debugger: after a candidate business request exists and attach is available, sequential handoff to js-reverse; if attach is missing, export artifacts, record debugger_attach_gap, and continue offline.
5. Stop browser early: once the real request, mutation point, and rebuild path are proved, leave browser MCP and finish in pure Python.

Default live sequence

capability snapshot
  -> Auto Judge
  -> fingerprint-baseline (chrome-devtools default; Camoufox/managed host only on pressure)
  -> sequential handoff
  -> js-reverse when attach exists
  -> offline rebuild + delivery gate

Startup Gate

Complete and report this gate before deep analysis. Expanded checklists stay in references/startup-triage-playbook.md.

0. Intake mode

Declare one mode before tool use:

• live-target: current web page/endpoint needs fresh browser and wire evidence; use sequential role order
• artifact-only: only saved requests/source/tokens/samples; mark live acceptance unproven
• continuation: same target/env/goal; reuse the current gate and reopen only changed surfaces

1. Environment and tools

Snapshot installed MCP families, attach/debug availability, and optional passive wire stores. Route only confirmed tools. Missing optional families are gaps, not ceremony.

2. Family triage

Tag the smallest dominant gate family (signer-gated, transport-gated, verifier-gated, decode-gated, session-gated) from current evidence, then open only that path.

3. Delivery intent

State the declared shape (evidence, local-proof, compact-replay, collector) and stop at that gate. Do not brand incomplete automation as a temporary collector.

Minimal Intake

Start immediately when the user provides a target page or API URL, site and collection goal, captured request, JS or WASM sample, cookie or token sample, or packet capture. Choose the intake mode before deciding whether browser evidence is required.

Ask only for missing information that changes implementation: target fields, collection scope, output format, login requirement, and whether dedupe, resume, or incremental sync is required.

For read-only evidence or local-proof requests, ask only for the missing sample, vector, trigger action, or source path. Delay project-root, retention, live replay, and request-budget questions until the next action would write, execute target code, or contact the target.

Before implementing a compact-replay or collector, use the conditional implementation brief in references/provider-work-order.md when multiple implementation forms remain viable or the next step would widen the currently resolved runtime, dependency, writable-scope, or live-authority boundary. Do not turn that brief into a mandatory approval ceremony for evidence, local-proof, or an implementation choice the user already made.

Universal Reverse Loop

Use references/workflow-overview.md as the short execution map and references/tool-playbook.md for tool selection.

Phase 0: Fingerprint

• Capture a clean baseline before broad hooks when observer effect is possible.
• Distinguish decoy from real endpoint, transport gate from application gate, visible param from wrapper rewrite, bootstrap asset from data API, and single request from stateful transcript.
• Identify plain JSON, GraphQL, WebSocket, protobuf, binary envelope, encrypted response, glyph mapping, JSVMP, or host-bound runtime early.
• Choose the smallest next proof, not the largest bundle dump.

Phase 1: Prove the real request

• Follow redirects and wrapper or compatibility pages.
• Map entry, bootstrap, list, detail, submission, verifier, warm-up, telemetry, download, risk-control, and async export or report job routes separately.
• Capture exact URL, method, query, body bytes, headers, outbound Cookie header, response shape, and initiator.
• Treat pagination pivots and challenged document replays as part of the protocol contract.

Deliver one confirmed request on the real business path.

Phase 2: Isolate moving state

Classify every changing part: timestamp, nonce, signed query or body, rotating header or cookie, wrapper field, operation name, cursor, bootstrap artifact, decode key, glyph map, session secret, profile baseline, sparse delta, counter, heartbeat, elapsed-time dependency, media key, page exception, account state, or host semantic. When the surface is an export or signed open platform style API, also bucket fields into business, static app, server-issued, and per-request dynamic classes before designing regeneration.

Prove cookie provenance and distinguish server-issued artifacts from locally minted filler. Treat page text about session participation as a hypothesis only until wire behavior confirms it. When login is only the first gate, validate tenant, role, and data-range with a final identity reread before export; see references/multi-context-session-playbook.md. Keep stored jar state separate from the authoritative outbound Cookie header when they diverge.

Phase 3: Locate the canonical mutation point

Trace in this order:

1. transport wrappers, interceptors, beforeSend, fetch, Ajax, XHR, worker, or message boundaries
2. bootstrap scripts and inline payloads
3. exposed helpers and returned child objects
4. WASM exports or inner serializer, packer, signer, or decoder primitives
5. server-returned challenges and response-side refresh fields
6. frame serializers, protobuf parsers, handshake transcripts, and key schedules

The canonical mutation point is where the wire-shaped payload actually changes, not where business code creates a placeholder.

When a named digest is present, prove it on fixed inputs before trusting a standard library. Prefer environment-selected digest constants and the browser branch over UI or function names; route to references/crypto-patterns.md.