explore-area

Explore Area

Orient on an unfamiliar area of the codebase using Julie's get_context tool. This is the recommended starting point before any modification task — understand the area first, then dive in.

Process

Step 1: Get Token-Budgeted Context

get_context(query="<area, concept, or module name>")

Conceptual queries work well here, not just symbol names. For example, get_context(query="error handling and retries") will find relevant symbols by meaning via semantic search.

For a quick concept-to-symbol probe before expanding context, use fast_search(query="...", backend="semantic") or backend="hybrid". Those backends return symbol-backed hits only; use explicit backend="lexical" for file names, path fragments, or pure lexical comparison. Omitting backend is normal search and may show a labeled semantic fallback only when an identifier-like unscoped lexical query returns zero hits and embeddings are ready.

This returns:

• Pivots: The most relevant symbols with full code bodies
• Neighbors: Connected symbols with signatures only
• File map: Which files contain which symbols

The output is automatically token-budgeted — few results get deep context, many results get broad overview.

Step 1a: Bias with task inputs (optional)

get_context accepts task-shaped inputs that bias pivot selection and neighbor ranking toward what the user is actually working on. Mix and match as relevant:

• edited_files=[...] — boost pivots and neighbors in those files. Use when the user has changes in progress and wants context around them.
• entry_symbols=[...] — explicit symbol entry points the user cares about. Pins those symbols as pivots even if search scoring wouldn't have surfaced them.
• stack_trace="..." — paste a stack trace; file:line references inside get parsed and bias pivot selection toward the frames involved.
• failing_test="<test file or test symbol>" — boost production symbols linked to that test via the test-linkage graph. Great for "why is this test failing?" orientation.
• max_hops=2 — allow bounded second-hop expansion when first-hop is thin (fewer than 4 code neighbors). Default is 1. Use for sparsely-connected areas where the immediate neighborhood isn't enough.
• prefer_tests=true — let test-linked symbols compete for neighbor slots alongside production callers. Default is false (tests stay out of the neighbor budget). Flip on when the user is writing or debugging tests.