Skill

Find Code Files by Intent

Vexor CLI skill for semantic, intent-based file discovery in large codebases, faster than manual browsing or naive grep.


81
Spark score
out of 100
Updated last month
Version 13.1.0

Add to Favorites

Why it matters

Locate files within large codebases based on their semantic intent, rather than exact filenames or text matches. This is ideal for discovering where functionality is implemented, loaded, defined, or documented when manual browsing or simple text searches are insufficient.

Outcomes

What it gets done

01

Discover file implementations by semantic meaning.

02

Search codebases when manual browsing or grep is too slow.

03

Find definitions, implementations, or documentation semantically.

04

Utilize various search modes for optimal performance and recall.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-vexor-cli | bash

Overview

Vexor CLI Skill

A CLI skill for finding files by intent rather than exact text match, using vexor's semantic search modes tuned for different speed/recall tradeoffs. Use it in large repositories where manual browsing or naive grep is too slow or ambiguous, picking the cheapest mode (name/head/brief) that still answers the query.

What it does

Vexor CLI finds files by intent - what they do - rather than exact filename or text match, using the vexor command for intent-based file discovery. It's built for semantic discovery of where something is implemented, loaded, defined, or documented, in repositories large enough that manual browsing or naive grep becomes too slow or ambiguous.

When to use - and when NOT to

Use it when you need to locate files by intent rather than exact text, when the repository is too large for manual browsing or naive grep to be efficient, or when you want semantic discovery rather than literal string matching. Try vexor first for intent-based discovery; if it's missing, install instructions are in references/install-vexor.md.

Inputs and outputs

Command shape: vexor "<QUERY>" [--path <ROOT>] [--mode <MODE>] [--ext .py,.md] [--exclude-pattern <PATTERN>] [--top 5] [--format rich|porcelain|porcelain-z]. Seven search modes trade off speed against recall - pick the cheapest that works: auto (routes by file type, default), name (filename-only, fastest), head (first lines only), brief (keyword summary, good for PRDs), code (code-aware chunking for .py/.js/.ts, best default for codebases), outline (Markdown headings/sections, best for docs), and full (chunks full file contents, slowest but highest recall). Other flags: --path/-p for root directory, --ext/-e to limit file extensions, --exclude-pattern for repeatable gitignore-style exclusions, --top/-k for result count, --include-hidden and --no-respect-gitignore to widen scope, --no-recursive to limit to the top directory, and --no-cache for in-memory-only operation. Results return similarity ranking, exact file location, line numbers, and a matching snippet preview.

vexor search "config loader" --path . --mode code --ext .py

Integrations

Output format defaults to rich for human reading, with porcelain (TSV) or porcelain-z (NUL-delimited) for scriptable consumption. vexor doctor or vexor config --show diagnoses API, cache, and connectivity setup issues. The first search on a repo indexes files (may take a minute); subsequent searches are fast, so longer timeouts should only be expected on the first run.

Who it's for

Developers and agents working in large codebases who need to find where a concept is implemented (e.g. "config loader", "user authentication flow") without knowing the exact filename or string to grep for. Typical queries look like vexor search "typer app commands" --top 5 to find CLI entrypoints, vexor search "user authentication flow" --path docs --mode outline --ext .md --format porcelain to search docs by heading structure, or the same config-loader query with --exclude-pattern tests/** --exclude-pattern .js layered on top to cut out test files and JavaScript from the results - exclude rules apply on top of any --ext filter, so the two can be combined to focus tightly on a relevant subset of the repository.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.