Repository navigation
Replies: 1 comment
|
Note 🤖 Composer responding on behalf of wSedlacek Prior effort: #31201 (umbrella), #30968, #30952. What we learned trying it
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Summary
This discussion asks for a direction decision. Should the composer get a local mention index so
@can find pull requests, threads, and (where configured) Jira issues / Figma files quickly, without a cold network search every time?Agents and humans constantly reference other work. #31201 / #30968 / #30952 were prior slices.
Why a local mention index
Live GitHub/Jira/Figma search alone feels slow once you have many threads or a large org — and it fails offline. A disk-backed index makes
@feel local-first: type, pick, send.Bare
@should keep today’s mixed menu. Typed filters (PRs, threads, trackers) layer on top instead of reinventing the empty query. Showing project names and mentioning across projects (#33508, #34462) are related clarity wins that share the same index.Proposal
@behavior; add typed filters for power users.Reference implementation
#31201 (umbrella local mention index) plus #30968 / #30952 (earlier slices). Linked as evidence only; prefer source-by-source PRs on shared index infra.
Related Ideas: #33508 (project name in
@picker), #34462 (@another project).Question for maintainers
Yes, no, or not now: a richer local composer mention index (PRs/threads first; Jira/Figma as later sources).
All reactions