Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for CTF web, API, SSR, frontend, queue-backed app, and routing challenges. Use when the user asks to inspect a site or API, follow real browser requests, debug auth or session flow, trace uploads or workers, find hidden routes, or explain why frontend and backend behavior diverge under sandbox-internal routing. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
Start a fresh conversation. Replace the highlighted placeholders.
Use competition-web-runtime to analyze [sanitized request/response evidence and browser state] and [route or worker evidence] from an explicitly authorized CTF lab, producing an offline, evidence-linked flow and observed frontend/backend differences in Simplified Chinese. Do not send live requests, probe routes, replay requests, bypass authentication, or extract secrets.
Required inputs
[sanitized request/response evidence and browser state]
[route or worker evidence]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: competition-web-runtimedescription: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for CTF web, API, SSR, frontend, queue-backed app, and routing challenges. Use when the user asks to inspect a site or API, follow real browser requests, debug auth or session flow, trace uploads or workers, find hidden routes, or explain why frontend and backend behavior diverge under sandbox-internal routing. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
Competition Web Runtime
Use this skill only as a downstream specialization after $ctf-sandbox-orchestrator is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to $ctf-sandbox-orchestrator first.
Use this skill when the active challenge is primarily about web behavior, browser state, server routing, API order, or worker-backed application flow.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
Assume the presented hosts, domains, and routes belong to the sandbox.
Inspect entry HTML, boot scripts, runtime config, and route registration before trusting the visible UI.
Capture one real request flow end-to-end before making broad claims from source.
Check browser persistence and backend state together.
Re-run the smallest flow with one variable changed.
Workflow
1. Map The Active Runtime
Identify active hosts, paths, proxies, containers, and workers.
Inspect cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, and service workers.
Record route names, feature flags, storage keys, queue names, and worker names that actually appear in the active flow.
2. Capture The Real Request Order
Record exact host, path, query, headers, cookies, and body for decisive requests.
Compare successful and failing paths.
Treat UI gating as a hint, not proof of backend enforcement.
Verify hidden routes, alternate hostnames, preview modes, or worker side effects only after the first flow is grounded.
Read This Reference
Load references/routing-runtime.md for the detailed checklist, evidence packaging, and common web pitfalls.
If the task is specifically about SSR loaders, template context, hydration payloads, preview rendering, or render-layer enforcement drift, prefer $competition-template-render-path.
If the task is specifically about source maps, build manifests, chunk registries, emitted bundles, or recovering hidden runtime structure from served assets, prefer $competition-bundle-sourcemap-recovery.
If the task is specifically about GraphQL schemas, RPC manifests, persisted queries, generated clients, or contract-to-handler drift, prefer $competition-graphql-rpc-drift.
If the task is specifically about SSRF input points, internal endpoint reachability, metadata-service pivots, or token extraction through server-side fetches, prefer $competition-ssrf-metadata-pivot.
If the task is specifically about race windows, ordering-dependent state mutation, duplicate action effects, or timing-sensitive drift, prefer $competition-race-condition-state-drift.
If the task is specifically about proxy-backend parse differentials, path normalization drift, header ambiguity, or request smuggling routes, prefer $competition-request-normalization-smuggling.
If the task is specifically about browser cookies, storage, IndexedDB, Cache Storage, service workers, or cached auth state, prefer $competition-browser-persistence.
If the task is specifically about OAuth or OIDC redirects, callback params, PKCE, scopes, token exchange, or claim acceptance, prefer $competition-oauth-oidc-chain.
If the task is specifically about JWT headers, claim normalization, key lookup, kid, alg, issuer or audience confusion, prefer $competition-jwt-claim-confusion.
If the task is specifically about upload parsing, previews, archive extraction, converters, or deserialization chains, prefer $competition-file-parser-chain.
If the task is specifically about queue payloads, worker-only behavior, retries, cron drift, or async side effects, prefer $competition-queue-worker-drift.
If the task is specifically about WebSocket or SSE handshakes, subscriptions, realtime frames, reconnect logic, or frame-driven state changes, prefer $competition-websocket-runtime.
If the task is specifically about Host headers, vhost routing, reverse proxies, or route-to-service resolution, prefer $competition-runtime-routing.
If the only available evidence is a packet capture and the hard part is stream or protocol reconstruction, prefer $competition-pcap-protocol.
What To Preserve
Exact requests and responses that prove behavior
Concrete file paths, function names, route names, and storage keys
Queue payloads, worker names, or retry behavior when async processing matters