Build a workflow that finds which release version a pull request first shipped in, starting from a plain-language description of the change rather than a PR number. It's for anyone who knows what changed but not when it went out — support, release managers, engineers tracing a fix — working against a specific GitHub repo. Trigger it from a web page (space-members only) where the user types a description of the change (e.g. "rate limiting on webhook ingest"). The page calls two backend API routes directly: A search route that uses an LLM (Claude — or your preferred model provider) to turn the description into keyword queries, searches merged PRs in the target repo, then has the model rank the matches and return each with a short blurb and author, so the user can pick the right one when several fit. A resolve route that, once the user picks a candidate, walks the repo's GitHub Releases oldest-first and uses the compare API to find the first release tag whose history contains the PR's merge commit — that tag is the first version it shipped in. Handle the "merged but not released yet" case gracefully. Add caching for speed, backed by persistent storage: a cron-scheduled step that snapshots the releases list periodically; a step (off the response path) that stores each confirmed PR→version result so repeat lookups of the same PR are instant; and a step that caches resolved author names so you only look up authors you haven't seen. Keep "not released yet" answers verified against live data so a stale snapshot can't produce a wrong version. Use GitHub (or your team's code host) for search, pulls, releases, compare, and user lookups via a connector scoped to the target repo, and an LLM provider (Anthropic Claude — or your choice) for query derivation and ranking. The workflow is read-only against external services and writes only to its own cache storage. Tools used: GitHub, Anthropic Claude