agentleFS
KotlinKotlin/kotlinx-rpc/.claude/skills/searching_dependency_sources/SKILL.md

searching_dependency_sources

Skill1.1k starsChanged 5 days agoApache-2.0View on GitHub

Explores and searches source code of all external library dependencies, plugins, and Gradle internals via indexed symbol, full-text, and glob search; STRONGLY PREFERRED for understanding APIs, finding class/method definitions, and reading implementation logic. Do NOT use for project source code (use grep), Gradle documentation (use `researching_gradle_internals`), or Maven Central discovery (use `managing_gradle_dependencies`).

We split this skill into the rules it gives an agent

28 rules. About 0 are common, 6 are distinctive, and 22 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 22

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    ALWAYS: use search_dependency_sources as the primary discovery tool for external library and plugin code.

    line 19
  2. Distinctive:

    ALWAYS: prefer reading source code over interactive REPL exploration for understanding unfamiliar library APIs.

    line 20
  3. Very specific:

    ALWAYS: use the dependency parameter to target a single library (e.g., dependency="org.mongodb:mongodb-driver-sync") when the target is …

    line 22
  4. Very specific:

    NEVER: use gradleSource: true in this skill.

    line 24
  5. Very specific:

    NEVER: use generic shell tools like grep or find to *locate* dependency sources.

    line 25
  6. Very specific:

    MAY: use shell tools like rg or ast-grep to *operate on* a sources root path explicitly returned by read_dependency_sources or …

    line 26
  7. Very specific:

    ALWAYS: use read_dependency_sources once a specific file path has been identified via search.

    line 29
  8. Very specific:

    ALWAYS: use fresh: true if a search returns a SearchResponse with an error indicating a missing index.

    line 30
  9. Very specific:

    Invoke Precisely: ALWAYS set searchType explicitly if the intent is not a general full-text search.

    line 42
  10. Very specific:

    Scope Surgically: Use projectPath, configurationPath, or sourceSetPath to narrow the search and improve performance if the target library's …

    line 43
  11. Very specific:

    Target Libraries Directly: Use the dependency parameter to search or read from a single library.

    line 44
  12. Very specific:

    Troubleshoot Targeted Searches: If a targeted search using the dependency parameter fails or returns no matches, use inspect_dependencies …

    line 46
  13. Very specific:

    Refresh Indices: Use fresh: true if project dependencies have recently changed to ensure the index is up-to-date.

    line 48
  14. Very specific:

    Use Returned Sources Root: Every response from read_dependency_sources and search_dependency_sources includes a Sources root: …

    line 49
  15. Very specific:

    Explore Packages Authoritatively: Use read_dependency_sources with a dot-separated package path (e.g., org.gradle.api) to list its direct …

    line 51
  16. Very specific:

    Analyze Implementation: Use read_dependency_sources to retrieve the implementation logic.

    line 53
  17. Very specific:

    Trace Symbols Authoritatively: When encountering an unknown symbol, use DECLARATION search to jump directly to its definition in the …

    line 55
  18. Distinctive:

    API & Symbol Discovery: When you need to find the implementation, signature, or documentation of a class, interface, or method imported …

    line 59
  19. Distinctive:

    Library Usage Research: When understanding how to use a library's API by reading its internal implementation or looking for usage patterns …

    line 60
  20. Distinctive:

    Internal Logic Auditing: When researching how a dependency handles specific operations, edge cases, or performance-critical logic.

    line 61
  21. Very specific:

    Resource File Location: When searching for configuration files (XML, JSON, properties), specific named files (e.g., build.gradle), or …

    line 62
  22. Distinctive:

    Constant & Literal Research: When searching for specific constant values, error strings, or literal keys within external code.

    line 63
  23. Very specific:

    Call read_dependency_sources(path="<path>") to analyze the implementation.

    line 72
  24. Very specific:

    Search for a known entry point (e.g., a constructor or main class) using DECLARATION or FULL_TEXT.

    line 76
  25. Distinctive:

    Look for internal calls, helper methods, or factory patterns to understand the library's preferred usage.

    line 78
  26. Very specific:

    Call search_dependency_sources(query="\"<text>\"") (defaults to FULL_TEXT).

    line 83
  27. Very specific:

    When using the dependency parameter, all file paths and search results are relative to the library's root, omitting the …

    line 94
  28. Very specific:

    Troubleshooting Targeted Searches: If dependency filter fails, run inspect_dependencies to confirm the exact coordinates.

    line 214

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Authoritative Dependency Source & API Exploration

Explores, navigates, and analyzes the internal logic, APIs, and symbol implementations of external libraries and plugins with absolute precision using high-performance, indexed searching.

Constitution

  • ALWAYS use search_dependency_sources as the primary discovery tool for external library and plugin code.
  • ALWAYS prefer reading source code over interactive REPL exploration for understanding unfamiliar library APIs.
  • ALWAYS provide absolute paths for projectRoot.
  • ALWAYS use the dependency parameter to target a single library (e.g., dependency="org.mongodb:mongodb-driver-sync") when the target is known. This is significantly faster and more focused than searching the entire project graph. Note that when dependency is used in search_dependency_sources or read_dependency_sources, the path and all results are relative to the library root (omitting the <group>/<artifact>... prefix).
  • NEVER use gradleSource: true in this skill; use researching_gradle_internals for Gradle's internal implementation.
  • NEVER use generic shell tools like grep or find to locate dependency sources; they reside in remote caches whose paths are not predictable in advance.
  • MAY use shell tools like rg or ast-grep to operate on a sources root path explicitly returned by read_dependency_sources or search_dependency_sources in the Sources root: <path> header line. Dependency directories inside the sources root are symlinks; always pass --follow to rg (e.g., rg --follow <pattern> <sources-root>).
  • ALWAYS escape Lucene special characters (:, =, +, -, *, /) in FULL_TEXT searches using a backslash (e.g., \:) or double quotes.
  • ALWAYS use read_dependency_sources once a specific file path has been identified via search.
  • ALWAYS use fresh: true if a search returns a SearchResponse with an error indicating a missing index; the tool will return an error message rather than throwing an exception if the index is not found.
  • BE AWARE that indexing and extraction failures (e.g., ZipException) are still propagated and will cause the tool to fail with a descriptive error.
  • NOTE that the dependency filter targets ONLY the specific library version matched, NOT its transitive dependencies.

Directives

  • Identify Search Mode Authoritatively:
    • DECLARATION: Best for classes, methods, or interfaces. Matches against the simple name (tokenized for CamelCase) and the full path (exact literal). All declaration searches are case-sensitive. Do NOT include keywords like class, interface, or fun. Supports exact names, exact FQNs, glob wildcards (e.g., *, **), and regular expressions. Partial package paths require wildcards (e.g., use *.MyClass to find com.example.MyClass). You can target specific fields using name: (discovery) or fqn: (precision) prefixes.
    • FULL_TEXT: Best for literal strings, constants, and complex code patterns using Lucene. Case-insensitive.
    • GLOB: Best for finding specific files (XML, properties, etc.) by name or extension. Case-insensitive.
  • Invoke Precisely: ALWAYS set searchType explicitly if the intent is not a general full-text search. This improves result accuracy and reduces noise.
  • Scope Surgically: Use projectPath, configurationPath, or sourceSetPath to narrow the search and improve performance if the target library's context is known. To search a plugin, use configurationPath=":buildscript:classpath".
  • Target Libraries Directly: Use the dependency parameter to search or read from a single library. It supports group:name:version:variant, group:name:version, group:name, or just group. This bypasses project-level index merging and provides instantaneous results from the global extracted source cache. Note that results will be relative to the targeted library root.
  • Troubleshoot Targeted Searches: If a targeted search using the dependency parameter fails or returns no matches, use inspect_dependencies first to verify the exact coordinates (group, name, version, variant) of the dependency as resolved by Gradle.
  • Refresh Indices: Use fresh: true if project dependencies have recently changed to ensure the index is up-to-date.
  • Use Returned Sources Root: Every response from read_dependency_sources and search_dependency_sources includes a Sources root: <absolute-path> header. Use this path with rg, ast-grep, or other shell tools for operations not covered by the MCP tools (e.g., regex-heavy searches). Because dependency directories are symlinks, always pass --follow to rg: rg --follow <pattern> <sources-root>.
  • Explore Packages Authoritatively: Use read_dependency_sources with a dot-separated package path (e.g., org.gradle.api) to list its direct symbols and sub-packages. This is backed by the symbol index and is more reliable than directory-based exploration for Kotlin projects.
  • Analyze Implementation: Use read_dependency_sources to retrieve the implementation logic. If the file is large, use pagination to read specific sections. You can target plugins by passing configurationPath=":buildscript:classpath".
  • Trace Symbols Authoritatively: When encountering an unknown symbol, use DECLARATION search to jump directly to its definition in the library. This is the only reliable way to understand exact behavior and available methods.

When to Use

  • API & Symbol Discovery: When you need to find the implementation, signature, or documentation of a class, interface, or method imported from a library.
  • Library Usage Research: When understanding how to use a library's API by reading its internal implementation or looking for usage patterns in its source.
  • Internal Logic Auditing: When researching how a dependency handles specific operations, edge cases, or performance-critical logic.
  • Resource File Location: When searching for configuration files (XML, JSON, properties), specific named files (e.g., build.gradle), or metadata (AndroidManifest.xml) packaged within library jars.
  • Constant & Literal Research: When searching for specific constant values, error strings, or literal keys within external code.

Workflows

1. Tracing a Symbol from Project Code

  1. Identify the symbol name (e.g., JsonConfiguration) or fully qualified name from an import.
  2. Call search_dependency_sources(query="<SymbolName>", searchType="DECLARATION").
  3. Identify the correct file path from the results.
  4. Call read_dependency_sources(path="<path>") to analyze the implementation.

2. Discovering API Usage through Source

  1. Search for a known entry point (e.g., a constructor or main class) using DECLARATION or FULL_TEXT.
  2. Once the file is found, use read_dependency_sources to read its source.
  3. Look for internal calls, helper methods, or factory patterns to understand the library's preferred usage.

3. Searching for Constants or Error Codes

  1. Identify the constant name or a snippet of an error message.
  2. Call search_dependency_sources(query="\"<text>\"") (defaults to FULL_TEXT).
  3. Review matches to find where the value is defined or used.

Targeted Search for a Single Library

  1. Identify the dependency coordinates (e.g., from inspect_dependencies or project files).
  2. Call search_dependency_sources(query="<query>", dependency="<group:artifact>").
  3. The results will be scoped ONLY to that library, ensuring maximum speed and relevance.

Path Relativity and Targeted Searching

When using the dependency parameter, all file paths and search results are relative to the library's root, omitting the <group>/<artifact>... prefix.

  • Merged Scope (No Filter): path = "org/mongodb/mongodb-driver-sync/4.11.1-sources/org/mongodb/client/MongoClient.kt"
  • Targeted Scope (dependency="org.mongodb:mongodb-driver-sync"): path = "org/mongodb/client/MongoClient.kt"

This approach is significantly faster and simplifies path handling when you are focused on a specific library.

Examples

Search for a specific class definition within a targeted library

{
  "query": "MongoClient",
  "searchType": "DECLARATION",
  "dependency": "org.mongodb:mongodb-driver-sync"
}
// Reasoning: Using the 'dependency' parameter to target only the 'mongodb-driver-sync' library for a fast, focused search.

Read sources from a specific dependency

{
  "dependency": "org.jetbrains.kotlinx:kotlinx-coroutines-core",
  "path": "kotlinx/coroutines/Job.kt"
}
// Reasoning: Reading 'Job.kt' directly from the targeted 'kotlinx-coroutines-core' library. Note the 'group/artifact...' prefix is omitted.

Search for a specific class definition

{
  "query": "JsonConfiguration",
  "searchType": "DECLARATION"
}
// Reasoning: Using DECLARATION search to find a class named 'JsonConfiguration' across both name and FQN fields.

Search with field-specific precision

{
  "query": "fqn:kotlinx.serialization.json.*",
  "searchType": "DECLARATION"
}
// Reasoning: Using the 'fqn:' prefix with a wildcard to find all declarations within a specific package literal.

Search with name-specific discovery (CamelCase)

{
  "query": "name:Configuration",
  "searchType": "DECLARATION"
}
// Reasoning: Using the 'name:' prefix to find classes like 'JsonConfiguration' via CamelCase tokenization.

Trace a method signature using wildcards

{
  "query": "encodeTo*",
  "searchType": "DECLARATION"
}
// Reasoning: Finding all definitions starting with 'encodeTo' across both name and FQN fields.

Use regular expressions for complex matching

{
  "query": "fqn:/.*\\.internal\\..*/",
  "searchType": "DECLARATION"
}
// Reasoning: Using a regular expression on the 'fqn' field to find all internal declarations.

Search for a constant value assignment

{
  "query": "DEFAULT_TIMEOUT_MS \\: 5000"
}
// Reasoning: Using FULL_TEXT (default) with escaped colon to find a specific constant assignment.

Locate a specific file by its exact name

{
  "query": "**/AndroidManifest.xml",
  "searchType": "GLOB"
}
// Reasoning: Using GLOB search to find a specific file by name across the dependency graph.

Read a specific dependency source file

{
  "path": "kotlinx/serialization/json/Json.kt"
}
// Reasoning: Reading the implementation of a known class path identified from previous search results.

Explore a package via its FQN

{
  "path": "org.gradle.api"
}
// Reasoning: Listing the direct symbols and sub-packages of 'org.gradle.api' using index-backed exploration.

Resources

  • Lucene Query Syntax: Refer to the tool description for search_dependency_sources for details on complex queries and escaping.
  • Troubleshooting Targeted Searches: If dependency filter fails, run inspect_dependencies to confirm the exact coordinates.

Download now (ZIP)

Trending

Quiet since September.about the whole repository

Dec 2025: 2 mentionsJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 1 mentionApr 2026: 0 mentionsMay 2026: 1 mentionJun 2026: 2 mentionsJul 2026: 2 mentionsAug 2026: 0 mentionsSep 2026: 1 mentionOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the Kotlin/kotlinx-rpc repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about Kotlin/kotlinx-rpc

The biggest 5 of 16 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 16

Talked about on GitHub (16 times).

On GitHub · 16

11 more on GitHub

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.