Convert one observed browser journey into the narrowest reusable client that performs the requested job. Treat the HAR as sensitive evidence, not as source code or a durable project asset.
-
Define the capability contract. Name the exact user-visible workflow, its inputs and outputs, and whether it reads or mutates external state. Default to read-only discovery and smoke tests. Ask before exercising purchases, messages, deletes, submissions, account changes, or other consequential mutations.
-
Capture a representative journey. If the user supplied a HAR, use it. Otherwise, use an available browser-control capability or guide the user through browser developer tools. Record only the relevant journey, include one pagination or detail-view transition when applicable, and avoid unrelated account activity.
-
Contain the raw HAR. Work from a temporary or ignored local path. Add *.har to the target repository's .gitignore when a HAR is stored inside it. Never paste raw headers, cookies, tokens, addresses, payment data, or response bodies into chat, logs, generated code, tests, commits, or skill resources. Read references/security.md before handling authenticated or personal traffic.
-
Produce a reduced inventory. Run:
python3 scripts/summarize_har.py <capture.har> --output <summary.json>
Use the summary to group repeated endpoints and identify likely application traffic. It removes body values and normalizes obvious identifiers, but endpoint paths can still contain site-specific names, so keep the summary local and inspect it before sharing. Inspect raw entries locally only when a missing detail is necessary. Ignore analytics, ads, fonts, images, source maps, telemetry, and static bundles unless the requested workflow genuinely depends on them.
-
Select the minimum endpoint set. Trace the calls responsible for the visible result. Record the method, normalized path, query names, request and response shapes, pagination, required non-secret headers, auth mechanism, rate-limit signals, and error behavior. Do not build a generic replay engine or copy every observed endpoint.
-
Generate a project-native client. Match the target repository's language, runtime, package manager, conventions, and test stack. Expose semantic methods such as searchRestaurants() rather than raw HAR replay. Inject base URLs and credentials at runtime, validate response boundaries, provide actionable errors, and keep browser automation as a fallback for unsupported or challenged flows.
-
Handle authentication explicitly. Prefer a documented API, OAuth, or an existing project credential. If the observed application requires browser-session material, keep it in an environment variable or OS-backed secret store and explain its expiry. Never automate CAPTCHA or bot-check bypasses, persist captured cookies in source, or silently broaden access beyond the user's current account and requested workflow.
-
Test at two levels. Add deterministic tests using redacted fixtures or schema-only samples, then run one authorized live read-only smoke test. Compare the client result with the browser UI for at least two meaningful fields. For mutations, test serialization locally and perform a live call only with explicit user approval.
-
Deliver a reusable capability. Provide the client location, supported operations, runtime configuration names, validation evidence, known expiry or drift risks, and the browser fallback. Do not claim completion from a successful HTTP status alone; confirm that the returned data matches the visible workflow.
Resolve script paths relative to this skill directory, not the user's project.
Stop and keep the browser workflow when the site relies on CAPTCHA, device-bound signing, opaque rotating request signatures, prohibited access, or endpoints too unstable to validate safely. Explain the constraint and retain the captured journey only as temporary diagnostic evidence.
