@@ -123,6 +123,13 @@ With them, a call into a dependency resolves to its declaration and a chain is t
 types (`client.post(...).json()`). Library bodies are not walked, so a dependency calling back into the project is
 not found this way.
 
+## graph
+
+`axiomcode graph` draws the codebase as one page for the user to look at: directories, files, types and methods, with
+the call edges between them and each edge's tier. It prints the page's path (`.axiomcode/graph/graph.html`); open it
+in a browser. It is drawn from the graph the index built, rebuilt first only when a source file changed. It is not an
+MCP tool: it answers no question, so when the user asks to see the graph, run it and give them the path.
+
 ## What it cannot see — say so instead of guessing
 
 Reflection, string dispatch, event buses; receivers the engine could not type; callbacks invoked by a library; what a
 
@@ -17,6 +17,9 @@
 #       labelled [asserted]. Alone, lists every link and whether the graph took it; `link <file:line> -` removes one.
 #   axiomcode index [<repo>] [--lang <lang>[,<lang>…]] [--src <subdir>] [--library <root>[,<root>…]]
 #       build the graph (the first query builds it too). <repo> defaults to the current directory.
+#   axiomcode graph [<repo>]
+#       the codebase as one interactive page: directories, files, types and methods, and the call edges between them.
+#       Prints the page's path, <repo>/.axiomcode/graph/graph.html.
 #
 # Names are written as in the code: Owner.method, function, Type, or file.py:123. `axiomcode help <verb>` for one verb.
 
@@ -182,6 +185,7 @@ done
 LASTPOS=""; [ "${#POS[@]}" -gt 0 ] && LASTPOS="${POS[${#POS[@]}-1]}"
 case "$cmd" in
   index|build) if [ "${#POS[@]}" -gt 0 ] && [ ! -d "${POS[0]}" ]; then gone "${POS[0]}"; fi ;;
+  graph) case "${POS[0]:-}" in ""|build|export|draw) ;; *) [ -d "${POS[0]}" ] || gone "${POS[0]}" ;; esac ;;
   context) if [ "${#POS[@]}" -gt 1 ] && [ ! -d "${POS[1]}" ]; then gone "${POS[1]}"; fi ;;
   path) if [ "${#POS[@]}" -gt 2 ] && [ ! -d "${POS[2]}" ]; then gone "${POS[2]}"; fi ;;
   impact) if [ "${#POS[@]}" -gt 1 ] && [ ! -e "$LASTPOS" ] && dirlike "$LASTPOS"; then gone "$LASTPOS"; fi ;;
@@ -234,6 +238,7 @@ case "$cmd" in
   changed) exec python3 ${Q:+"$Q" "$FR"} "$H/axiomcode-changed" ${ARGS[@]+"${ARGS[@]}"} ;;
   test-impact|tests) exec ${G[@]+"${G[@]}"} python3 ${Q:+"$Q" "$FR"} "$H/axiomcode-test-impact" ${ARGS[@]+"${ARGS[@]}"} ;;
   link) exec python3 "$H/axiomcode-link" ${ARGS[@]+"${ARGS[@]}"} ;;
+  graph) exec python3 "$H/axiomcode-graph" ${ARGS[@]+"${ARGS[@]}"} ;;
   --verbs) verbs ;;                      # the dispatch table, internal verbs included; tests/surfaces.py audits it
   ""|-h|--help|help) if [ ${#ARGS[@]} -gt 0 ]; then verbhelp "${ARGS[0]}"; else helptext; fi ;;
   *) echo "axiomcode: unknown subcommand '$cmd' — the entry point has: $(public_verbs | tr '\n' ' ')" >&2
 
@@ -1,23 +1,25 @@
 ---
 name: axiomcode
 description: >-
-  Use for any why, what or where question about code — how a codebase works, where something lives, who calls it, what a change to it breaks, which tests cover an edit. Also use when resolving an issue or bug report, which names a symptom rather than a file. Examples: "How does X work?", "Where do I change Y?", "What calls this?", "What breaks if I change Z?", "Which tests do I run?", "Fix this issue". Search with grep as usual; ask the graph for what grep cannot know — which declaration a call reaches and the callers that never spell the name. Answers come from a resolved call graph, so they include callers that never spell the name — through an interface, an override, a callback, dependency injection or a config key — and every place comes with the code of the function it sits in. Call the MCP tools directly, no need to load this skill first: impact(name) for who calls it and what a change reaches (with no name: your uncommitted edits), path(start, end) for how A reaches B, tests() for the tests your edits reach. Only when those tools are not in your list, the same from the shell: `axiomcode impact <name>`, `axiomcode path <A> <B>`, `axiomcode tests`. Java, TypeScript, Python, JavaScript, C#.
+  Use for any why, what or where question about code — how a codebase works, where something lives, who calls it, what a change to it breaks, which tests cover an edit. Also use when resolving an issue or bug report, which names a symptom rather than a file. Examples: "How does X work?", "Where do I change Y?", "What calls this?", "What breaks if I change Z?", "Which tests do I run?", "Fix this issue". Search with grep as usual; ask the graph for what grep cannot know — which declaration a call reaches and the callers that never spell the name. Answers come from a resolved call graph, so they include callers that never spell the name — through an interface, an override, a callback, dependency injection or a config key — and every place comes with the code of the function it sits in. Call the MCP tools directly, no need to load this skill first: impact(name) for who calls it and what a change reaches (with no name: your uncommitted edits), path(start, end) for how A reaches B, tests() for the tests your edits reach, context(task, source=True) for how something works as a step-by-step call flow with each step's code. Only when those tools are not in your list, the same from the shell: `axiomcode impact <name>`, `axiomcode path <A> <B>`, `axiomcode tests`, `axiomcode context "<task>" --source`. Java, TypeScript, Python, JavaScript, C#.
 ---
 
 # axiomcode
 
 Search with grep as usual; the graph answers what grep cannot. Use the MCP tools when they are in your list (in Claude Code
-`mcp__plugin_axiomcode_axiomcode__impact`, `__path`, `__tests`); otherwise run
+`mcp__plugin_axiomcode_axiomcode__impact`, `__path`, `__tests`, `__context`); otherwise run
 `<this dir>/../../plugins/axiomcode/skills/axiomcode/scripts/axiomcode <verb>` from the repository root. Same answer either way.
 
 | the question | MCP tool | shell |
 |---|---|---|
 | where is the code for this task? | your own search (grep), then bring the name here | — |
 | who calls X, what does changing it reach, which tests? | `impact(name)` | `axiomcode impact <name>` |
+| what is the value of constant X, and who reads it? | `impact(name)` | `axiomcode impact <name>` |
 | what do my uncommitted edits reach? | `impact()` | `axiomcode impact` |
 | how does A reach B? | `path(start, end)` | `axiomcode path <A> <B>` |
 | which tests do my edits need, and how do I run them? | `tests()` | `axiomcode tests` |
 | an answer lists an unresolved call I can see the target of | `link(site, target)` | `axiomcode link <file:line> <target>` |
+| how does this work, start to finish? | `context(task, source=True)` | `axiomcode context "<task>" --source` |
 
 Names are written as in the code: `Owner.method`, `function`, `Type`, or `file.py:123` for the declaration at that
 line. There is no setup step: the first question builds the graph, and it refreshes itself after every edit.
@@ -45,7 +47,8 @@ from an empty answer.
 
 With a name: who calls it, what depends on it further out, and the tests that exercise it. Example:
 `impact(name="PriceService.total")`. With no name: the first line is `your edits:` (each declaration you changed and
-how), then the same answer for all of them.
+how), then the same answer for all of them. A constant answers with its value — `change: const MAX_ITEMS = 5` —
+so a limit, a default or a threshold is read off the first line rather than from the file.
 
 ## path
 
@@ -87,10 +90,46 @@ identifier as written in the code.
 
 ## index
 
-`axiomcode index` builds the graph explicitly; `--lang`, `--src` and `--library` narrow it. Never re-run it on an
+`axiomcode index` builds the graph explicitly; `--lang` and `--src` narrow it. Never re-run it on an
 existing graph: the graph rebuilds itself after edits, and an answer given before that finishes says so on a
 `graph refresh:` line.
 
+By default the graph is built without the project's dependencies: a call into one is unresolved or named only as an
+external boundary. When better coverage is needed, compile the dependencies and enable them with `--library`, given
+once on `index` and kept by every rebuild after it:
+
+    axiomcode index --library auto                                  # the dependencies the project imports
+    axiomcode index --library .venv/lib/python3.12/site-packages/requests,/deps/ir/jdk   # or name them
+
+`auto` finds what the project depends on, in every language: a Python package its source imports, in its virtual
+environment (`.venv`, `venv`, `$VIRTUAL_ENV`); a JavaScript / TypeScript package it imports, under `node_modules`; a
+Java dependency `pom.xml` or `build.gradle` declares, through its `-sources.jar` in the Maven repository or Gradle's
+cache, or its class jar decompiled when it ships no sources (needs Vineflower: `mvn dependency:get
+-Dartifact=org.vineflower:vineflower:1.10.1`); a NuGet package a `.csproj` references, decompiled from its assembly
+(needs `dotnet tool install -g ilspycmd`). Whatever it cannot find (a package never restored, a jar without sources)
+it names, with the command that fetches it. A named entry, comma-separated with no spaces, is a dependency's source
+directory or a library IR (a directory of the parser's CSV tables, as `axiomcode parser <source> <dir> --library`
+writes it). Every library is compiled once into `~/.cache/axiomcode/libir/` and reused until its files change; one no
+build has used for 30 days is removed. Entries are relative to the repository or absolute; write `~` out, since one
+after a comma is not expanded. `AXIOMCODE_LIBRARY` takes the same list.
+
+The choice is kept with the graph. Every rebuild after it stages the libraries again (`auto` discovers them
+again, so a new dependency is picked up), and with libraries on, a dependency change alone (a manifest or lockfile
+edit, `pip install -U`, `npm install`, `dotnet restore`, a Maven or Gradle fetch of a dependency that was missing)
+also marks the graph stale and rebuilds it. A graph built
+without `--library` never gains libraries by itself; `AXIOMCODE_REINDEX=1 axiomcode index` turns them off again.
+
+With them, a call into a dependency resolves to its declaration and a chain is typed through its declared return
+types (`client.post(...).json()`). Library bodies are not walked, so a dependency calling back into the project is
+not found this way.
+
+## graph
+
+`axiomcode graph` draws the codebase as one page for the user to look at: directories, files, types and methods, with
+the call edges between them and each edge's tier. It prints the page's path (`.axiomcode/graph/graph.html`); open it
+in a browser. It is drawn from the graph the index built, rebuilt first only when a source file changed. It is not an
+MCP tool: it answers no question, so when the user asks to see the graph, run it and give them the path.
+
 ## What it cannot see — say so instead of guessing
 
 Reflection, string dispatch, event buses; receivers the engine could not type; callbacks invoked by a library; what a
 
@@ -5,7 +5,7 @@
 every place with the code of the function it sits in, in a fenced block. That shape is given at the front doors — the
 installed command (bin/axiomcode sets AXIOMCODE_FRONT) and the MCP server (AXIOMCODE_SURFACE=mcp) — when no flag is
 passed. Everything that calls the dispatcher directly (the hooks, the case suite, loops) or passes a flag gets the verb's
-own answer, unchanged; a verb outside the surface (find, context, graph, diff, install) is refused by the installed
+own answer, unchanged; a verb outside the surface (find, diff, install) is refused by the installed
 command.
 
   a. bin/axiomcode on a small repository (copied to a temporary directory, committed, indexed): impact <name> and
@@ -98,11 +98,14 @@ def main():
         if fails: return 1
 
         # ── a. the installed command, no flags ───────────────────────────────────────────────────────────────────
-        for verb, args in (('find', ('how is the invoice total computed',)),
-                           ('graph', ()), ('diff', ()), ('install', ())):
+        for verb, args in (('find', ('how is the invoice total computed',)), ('diff', ()), ('install', ())):
             rc, out, err = cli(repo, verb, *args)
             check(f'{verb}: off the surface, the installed command refuses it and names the supported verbs',
                   rc != 0 and 'impact' in err and 'path' in err and 'tests' in err, (out + err)[:400])
+        rc, out, err = cli(repo, 'graph')
+        page = out.strip().splitlines()[-1].split('page: ', 1)[-1] if out.strip() else ''
+        check('graph: on the surface, it draws the page and prints its path last', rc == 0 and page.endswith('graph.html')
+              and os.path.isfile(page), (out + err)[-400:])
         rc, out, err = cli(repo, 'context', 'how is the invoice total computed')
         check('context: on the surface, the task in words answers with the flow', rc == 0 and 'pricing.py' in out, (out + err)[:400])
         rc, out, err = cli(repo, 'impact', 'vat_rate')