Lockpicker

guide the work from a user-owned browser session outward. do not start by guessing endpoints.

intent

reverse-engineer a legitimate website workflow you're already authorized to perform by capturing your own authenticated browser session, extracting only the auth material you actually need, and converting the request chain into a reusable local script. use this when you want to automate a browser action (upload, publish, schedule, queue) and browser automation feels flaky, or when you need direct authenticated web requests instead. only for services you own or have explicit permission to access.

inputs

• target website url and user account with active session
• one action you can already perform manually in that browser (upload, publish, schedule, queue, etc.)
• browser with devtools (chrome, firefox, edge, safari)
• HAR capture capability (all modern browsers)
• local disk space for auth files and script output (workspace/tmp/ directory)
• optional: reference docs (har-capture-checklist.md, auth-materials.md, request-analysis-patterns.md, common-web-flows.md, safety-boundaries.md)
• optional: bundled helper scripts (extract_har_requests.py, extract_cookie_headers.py, diff_request_shapes.py, scaffold_direct_client.py)

edge cases and constraints:

• if your session expires mid-capture, refresh cleanly from the browser instead of attempting token bypasses
• if the site rate-limits or blocks repeated requests, pause between batches
• if cookies or csrf tokens are stale, pull fresh ones from the browser session
• if the HAR includes chunked uploads or multi-step chains, ensure the full sequence is captured
• if analytics or unrelated api calls clutter the HAR, filter them out during analysis
• store auth material locally only, do not paste into chat unless you explicitly choose to

procedure

step 1: confirm the target action

write down your exact goal in one sentence. include what success looks like.

examples:

• schedule a post with one image (success: scheduled item appears in calendar)
• publish a drafted gallery (success: visible permalink returned)
• upload a file and submit metadata (success: resource id in response)
• create a queued post for later release (success: draft created with status pending)

input: user describes the action and success condition output: written one-liner describing the goal and expected result

step 2: capture a clean HAR

read references/har-capture-checklist.md before starting.

capture one successful run with minimal noise:

• open a fresh browser tab
• open devtools network panel
• enable preserve log
• enable disable cache
• clear any old requests from the panel
• perform only your target action once
• export the HAR file immediately after success

if the site uses chunked uploads, polling loops, or chained mutations, ensure the HAR includes the complete sequence from start to finish.

input: browser, devtools, target website, user credentials output: capture.har file on disk

step 3: extract auth material

read references/auth-materials.md.

collect only what you actually need for replay:

• cookie header (may include session id, auth token, csrf token)
• csrf token (if sent separately in request body or headers)
• authorization header (if api uses bearer tokens or similar)
• key client headers (user-agent, origin, referer if requests depend on them)

save these as local plaintext files in workspace/tmp/ (or user-specified location). do not copy into chat unless you explicitly decide to.

input: HAR file, browser session output: plaintext files in workspace/tmp/ containing cookie, csrf, and auth headers

step 4: isolate the request chain

read references/request-analysis-patterns.md.

break the workflow into stages:

• init (prepare, fetch csrf, poll for availability)
• append/upload (send file or chunk)
• finalize (commit, confirm, create)
• status/poll (check result, fetch ids)
• mutation/create (graphql or rest mutation for the final action)
• confirm/readback (verify user-visible outcome)

for each stage, extract:

• http method
• full url (with query params)
• required headers (only the ones that change behavior)
• request body shape (json, form-data, etc.)
• values copied from previous step responses

ignore decorative noise: analytics pings, passive feed refreshes, unrelated graphql subscriptions, favicon fetches, stylesheet loads.

input: HAR file, list of stages output: request-chain.json documenting each stage with method, url, headers, body, and response fields

step 5: identify reusable vs dynamic fields

classify each field in every request as one of:

• constant (same across all runs until site changes it)
• auth/session-derived (comes from cookies or csrf, changes per session)
• generated per request (nonce, timestamp, request id)
• user-supplied (text, file path, schedule time)
• returned from prior step (media id from upload init, permalink from finalize)

input: request-chain.json from step 4 output: annotated request-chain.json with field classifications

step 6: rebuild as a local script

keep the first script narrow and single-purpose.

shape:

• one script that executes one end-to-end known-good workflow
• plaintext auth files (cookie.txt, csrf.txt, authorization.txt as needed)
• one media file (if uploading)
• one text payload (if submitting content)
• one user-supplied parameter (schedule time, title, etc.)
• json output file that preserves step results (ids, permalinks, status)

use bundled helpers if available:

• scripts/extract_har_requests.py capture.har --contains keyword --out requests.json to filter and summarize HAR requests
• scripts/extract_cookie_headers.py capture.har --contains endpoint --out-dir runtime-auth to pull auth material from a matching request
• scripts/diff_request_shapes.py request-a.json request-b.json to spot dynamic fields by comparing two requests
• scripts/scaffold_direct_client.py request.json --out first_client.py to generate a first-pass replay script

input: request-chain.json, field classifications, auth files output: single-purpose script (python, bash, curl, or other) that replays one full workflow

step 7: test one item first

do not batch yet.

run the script against the live site and validate:

• upload succeeds and returns an id
• returned ids look real (not empty, not error codes)
• final mutation succeeds (no 4xx, 5xx, or api error in response)
• user-visible result exists (check the website, not just the response)

if the test fails, diff the failing request against the corresponding HAR request rather than guessing at fixes.

input: script from step 6, one media file or payload, auth files output: script runs without error, user-visible artifact created (post scheduled, file uploaded, etc.), result ids in output.json

step 8: add queueing or scheduling only after single-item success

once step 7 passes, you can add batch processing.

use a queue manifest for repeated runs (json or csv):

• scheduled_at (timestamp or relative time)
• text (content)
• media_file (path)
• status (pending, sent, success, failed)
• result_ids (whatever the site returned)
• permalink (user-facing url if applicable)
• notes (errors, retries, anything unusual)

prefer small batches (5-10 items) and pauses (30 seconds to 5 minutes) between batches when hitting production sites. monitor for rate limits, account locks, or changed response formats.

input: working single-item script, batch manifest output: queue runner that processes manifest, logs results, pauses between batches

decision points

if the captured har contains stale auth material (expired cookies, csrf tokens issued hours ago):

• do not attempt to forge or refresh tokens programmatically
• instead, recapture the har from a fresh browser session with active login

if the site requires graphql instead of rest:

• follow the same request isolation process
• extract the graphql query, variables, and operationName
• preserve the exact query structure in your script
• treat the variables as either constant or user-supplied based on step 5

if the site uses multi-step upload (init, chunk, finalize):

• capture the full sequence in one har
• identify which response fields (upload id, session id) flow into the next request
• do not attempt to parallelize chunks until single-file success is confirmed

if the workflow involves polling or delayed status checks:

• capture at least one full poll cycle in the har
• extract the poll endpoint, interval, and success condition
• in your script, implement polling with exponential backoff and a maximum timeout
• do not poll more than once per second unless the captured har shows higher frequency

if the site uses client-side encryption, signing, or challenge-response:

• extract the exact algorithm and key material from the har or browser session
• replicate it faithfully in your script
• if the key is per-session, fetch it fresh before each use

if the user cannot or should not store auth material locally (compliance, security policy):

• store only non-secret derived values (request shapes, endpoints, field names)
• prompt the user to paste auth material into the script at runtime
• do not accept auth material via chat or files; use stdin or environment variables

if the site's terms of service prohibit or restrict automated access:

• read references/safety-boundaries.md
• warn the user clearly before proceeding
• document the risk and the user's acknowledgment in comments or a safety log

output contract

success means you deliver:

• a single-purpose script (python, bash, or equivalent) that replicates one manual workflow end-to-end
• plaintext auth files (cookie.txt, csrf.txt, etc.) stored locally in workspace/tmp/ or user-specified directory
• a request-chain.json documenting each stage (method, url, headers, body, response fields)
• a field-classification.json or annotations showing which values are constant, auth-derived, generated, user-supplied, or copied from prior responses
• an output.json from the test run in step 7 showing request/response results and any returned ids or permalinks
• script comments documenting assumptions, dynamic fields, and any known brittleness (e.g., csrf expires in 1 hour, media id format may change)
• optional: a queue manifest template (csv or json) if the user wants batch processing later

outcome signal

you know it worked when:

• the test script in step 7 runs without error and produces a user-visible artifact on the actual website (scheduled post, uploaded file, published item)
• the output.json contains non-empty ids or permalinks that match what you see on the site
• running the script a second time with a different payload produces a different result (not a duplicate of the first run)
• the auth material you extracted (cookies, csrf tokens) remain valid for at least one complete workflow cycle
• comments in your script clearly mark which fields will need updating on the next run (csrf expires, session id rotates) and which are truly reusable
• the user confirms the workflow behaves identically to their manual process in the browser