Roadmap

[shouze]

This issue tracks the high-level feature backlog for github-code-search. It is meant to be a living document — priorities may shift as feedback comes in.

Priority: 🔴 high · 🟡 medium · 🟢 nice-to-have

---

🔍 TUI — Advanced filtering

The current filter mode (f) only matches against file paths. This category extends it.

• 🔴 Regex support in path filter — allow the filter bar to accept regular expressions in addition to plain substrings
• 🔴 Filter by extract content — search within the displayed code fragments, not just file paths
• 🟡 Filter by repository name — a dedicated filter mode scoped to repo names (symmetric to the path filter)

🗂 TUI — Navigation & result management

• 🔴 Global fold / unfold — a single shortcut to collapse or expand all repositories at once (complements the existing ← / → per-repo shortcuts)
• 🟡 Team section selection — a / n on a team section header to select or deselect all its repositories in one keystroke (natural extension of --group-by-team-prefix)
• 🟡 Fast navigation — gg / G (top / bottom) and Page Up / Page Down; currently only line-by-line scrolling is supported
• 🟢 Open in browser — o shortcut on a result to open its GitHub URL directly from the TUI (open / xdg-open)

👥 Team grouping — Exclusions

• 🔴 Exclude teams — two complementary surfaces:
  • TUI: interactively hide/disable a team section
  • CLI: --exclude-teams option for non-interactive mode (also reflected in the replay command)

🤖 Natural language search (experimental)

A two-stage approach that extends the existing keyword-based search workflow.

Stage 1 — NL → GitHub query translation

Translate a plain-English description into a valid GitHub Code Search query using an LLM. Example:

"find all places where we swallow exceptions without logging"
→ catch -throw -logger language:typescript

Stage 2 — Semantic post-filtering

After fetching results from the GitHub API, re-rank or filter the returned code fragments by semantic similarity to the original query — surfacing the most relevant matches above GitHub's default relevance ordering.

The two stages are independent and can be enabled separately via a --natural-language flag (stage 1) and a --semantic-rerank flag (stage 2).

Dependencies

Dependency	Purpose	Notes
LLM provider (OpenAI, Anthropic, Ollama, …)	Query translation — stage 1	Configured via env var or config file
Embeddings model (OpenAI, local via Ollama, …)	Semantic re-ranking — stage 2	Optional; falls back to GitHub relevance order
GITHUB_CODE_SEARCH_AI_KEY + GITHUB_CODE_SEARCH_AI_PROVIDER env vars	Provider configuration	New env surface, no hard dependency on a specific vendor
Persistent config file (~/.githubcodesearchrc)	Store provider preferences across invocations	Shared dependency with the Developer experience section

⚠️ This feature introduces an optional external dependency. When no AI provider is configured the tool behaves exactly as today — there is no silent fallback or unexpected network call.

• 🟢 NL → query translation (stage 1)
• 🟢 Semantic post-filtering / re-ranking (stage 2)

🛠 Developer experience

• 🟡 Shell completions — bash, zsh and fish completions for subcommands and options (Commander has native support for this)
• 🟢 Persistent config file — ~/.githubcodesearchrc to avoid re-passing the org, recurring exclusions, etc. on every invocation
• 🟢 Additional syntax highlighting — PHP, C/C++, Swift, Terraform/HCL, Dockerfile (the regex-based rules system is trivially extensible)

---

Contributions welcome — feel free to open a dedicated issue for any item you'd like to discuss or implement.