# Org Search

> Experimental jbcontext org-wide semantic search across multiple repositories

- Skill: `jetbrains/org-search` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jetbrains/org-search`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jetbrains/org-search/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jetbrains (https://skillmd.com/u/jetbrains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jetbrains/org-search

---


Use this skill to research `$ARGUMENTS` across all available repositories, especially when the answer may live outside the current repo.

## Use cases for cross repository search

- **Find reusable components, libraries, or utilities.** Before writing new code, check whether another repo already exposes a client, helper, or shared package that solves the problem.
- **Locate prior art and reference implementations.** Discover how other teams have already solved a similar design problem (e.g. retry logic, feature flag wiring, pagination, caching, auth middleware) so a new implementation can follow established patterns.
- **Trace cross-service API consumers and producers.** Given an endpoint, RPC, topic, or event name, find every repo that publishes or consumes it to understand blast radius before changing a contract.
- **Find usages of a shared library, type, or symbol across the org.** Useful for migrations, deprecations, and breaking-change planning — answer "who imports this?" when the symbol is defined in a shared package.
- **Investigate unfamiliar systems and code ownership.** When a request mentions a service, table, or feature you don't recognize, search the org to find the owning repo, its README, and entry points before asking a human.
- **Audit security, compliance, or anti-pattern occurrences.** Sweep all repos for risky patterns (hardcoded secrets shapes, deprecated crypto, banned dependencies, unsafe SQL) to scope remediation work.
- **Discover configuration and infrastructure examples.** Find how other services configure the same tool (CI workflows, Dockerfiles, Terraform modules, Helm charts, observability setup) to copy a known-good baseline.
- **Cross-reference schemas, protos, and shared data models.** Locate the canonical definition of a type or message and every repo that depends on it.
- **Reproduce or correlate bugs across services.** When a bug may stem from a shared dependency or duplicated logic, search the org for the same code path or error string.
- **Onboarding and documentation lookup.** Surface relevant docs, runbooks, and examples that live outside the current repo when the local codebase doesn't fully explain a workflow.

## Workflow

1. **Find candidate repositories first.** Run the experimental repo discovery command before searching code:

```bash
jbcontext repos "<repo or domain terms>" --limit 30
```

Use short, discriminative repo terms from the request: product names, service names, team names, package names, or explicit repository names.

2. **Handle prefixed repository families carefully.** If the request mentions a prefix or wildcard such as `jcp-*`, treat it as a repository-family constraint.

- Query the prefix literally, for example `jcp` and `jcp-`.
- Keep all suitable repos whose names start with that prefix.
- Do not replace a prefixed repo family with a similar unprefixed repo unless the repo results clearly show it is the right target.
- Preserve the exact repository `id` returned by `jbcontext repos`; do not infer ids from names.

```
jbcontext repos "jcp-" # show all repos started with jcp- prefix
```

You can omit query completely.

3. **Select suitable repos.** Prefer exact name matches, prefix-family matches, and repos whose description/path/language matches the task. If there are many candidates, search the most likely 5-10 first, then expand if results are weak.

4. **Search selected repos in parallel.** Invoke `jbcontext search` once per selected repository, passing the repository id from `jbcontext repos` with the id option supported by the installed experimental CLI:

```bash
jbcontext search --repository-id "<repo-id>" --json-output --limit 10 "<semantic search query>"
```

If `jbcontext search --help` shows a different repository-id flag, use that flag, but still pass the exact id from `jbcontext repos`. Run independent repo searches in parallel when the agent environment supports parallel tool calls; otherwise keep results grouped by repository.

5. **Resolve snippets and repo information with `gh`.** When `jbcontext search` returns promising snippets, use the GitHub CLI to fetch full file context, surrounding code, default branch, repo metadata, owners, recent commits, or related PRs/issues before relying on the match. Use the GitHub owner/name or URL from `jbcontext repos` when available.

```bash
gh repo view "<owner>/<repo>" --json nameWithOwner,description,defaultBranchRef,url
gh api "repos/<owner>/<repo>/contents/<path>?ref=<ref>" -H "Accept: application/vnd.github.raw"
```

6. **Synthesize across repositories.** Report which repos were searched, which repos had useful matches, and the strongest files/symbols found. If no suitable repo is found, say which repo filters were tried before stopping.

## Search Guidance

- Use semantic, behavior-focused queries for `jbcontext search`; avoid one-word searches.
- Re-run `jbcontext repos` with narrower or prefix-aware terms before broadening code search.
- Use path filters only after repo-level matches identify likely directories.
- Keep repository names and ids visible in notes so later searches can be reproduced.
- Use `gh` to resolve snippets into full source context and to gather more information about matching repositories.