Update to DXD Skills

{
  "name": "derive-client",
  "description": "Use when the user wants a CLI or API client for a website that lacks a public SDK, asks to record browser network traffic into a HAR, reverse-engineer an undocumented API from DevTools/HAR, replace repeated browser automation with direct HTTP calls, or build a quick site-specific tool the way agents capture a flow once then derive a client.",
  "included_files": [],
  "skill_md_contents": "---\nname: derive-client\ndescription: >-\n  Use when the user wants a CLI or API client for a website that lacks a public\n  SDK, asks to record browser network traffic into a HAR, reverse-engineer an\n  undocumented API from DevTools/HAR, replace repeated browser automation with\n  direct HTTP calls, or build a quick site-specific tool the way agents capture\n  a flow once then derive a client.\n---\n\n# Derive Client\n\n## Goal\n\nCapture a real browser session as a HAR, extract the meaningful API calls, and\nderive a small programmatic client (CLI or library) so later work hits HTTP\ndirectly instead of driving a browser every time.\n\n## When to Use\n\nUse this skill when the user asks to:\n\n- Build a CLI or SDK for a site with no public API docs.\n- Record network requests / export a HAR while an agent uses the browser.\n- Reverse-engineer endpoints from DevTools traffic.\n- Stop browser-automating a repetitive web flow and call the underlying API.\n- \"Do the HAR → client trick\" / capture once, reuse as HTTP.\n\nExample prompts:\n\n- \"Record a HAR while ordering on this site, then make a CLI.\"\n- \"Don't keep controlling the browser — derive a client from the network traffic.\"\n- \"Reverse-engineer this app's API from a HAR and wrap it in TypeScript.\"\n- \"Build a quick Uber-Eats-style CLI from the live site.\"\n\n**Do not use** when:\n\n- A public OpenAPI/SDK already covers the need — use that instead.\n- The task is a one-off click with no reuse value.\n- The user only wants a screenshot or UI walkthrough, not an API client.\n\n## Workflow\n\n### 1. Define the target flow\n\nBefore opening a browser, write down:\n\n| Item | Example |\n|------|---------|\n| Goal action | Search restaurants, place order, list inbox |\n| Success signal | JSON list of results, 200 on submit |\n| Auth needed? | Logged-out / cookie / OAuth / API key |\n| Output shape | CLI commands + JSON stdout |\n\nConfirm with the user if the scope is unclear. Prefer the smallest flow that\ncovers the verbs they need.\n\n### 2. Capture traffic as HAR\n\nDrive the browser (agent browser tool, Playwright, or manual DevTools) through\n**only** the target flow.\n\nWhile capturing:\n\n1. Open Network tooling; enable \"Preserve log\" if the page navigates.\n2. Prefer capturing XHR/fetch; note the API host(s) if visible.\n3. Complete the happy path once; avoid unrelated tabs and clicks.\n4. Export **Save all as HAR** (or equivalent) to a local path, e.g.\n   `./captures/<site>-<flow>.har`.\n\nIf the agent can write HAR programmatically (Playwright `recordHar`, CDP\nNetwork domain, browser MCP export), prefer that over a manual export.\n\n### 3. Redact secrets before analysis\n\nTreat every HAR as credentialed until proven otherwise.\n\n1. Copy the HAR to a working file; keep the raw capture out of git.\n2. Scrub values (keep header **names** so auth shape stays visible):\n   - `Authorization`, `Cookie`, `Set-Cookie`\n   - `X-API-Key`, `X-CSRF-Token`, and similar\n   - JWT-shaped strings (`eyJ...`), AWS `AKIA...`, Stripe `sk_live_` / `sk_test_`\n   - Refresh tokens, session IDs in query strings or bodies\n3. Never paste raw HAR into chat, tickets, or commits until redacted.\n4. Document where live credentials will come from at runtime (env vars, existing\n   browser session export the user controls) — do not hardcode them.\n\n### 4. Filter noise and inventory endpoints\n\nHARs are mostly noise. Keep API-shaped traffic; drop the rest.\n\n**Drop:**\n\n- Static assets (`.js`, `.css`, images, fonts, source maps)\n- Analytics / ads / tag managers\n- CORS preflights (`OPTIONS`)\n- Telemetry and error beacons\n\n**Keep and cluster:**\n\n- JSON (or obvious RPC) requests to the product's API hosts\n- One sample per `METHOD + normalized path` (collapse IDs:\n  `/users/42` → `/users/{id}`)\n\nProduce a short inventory table:\n\n| Method | Path | Role | Auth | Request notes | Response notes |\n|--------|------|------|------|---------------|----------------|\n| GET | `/api/search` | search | cookie | `q` query | array of places |\n| POST | `/api/cart` | add item | cookie | JSON body | cart id |\n\nIf the inventory is empty, re-capture with clearer filters or a longer flow —\ndo not invent endpoints.\n\n### 5. Derive the client\n\nFrom the inventory (not from guesses), implement a thin client:\n\n1. **Transport** — `fetch` / `curl` / language HTTP library; one shared request\n   helper for base URL, headers, and error handling.\n2. **Auth** — mirror the capture: cookie jar, bearer token from env, or\n   header set the site used. Fail fast with a clear message if auth is missing.\n3. **Methods** — one function or CLI subcommand per user-facing verb\n   (`search`, `getCart`, `checkout`), named after intent, not raw paths.\n4. **Types** — infer request/response types from real HAR payloads; mark\n   uncertain fields optional rather than inventing.\n5. **CLI surface** (when asked for a tool) — JSON on stdout, human text on\n   stderr, exit non-zero on HTTP/auth failures so agents can pipe to `jq`.\n\nMinimal CLI shape:\n\n```bash\n# Example contract — adapt names to the site\nbun cli.ts search \"fast food\"\nbun cli.ts search \"fast food\" | jq '.[0:10]'\n```\n\nPrefer a few solid commands over a complete mirror of the website.\n\n### 6. Verify against the live API\n\n1. Replay each derived call with the user's real auth (never commit it).\n2. Diff status codes and response shapes against the HAR samples.\n3. Fix path/header/body mismatches until the client matches observed traffic.\n4. Re-run the user's original goal through the client only — **no browser**\n   unless auth bootstrap or CAPTCHA still requires it.\n\nIf replay fails with 401/403, fix auth acquisition; do not fall back to\npermanent browser automation without saying so.\n\n### 7. Hand off\n\nDeliver:\n\n- Client / CLI entrypoint and how to pass auth\n- Endpoint inventory (the table from step 4)\n- Note that private APIs drift — re-capture HAR when calls break\n- Reminder: respect the site's terms; this is for personal/automation use the\n  user is accountable for\n\n## Guardrails\n\n- Never commit HAR files, cookies, tokens, or session dumps to git.\n- Never leave live secrets in generated client code, fixtures, or README examples.\n- Never invent endpoints or fields that did not appear in the capture.\n- Never keep using browser control for the hot path once the client works —\n  browser is for capture and auth bootstrap only.\n- Never claim the client is an official SDK or supported API.\n- Never disable TLS verification or ignore certificate errors to \"make it work.\"\n- Never exfiltrate captured credentials to third-party paste/LLM services; prefer\n  local redaction and local generation.\n- If the site's terms or the user forbid reverse engineering, stop and report\n  rather than proceeding.\n\n## Completion Checklist\n\n- [ ] Target flow and success signal were defined before capture.\n- [ ] A HAR was captured for that flow (or an existing HAR was used).\n- [ ] Secrets were redacted; raw HAR is not committed.\n- [ ] Noise was filtered; an endpoint inventory was produced from real traffic.\n- [ ] A thin client/CLI was derived from the inventory with env-based auth.\n- [ ] Live replay matched HAR status/shape for the supported verbs.\n- [ ] The user's goal runs through the client without browser automation.\n- [ ] Drift and ToS caveats were stated in the handoff.\n"
}