Issue Links Need Readers, Not Cloners
failed issue capture exposes a joelclaw discovery gap: GitHub issue URLs need an API reader fallback, not clone semantics
A Joel-authored Slack #brain-joel message pointed at Skill Recordings support issue #94, and the capture path tried to treat that issue URL like a cloneable GitHub repo.
That’s the useful part. A GitHub Issue is a record inside a repo, not the repo itself. If the discovery pipeline sees /issues/{id}, it should read the issue through the GitHub API or gh issue view, then preserve the thread, labels, author, timestamps, linked PRs, and comments as the source material.
This matters for joelclaw because support work often lives in boring operational artifacts: GitHub Issues, Slack, Front, and internal repos. The capture system shouldn’t drop those just because the URL isn’t cloneable. That’s a shitty little edge case that turns into memory loss.
Key Ideas
- GitHub Issue URLs need a reader path, not a
git clonepath. gh issue viewis the obvious local fallback when a capture worker seesgithub.com/{owner}/{repo}/issues/{number}.- The GitHub Issues REST API can preserve metadata that matters later: labels, state, author, comments, linked work, and timestamps.
- Slack brain links are useful discovery triggers, but the downstream capture needs source-specific handlers so Obsidian Vault notes don’t become empty shells.
- For joelclaw, this is a concrete discovery-pipeline improvement: classify URL shapes before fetching, then route to the right extractor.