Menu
Use when orienting on an unfamiliar code area with Miller, explaining a module, finding entry points, or gathering context before a change.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use before changing existing indexed files with Miller edit, especially symbol rewrites, text replacements, renames, or refactors.
Use when an agent needs extractor-recognized code-shape facts such as routes, htmx attributes, Alpine directives, SQL DDL/DML, or data-document structure.
Use when starting a Miller task, choosing a Miller tool, or choosing a Miller search mode.
Use when tracing Miller bridge paths in supported providers: dotnet-web URL literals and fetch/axios client requests to ASP.NET signals, client requests to Next.js route handlers or Nuxt server routes, Next.js/Nuxt route references to file routes, Vue/React references to route definitions, or backend-http client requests to Express/FastAPI/Flask/Django/Spring/Go/gin/echo/Rails/NestJS/Laravel/Phoenix/axum/actix/Symfony/Ktor route facts.
Use when assessing blast radius with Miller, choosing tests for a change, answering who uses a symbol, or planning a refactor.
Use when resuming Miller-backed work from a handoff packet or validating a packet before continuing in another harness, model, or session.
| name | miller-explore-area |
| description | Use when orienting on an unfamiliar code area with Miller, explaining a module, finding entry points, or gathering context before a change. |
| user-invocable | true |
| arguments | <area, concept, module, file, or task> |
| allowed-tools | mcp__miller__context, mcp__miller__search, mcp__miller__inspect, mcp__miller__trace, mcp__miller__workspace |
Use Miller's indexed context before raw file reads. The goal is to identify the important symbols, files, and flows with a few targeted calls.
workspace(operation="status"); use workspace(operation="refresh") when needed.
When you are starting fresh in an already-indexed repo, run workspace(operation="onboarding") first — it
summarizes local telemetry into starter guidance for this repo.context(query="<task or concept>")
Use failing_test, stack_trace, or entry_symbols when the user gave those anchors.
inspect first:inspect(target="<file-or-symbol>")
inspect(target="<symbol>", depth="overview")
Omitted inspect depth is summary. Use depth=overview for the first symbol read; escalate to
depth=full only when you need the complete body or complete relation lists.
search for missing anchors:search(query="<identifier or phrase>")
search(query="<docs/prose phrase>", mode="content")
search(query="<source-body literal>", mode="source")
search(query="<imported log or web phrase>", mode="external|web")
search(query="<comment or literal>", regions="comment|string_literal|doc_comment")
For audits across registered workspaces, use content search "<term>" --workspace-id all --kind source|docs|config|external_file|web and bounded content read windows before escalating to broader context.
context integration from content hits remains opt-in: use it only when the user asks for surrounding code context after an audit or text-search hit.
trace when the question is about flow:trace(target="<symbol>")
trace(target="<from>", mode="path", to="<to>")
If trace returns no refs, no neighbours, no path, or an unsupported bridge, follow its Next: actions first.
Typical recovery is trace(mode="refs"), search(mode="source"), a scoped inspect(depth="overview"), or a
bounded depth bump; a missing extracted path is not proof the code is unrelated.
Use patterns(operation="list") before raw route, HTML, SQL, JSON, YAML, TOML, or Markdown structure hunting.
Then search a shown pattern_id or follow the list output's Next: actions.
Keep the answer compact:
Do not read whole files until context, search, or inspect has narrowed the target.