Creator's demonstrated workflow
Dax explicitly credits James Long (@jlongster) with originating the trick.
Dax's demonstrated sequence is:
- Agents control browsers.
- Ask the agent to record network requests into a HAR file.
- The agent derives a client for the website that is more efficient than controlling the browser every time.
- Build a quick Uber Eats CLI.
The supplied terminal screenshot demonstrates this invocation:
$ bun cli.ts search "fast food" | jq '[.[] | select(.sponsored != true)][0:10]'
The demonstrated input is the search query "fast food". The displayed jq transformation excludes records where sponsored is true and selects [0:10] from the filtered records.
The screenshot shows structured restaurant fields including:
uuidnameratingetadeliveryFeeoffer
One displayed example is McDonald's (Coral Gables), with rating 4.6, ETA Delivered in 12 to 26 min, $0 Delivery Fee, and $5 off $25+.
The screenshot also shows a human-readable comparison at 2:20 AM of restaurants described as accepting Uber Eats orders. It concludes: Best combination of speed and rating: McDonald’s or Papa Johns.
The sources do not identify the browser-control product, HAR-recording mechanism, request format, authentication method, client implementation, Uber Eats endpoint, client library, or reliability boundary.
XSkills operational adaptations
The following execution procedure is an XSkills operational adaptation. Its preflight, validation, fallback, and implementation details are not stated by Dax or James Long.
Inputs
XSkills operational adaptation - collect before execution:
- An authorized, narrowly scoped read-only retrieval task.
- The authorized browser context for that task.
- The specific retrieval input, such as a search query.
- The fields required in the output.
- Any requested local transformation or comparison criteria.
A HAR is not an input prerequisite: it is produced by the browser capture step below.
1. Preflight browser control and HAR capture
XSkills operational adaptation - action: Confirm that the execution environment can both:
- control the authorized browser context needed for the scoped task; and
- record that browser run's network requests to a HAR file.
XSkills operational adaptation - check: Confirm that the capture capability can save an inspectable HAR artifact for a test or completed scoped run.
XSkills operational adaptation - output: Record either browser control available and HAR capture available, or the unavailable capability.
XSkills operational adaptation - fallback: If browser control is unavailable, do not attempt the demonstrated automated capture sequence. Use an authorized manual browser workflow for the read-only task, if available, or stop. If HAR capture is unavailable, do not infer network requests; use the authorized browser workflow without deriving a client, or use an approved documented read-only interface if one is available.
XSkills operational adaptation - stop condition: Stop client derivation when either browser control or HAR capture is unavailable and no authorized non-derived read-only fallback is available.
2. Capture the browser run to a HAR
XSkills operational adaptation - action: Use browser control to perform only the scoped read-only task. Record that run's network requests to a HAR file.
XSkills operational adaptation - check: Confirm that the HAR contains captured requests and responses associated with the completed task and that the observed browser result can be associated with captured material.
XSkills operational adaptation - output: Produce a task-specific HAR, plus a concise record of the input, capture time, and observed browser result.
XSkills operational adaptation - fallback: If the relevant request or response is absent, perform at most one additional minimal capture run for the same scoped task. Do not guess missing request details.
XSkills operational adaptation - stop condition: Stop if the capture does not provide sufficient observable information to associate a request or request sequence with the needed result.
3. Derive a narrow client from the capture
XSkills operational adaptation - action: Inspect the HAR to identify the observed request, or ordered request set, that supplies the scoped result. Map only observed inputs, response fields, and dependencies needed for that retrieval.
XSkills operational adaptation - action: Implement a narrow client around that observed mapping. Keep retrieval, local filtering, and presentation separate.
XSkills operational adaptation - check: For the same input and authorized browser context, compare available stable fields and result counts from the derived client with the browser result. Report differences rather than assuming equivalence.
XSkills operational adaptation - output: Produce a client design or implementation documenting its input, observed request dependency, parsed fields, retrieval timestamp, and validation result.
XSkills operational adaptation - fallback: If the required request depends on state that cannot be mapped from the authorized capture without guessing, retain browser-based retrieval for the scoped task rather than inventing request details.
XSkills operational adaptation - stop condition: Stop if the derived client cannot reproduce enough of the scoped result to support the requested output.
4. Produce the demonstrated Uber Eats CLI output only when it is the scoped task
XSkills operational adaptation - action: When the authorized task is specifically the Uber Eats search shown in the source, preserve the demonstrated tool sequence:
bun cli.ts search "fast food" | jq '[.[] | select(.sponsored != true)][0:10]'
XSkills operational adaptation - action: Have the CLI emit structured result records. Apply the demonstrated filter and selection only when sponsored is present and the requested transformation is specifically to exclude sponsored == true and retain [0:10].
XSkills operational adaptation - check: Confirm that output fields are returned by the derived client. Do not synthesize UUIDs, ratings, ETAs, delivery fees, offers, availability, or rankings.
XSkills operational adaptation - output: Return structured restaurant records and, if requested, a separately labeled comparison based only on returned fields.
XSkills operational adaptation - fallback: If sponsored is absent, do not substitute another field or silently filter records. Return available records and state that the demonstrated filter cannot be applied.
XSkills operational adaptation - stop condition: Stop a speed-and-rating comparison when the returned data lacks the fields needed for those criteria.
XSkills operational adaptation - portable alternative: If Bun or jq is unavailable, implement the explicitly demonstrated input, sponsored != true filter, and [0:10] selection in the local environment. This portability measure is from XSkills, not a tool choice demonstrated by Dax.
Execution record
XSkills operational adaptation - output: Produce a concise record containing:
- scoped task and input;
- browser-control and HAR-capture preflight result;
- HAR capture time;
- observed request-to-response mapping, excluding sensitive values;
- client input and returned field names;
- applied local transformation;
- validation result against the browser run; and
- known discrepancies, gaps, fallbacks, or stop conditions.
XSkills safety adaptations
The following boundaries are XSkills safety adaptations. They are not stated as requirements by Dax, James Long, Uber Eats, or the supplied sources.
Authorization and read-only scope
XSkills safety adaptation - action: Use this process only when the operator is authorized both to perform the scoped task and to inspect its network activity.
XSkills safety adaptation - action: Limit the derived client to read-only retrieval and local presentation. Do not use it for ordering, payment, account changes, cancellation, or other account mutation.
XSkills safety adaptation - stop condition: Stop when authorization is absent, the intended use exceeds the agreed read-only scope, or the task requires a consequential action.
HAR and secret handling
XSkills safety adaptation - action: Treat HAR files as sensitive artifacts. Before storage, sharing, logging, or committing, sanitize cookies, authorization headers, bearer tokens, session identifiers, API keys, addresses, payment information, and other private account data.
XSkills safety adaptation - action: Do not embed captured secrets in source code, command lines, fixtures, CLI output, or error messages.
XSkills safety adaptation - check: Inspect generated logs, test data, and output for secret and personal-data leakage before distribution.
XSkills safety adaptation - fallback: If necessary runtime state cannot be handled without exposing sensitive material, retain the task in the authorized browser context or use an approved documented interface.
XSkills safety adaptation - stop condition: Stop if safe handling of required session or account data cannot be maintained.
Rate limits, validation, and non-evasion
XSkills safety adaptation - action: Use conservative request volume, explicit timeouts, and bounded retries. Validate response status and expected response shape before parsing.
XSkills safety adaptation - action: Treat availability, delivery time, fees, offers, and ordering status as time- and context-dependent. Include a retrieval timestamp when reporting such values.
XSkills safety adaptation - action: Do not bypass authentication, access controls, CAPTCHAs, bot protections, rate limits, or other restrictions. Do not alter the client to evade them.
XSkills safety adaptation - fallback: On access denial, rate limiting, CAPTCHA, unexpected response shapes, or inconsistent results, stop automated retries, report the condition, and return to the authorized browser workflow or an approved documented interface.
XSkills safety adaptation - stop condition: Stop immediately when a protection mechanism or access restriction is encountered; do not attempt evasion.
Source attribution
Sources: Dax's X post at https://x.com/thdxr/status/2078727284865827140 and the supplied attached terminal screenshot. Independently compiled by XSkills from the supplied sources. Dax Raad did not author or review this skill. Attribution does not imply endorsement.