菜单
Use this skill when navigating, understanding, or changing code in an indexed repo. Prefer the code graph (symbol search, source slices, call graph) over full-file reads and wide greps — it is cheaper and more precise. Covers when to reach for which tool and the canonical lookup sequence.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | codegraph |
| description | Use this skill when navigating, understanding, or changing code in an indexed repo. Prefer the code graph (symbol search, source slices, call graph) over full-file reads and wide greps — it is cheaper and more precise. Covers when to reach for which tool and the canonical lookup sequence. |
| metadata | {"keywords":"code search, find function, where defined, where is, what calls, callers, callees, refactor, impact analysis, symbol, navigate code, codebase tour, qualified name, outline, indexed repo, project path, which repo, what repos, what project, go to project","category":"code-navigation","load":"on-demand"} |
A pre-indexed symbol + call graph over the user's repos, exposed as six MCP tools:
code_repos, code_search, code_outline, code_context, code_callers, code_callees.
Reach for these before read_file or recursive grep whenever the question is about a symbol (function, class, method, const, type) or its relationships.
ALWAYS call code_repos before answering any question about:
Project paths are runtime filesystem facts — they are NOT in your training data and you CANNOT answer them from knowledge. Never guess or refuse. Always call code_repos first.
This rule overrides the general "don't use tools for knowledge questions" guidance in agent-conduct. A project path is not a knowledge question.
X defined?" → code_search → code_contextcode_outlineFoo.bar" → code_contextcode_callerscode_calleescode_callers firstcode_repos → code_outline on entry filescode_repos first if unsure)read_filewiki, memory, or read_fileunknown repo → code_repos (which repos are indexed, where are they)
unknown name → code_search (returns ranked qualified names + kinds)
known file → code_outline (cheap map before fetching context)
known symbol → code_context (source slice with leading comment + padding)
about to edit → code_callers (one hop; depth ≤ 5 for transitive)
tracing flow → code_callees (one hop; depth ≤ 5 for transitive)
A typical "find and read" is two calls: code_search → code_context. A typical "safe-to-change" check is one more: code_callers.
code_search returns results keyed by qualified name: <repo-relative path>::<Class>.<method> or <path>::<function>. Pass that string verbatim to code_context, code_callers, code_callees. Do not reconstruct it by hand.
Examples:
lib/agent/index.js::Agent.runmcp/tools/files.js::readFileMultiple repos can be indexed at once, and paths/qualified names are repo-relative — lib/playground.js may exist in several of them. Every match from code_search, code_outline, code_callers, and code_callees therefore carries its repo:
repo — the repo's short name (root_path basename), e.g. aperioroot_path — the repo's absolute path, e.g. /Users/lk/Projects/BaiGanio/aperioNever infer which repo a relative path belongs to from the path itself — that guess is the source of cross-project hallucinations. Read repo/root_path straight off the result. To open the file directly, join root_path + the relative path and read_file that absolute path.
When you act on a result, pass its repo to the follow-up tool (code_context, code_outline, code_callers, code_callees) so the lookup resolves in the right repo. Without it, a qualified name or path that exists in two repos resolves to an arbitrary one. If a repo substring matches more than one indexed repo the tool errors with the candidates — pass a longer substring.
Bug triage. User reports "X is broken." → code_search the user's wording → code_context the top hit → code_callers to find the entry path that triggered it.
Refactor scoping. Before renaming or changing a signature: code_callers at depth: 2 or 3 to see the blast radius. If it's large, propose a plan to the user before editing.
Codebase tour. code_repos → pick the relevant repo → code_search for likely entry symbols (main, run, start, register, handler) → code_outline on each hit's file.
"What does this function actually do?" code_context for the body → code_callees to see what it delegates to → recurse one level on anything non-obvious.
code_context returns "file not found — repo may have moved", the index is out of date. Tell the user; suggest node lib/codegraph/indexer.js <path> to reindex.code_search blends FTS with semantic embeddings when available. Short, distinctive terms (function names, error strings) rank best. Long natural-language queries work too but return broader results — narrow with kind or repo.code_callers / code_callees cap at depth 5. For wider sweeps, walk iteratively and summarize.code_context defaults to 2 lines of padding above/below the symbol. Bump to 5–10 when you need surrounding context (imports, sibling helpers).The extractor is lib/codegraph/extract-ts.js and uses web-tree-sitter with tree-sitter-wasms. Adding a language means: register the grammar, write a small node-type walk that yields { name, kind, qualified, startLine, endLine, leadingDoc }, and (optionally) extract call edges by walking call expressions.
Grammars already installed and ready to wire up: python, go, rust, java, kotlin, c, cpp, c_sharp, ruby, php, swift, scala, lua, bash, solidity, dart, elixir, zig, plus markup (html, css, vue), data (json, yaml, toml), and query languages (ql).
If a user asks about a language not yet supported, say so plainly and fall back to read_file / grep — do not silently miss results.
How to use Aperio's memory tools well — when to recall, what is worth remembering, how to correct a wrong memory, and what must never be stored. Read this when connected to an Aperio MCP server; the tool schemas describe parameters, this describes judgment.
Use this skill to iteratively tune the keywords and descriptions of other SKILL.md files so the skill matcher fires the right skill for a prompt. Runs an autonomous mutate → score → keep/discard loop against a frozen eval set (exam §7 skill triggering), advancing a git branch when match accuracy improves. The eval and scorer are read-only ground truth; the curated keyword frontmatter of other skills is the only editable surface.
Use this skill before writing new code — when the ask is to add a helper, a small feature, a utility, or a new module, and the right amount of code has not been decided yet. Triggers: "write me a helper for…", "add a small feature", "do I need a library for this", "keep it minimal", weighing a new dependency, or any request that could be met by something that already exists. Walk the ladder first: reuse beats stdlib beats platform beats dependency beats new code. This is the pre-write sibling of code-simplification, which cleans up afterwards.
Use this skill when reading from or writing to the persistent memory store. Covers the memory tool API (recall, remember, update_memory, forget) and — for advanced direct access — the SQL schema, vector search patterns, and retrieval priority order against the Aperio Postgres store. Triggers: user states a preference, shares a fact or decision, gives a correction, asks the agent to remember something, or starts a task where past context would affect the output.
Use this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text/tables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, adding watermarks, creating new PDFs, filling PDF forms, encrypting/decrypting PDFs, extracting images, and OCR on scanned PDFs to make them searchable. If the user mentions a .pdf file or asks to produce one, use this skill.
Toolkit for styling artifacts with a theme, and for creating distinctive, production-grade frontend interfaces. Use for: applying pre-set or custom themes to slides, docs, reports, HTML pages; building web components, pages, dashboards, React components, HTML/CSS layouts; or styling/beautifying any web UI with high design quality. ALWAYS use this skill before building any frontend or UI — it prevents the default "clean SaaS with purple gradient" trap that makes every AI-built site look identical.