Ayobami Adegoke 8cbab6823e fix(linkedin-search): reject detail URLs on other hosts instead of fetching the posting with that number (#500) ...

normalizeId took the first 6+-digit path segment from ANY URL, so a
Greenhouse or Lever apply link - the kind a posting's own page hands out
and a user pastes back into detail - was reduced to that number and the
handler fetched jobPosting/<number> from LinkedIn: whatever job carried
that id came back with exit 0, or NOT_FOUND if none did, never an error
about the input. Driving the real handler with a stubbed fetch,
https://boards.greenhouse.io/acme/jobs/4567890 requested
.../jobPosting/4567890. Every other portal CLI rejects an off-host detail
URL with BAD_ID (the #447 shape); linkedin was the one still trusting the
digits.

Parse URLs for real: a linkedin.com host (apex or any subdomain, scheme
optional) plus a /jobs/view/<slug->id path yields the id; other hosts,
look-alike and userinfo hosts, and linkedin.com profile or search URLs
exit 1 with the stderr-JSON BAD_ID contract before any request. Bare
ids, URNs, and slash-free title slugs are unchanged.

Four new normalizeId cases and a new detail-input.test.ts that drives
runDetail and the CLI with fetch stubbed; five cases fail on the old
pattern.

2026-09-27 19:28:16 +02:00

..

cli

fix(linkedin-search): reject detail URLs on other hosts instead of fetching the posting with that number (#500)

2026-09-27 19:28:16 +02:00

SKILL.md

fix(linkedin-search): drop the never-delivered applyUrl detail field

2026-08-19 20:34:35 +02:00

url-reference.md

Add country-agnostic linkedin-search skill (#20)

2026-06-29 20:26:19 +02:00