@neat.is/claude-skill 0.10.6-dev.20261007 → 0.10.6-dev.20261009

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/GRAPH_FIRST.md +40 -40
  2. package/SKILL.md +101 -97
  3. package/package.json +1 -1
package/GRAPH_FIRST.md CHANGED
@@ -1,49 +1,49 @@
1
1
  <!-- NEAT graph-first directive. Paste this block into your agent's project
2
- instructions — CLAUDE.md, AGENTS.md, .cursorrules, or the equivalent —
3
- so the agent queries NEAT's graph before it scans files by hand.
2
+ instructions — CLAUDE.md, AGENTS.md, .cursorrules, or the equivalent.
4
3
  Agent-agnostic: it is plain guidance, no Claude Code features required. -->
5
4
 
6
- ## Query the graph FIRST
5
+ ## Query NEAT before searching files
7
6
 
8
- This project has NEAT wired in: a live, fused semantic graph of the system —
9
- code, infrastructure, and runtime behaviour (OpenTelemetry) in one model. Every
10
- fact carries provenance — `EXTRACTED` from source, `OBSERVED` from OTel,
11
- `INFERRED` where the trace stitcher bridges a gap, `STALE` when runtime goes
12
- quiet — plus a confidence, so you know how much to trust each answer.
7
+ This project has a live NEAT graph: code, data and infrastructure declarations
8
+ fused with runtime traffic, incidents and supported provider telemetry. It can
9
+ show what exists, what actually ran, where a failure began, and what may break
10
+ when a node changes. The graph is deterministic: the agent supplies the model;
11
+ NEAT resolves named nodes and traverses recorded evidence rather than asking an
12
+ LLM to infer architecture from file names.
13
13
 
14
- **For ANY question about this system's behaviour, dependencies, failures, root
15
- cause, or blast radius, call `neat ask` FIRST — before Read, Grep, Glob, or
16
- Bash.** You do not need to know which tool or the exact node id: `ask` is the
17
- front door. It resolves the entities in your question to graph nodes and routes
18
- it to the right traversal, returning one compact, provenance-tagged answer.
14
+ Every claim carries provenance and confidence. `EXTRACTED` comes from recognized
15
+ source or configuration, `OBSERVED` from spans or supported provider signals,
16
+ `INFERRED` from a bridged relationship, and `STALE` marks an observed edge that
17
+ went quiet. Missing runtime evidence does not prove a path never runs.
18
+
19
+ **For questions about this system's behavior, structure, data dependencies,
20
+ failures, or change impact, call the MCP `ask` tool (`mcp__neat__ask`) before
21
+ Read/Grep/Glob/Bash.** You do not need an exact node id. `ask` resolves names
22
+ and routes to the relevant graph traversal, returning provenance-tagged facts.
23
+ When MCP is unavailable, use the same door through the CLI:
19
24
 
20
25
  ```
21
- neat ask "why is checkout failing?"
22
- neat ask "what breaks if I change the orders table?"
23
- neat ask "what does the payments service depend on at runtime?"
26
+ npx neat.is ask "why is checkout failing?"
27
+ npx neat.is ask "what breaks if I change the orders table?"
28
+ npx neat.is ask "what does the payments service depend on at runtime?"
24
29
  ```
25
30
 
26
- Same door over MCP: the `ask` tool (`mcp__neat__ask`). Reach for it first.
27
-
28
- The graph is live and fused: it is faster and more accurate than
29
- `grep`/`glob`/`find`, and it can tell you what the system *actually does at
30
- runtime*, not only what the source declares.
31
-
32
- When you already have a node id and want one specific traversal, the structured
33
- tools answer directly:
34
-
35
- - `semantic_search` — find code/nodes by a natural-language description.
36
- - `get_dependencies` — a node's transitive outgoing dependencies (`EXTRACTED`).
37
- - `get_observed_dependencies` — only what a node calls *in production* (`OBSERVED`).
38
- - `get_divergences` — where the code (`EXTRACTED`) and production (`OBSERVED`) disagree.
39
- - `get_root_cause` — trace a failing node up its dependency graph to the culprit.
40
- - `get_blast_radius` — everything downstream: what breaks if a node changes or fails.
41
- - `get_incident_history` — recent OTel error events recorded against a node.
42
- - `check_policies` — the project's `policy.json` violations, actual or hypothetical.
43
-
44
- Fall back to text search only when the graph does not have what you need —
45
- comments, string literals, config minutiae, a file NEAT does not model. The rule
46
- is order: ask the graph first, then scan.
47
-
48
- If the tools are not available, the NEAT daemon may not be running (`neat list`)
49
- or the MCP server may not be wired in (`neat skill --apply`).
31
+ For a failure, ask first, then call `get_incident_card` on the named service,
32
+ file or symbol. The card combines the incident, likely cause, blast radius,
33
+ policies and divergence into a work order. Use `expand` one hop at a time and
34
+ `relate` to test whether the suspected cause and symptom share a signal. Check
35
+ provenance and confidence before acting.
36
+
37
+ Before a change, use `get_blast_radius` and `check_policies` to see dependents
38
+ and advisory architectural rules. Use `get_divergences` to compare declared
39
+ intent with observed behavior, `get_graph_diff` to compare a saved snapshot
40
+ with the live graph, and `get_recent_stale_edges` when traffic goes quiet.
41
+ `get_dependencies` maps a node's outgoing graph; `get_observed_dependencies`
42
+ shows only seen runtime/provider calls. `semantic_search` finds node labels,
43
+ not arbitrary source text.
44
+
45
+ Read source when the graph does not model what you need: comments, arbitrary
46
+ string literals, config details, unsupported syntax, or a repository that has
47
+ not been extracted or connected. If a graph answer is empty, check the daemon
48
+ with `npx neat.is list` or restart it with `npx neat.is up`; wire MCP with
49
+ `npx neat.is skill --apply`.
package/SKILL.md CHANGED
@@ -1,130 +1,134 @@
1
1
  # NEAT — Claude Code skill
2
2
 
3
- This skill exposes NEAT's live semantic graph to Claude Code over MCP. Once installed, Claude can ask the running NEAT daemon (`neatd`) about a project's services, dependencies, recent errors, and policy violations — same as any other agent NEAT supports.
3
+ NEAT gives a coding agent a live semantic graph of the software system it is
4
+ working in. It fuses declarations from code, data schemas and infrastructure
5
+ with runtime traffic, incidents and supported provider telemetry, at the finest
6
+ grain the evidence permits. An agent can ask how a feature fits together, what
7
+ actually runs, where a failure began, and what an edit could affect before it
8
+ searches files or guesses from names. Every graph claim has provenance and
9
+ confidence; an unseen path is not proof that it never runs.
4
10
 
5
11
  ## What you get
6
12
 
7
- Twenty-four MCP tools, served by `@neat.is/mcp` over stdio — fourteen read-only graph queries, six `/neat extend` tools for instrumentation, and four hosted connector tools. The canonical list lives in `MCP_TOOL_NAMES` (`@neat.is/types`); the server registrations are the source for every description below.
8
-
9
- ### Read tools
10
-
11
- | Tool | What it does |
12
- |------|--------------|
13
- | `ask` | Ask the graph a question in plain language — the front door. Resolves the entities in the question to nodes and routes to the right traversal, so you need neither a tool name nor a node id. Reach for it before Read/Grep/Bash. |
14
- | `get_root_cause` | Trace a failing node up its dependency graph to the underlying cause. Use when something is breaking and you want the upstream culprit. |
15
- | `get_blast_radius` | List every node downstream of a node — what would break if it failed or was redeployed. |
16
- | `get_dependencies` | Transitive outgoing dependencies, BFS to depth N, each carrying distance, edge type, and provenance (EXTRACTED vs OBSERVED). |
17
- | `get_observed_dependencies` | Only the runtime (OBSERVED via OTel) outgoing dependencies — compare what code declares against what production does. |
18
- | `get_incident_history` | Recent OTel error events recorded against a node, most recent first. |
19
- | `get_incident_card` | One self-sufficient work order for an incident on a node — the incident fused with its root-cause chain, blast radius, governing policies and node divergence, each claim provenance-stamped. |
20
- | `get_divergences` | Places where the code (EXTRACTED) and production (OBSERVED) disagree, ranked by confidence × severity. The most NEAT-shaped query — reach for it on "is anything weird?" |
21
- | `get_graph_diff` | Diff a saved graph snapshot against the current live graph — added/removed/changed nodes and edges. |
22
- | `get_recent_stale_edges` | Most recent OBSERVED → STALE transitions — integrations that have gone quiet. |
23
- | `check_policies` | Inspect or dry-run the project's `policy.json`. Returns current violations, or violations a hypothetical action would cause. |
24
- | `semantic_search` | Search nodes by natural-language query (embedding vectors when available, substring fallback otherwise). |
25
- | `expand` | Take one navigation step from a node — `up` to callers, `down` to callees — with each neighbour classified primary-failure / symptom-only / unrelated. Walk a failure a hop at a time. |
26
- | `relate` | Confirm whether two nodes are connected, which way, and whether the connecting path carries the failure (`carriesSignal`) rather than merely existing. |
27
-
28
- ### Extend tools (`/neat extend`, ADR-081 / ADR-086)
29
-
30
- | Tool | What it does |
31
- |------|--------------|
32
- | `neat_list_uninstrumented` | List libraries that need instrumentation beyond the auto-instrumentations bundle. |
33
- | `neat_lookup_instrumentation` | Look up the registry entry for a library — canonical instrumentation package, version, registration snippet. |
34
- | `neat_describe_project_instrumentation` | Describe the current OTel state: which hook files exist, whether `.env.neat` is present, which OTel deps are installed. |
35
- | `neat_dry_run_extension` | Preview what an apply would do — the exact file diff, deps to add, install command — without changing anything. |
36
- | `neat_apply_extension` | Install an instrumentation package and splice its registration into the OTel hook file. Idempotent. |
37
- | `neat_rollback_extension` | Undo the last apply for a library — removes the dep and registration. |
38
-
39
- ### Connector tools (hosted, ADR-228)
40
-
41
- The headless half of `neat connect` — paste a provider token instead of walking a browser consent screen. These are the only tools that call the control plane rather than the daemon, so they need `NEAT_CP_URL` and a `neat_pat_` API key; without those they return a "not configured" note.
42
-
43
- | Tool | What it does |
44
- |------|--------------|
45
- | `neat_list_connectable` | List the providers connectable to this hosted project (Supabase, Railway, …). |
46
- | `neat_connect` | Connect a provider by pasting its API token. NEAT verifies it against the provider, seals it, and pulls the provider in as OBSERVED. |
47
- | `neat_connection_status` | List connected providers and each connection's status — connecting, healthy, error, needs reconnect. |
48
- | `neat_disconnect` | Disconnect a provider and drop its stored connections. |
49
-
50
- The fourteen read tools read from the live graph the daemon maintains in memory. No fs reads of `graph.json` at request time. The extend tools modify instrumentation files, `package.json`, and the lockfile only; NEAT never calls an LLM and the agent reasons over their output (ADR-084). The connector tools are the one exception to all of this — they call the hosted control plane rather than the daemon, and write connection state, never the graph.
13
+ The MCP server answers plain-language questions and exposes structured walks,
14
+ incident work orders, change impact, divergence and policy checks. It also
15
+ reports instrumentation gaps and, when hosted control-plane access is configured,
16
+ can manage supported provider connections. The table below is generated from the
17
+ registered tool descriptions, so its inventory follows the shipped server.
18
+
19
+ <!-- MCP_TOOL_TABLE_START -->
20
+ | Tool | Server description |
21
+ | --- | --- |
22
+ | `get_root_cause` | When a named node is failing, trace its dependency graph toward likely root-cause candidates. Returns a provenance-scored cause chain, including recorded error context when available, that file search cannot establish from runtime evidence. |
23
+ | `get_blast_radius` | Before changing or redeploying a node, see its downstream dependents and evidence-bearing paths. Returns the bounded blast radius so an edit plan includes affected services, routes, data, and callers. |
24
+ | `get_dependencies` | When you know a node id, map what it depends on across code, data, and infrastructure. Returns a bounded outgoing traversal (default depth 3, max 10) with distance, edge type, provenance, and confidence; depth=1 shows direct dependencies. |
25
+ | `get_observed_dependencies` | When you need evidence of what a node actually called, return only its OBSERVED outgoing dependencies from runtime or supported provider signals. Compare with get_dependencies or get_divergences to distinguish declared intent from seen behavior. |
26
+ | `get_incident_history` | When a node has failed, read its recorded error events, most recent first. The incident ledger preserves failure evidence and timestamps that a source search cannot reveal. |
27
+ | `get_incident_card` | When something is failing, get one work order for a service, file, or symbol: the recorded incident, likely cause chain, blast radius, governing policies, and divergences with provenance on each claim. Omit errorId for the latest incident or pin a specific one, then use expand/relate to verify the path. |
28
+ | `semantic_search` | When you cannot name a graph node, find candidate nodes by a natural-language description. Searches node labels through Ollama nomic-embed-text when reachable, then in-process MiniLM, then substring fallback; it does not search arbitrary source contents. MiniLM downloads a ~23 MB quantized model on a cold cache; set NEAT_SEARCH_PROVIDER=substring before daemon startup to avoid model initialization and download. |
29
+ | `get_graph_diff` | When reviewing a change or incident timeline, compare a saved snapshot with the live graph. Returns added, removed, and changed nodes and edges plus both timestamps, so architecture drift is visible beyond a file diff. |
30
+ | `get_recent_stale_edges` | When traffic or an integration seems to have disappeared, list recent OBSERVED → STALE edge transitions. Returns the edges that went quiet and when; quiet is a signal to investigate, not proof the dependency is healthy or removed. |
31
+ | `check_policies` | Before an edit, ask which architectural policies apply to its node; before a proposed action, dry-run its policy effect. Returns advisory rules or violations across structure, compatibility, provenance, ownership, and blast radius. Policies inform the agent; this tool does not block changes. |
32
+ | `get_divergences` | When you need to find drift between declared code/config and observed behavior, return ranked divergences: missing edges, version or host mismatches, compatibility violations, symbol/field mismatches, and observed failures. Each result carries confidence and severity; use this for a broad audit before choosing a specific failing node. |
33
+ | `expand` | After an incident card points to a locus, walk one evidence-bearing hop. "up" finds callers/dependents and "down" finds callees/dependencies; each neighbor is classified primary-failure, symptom-only, or unrelated so you can separate cause from downstream symptoms. |
34
+ | `relate` | Test a suspected cause-and-symptom pair. Returns a bounded connecting path, direction, per-hop provenance, and whether error/latency signal carries end to end. No path within the bound is reported as such, not as proof the nodes are unrelated. |
35
+ | `ask` | Ask the graph a question in plain language — the front door to NEAT. Reach for this FIRST, before Read/Grep/Bash, for any question about this system's behaviour, dependencies, failures, root cause, or blast radius. You do NOT need to know which tool or the exact node id: `ask` resolves the entities in your question to graph nodes and routes it to the right traversal (root cause, dependencies, observed runtime calls, incidents, divergences, blast radius), returning one compact answer with every fact provenance-tagged (EXTRACTED/OBSERVED/INFERRED/STALE) and confidence-scored. Ask what a node talks to, connects to, uses, hits, calls, reads from, or writes to for dependencies; add actually, in production, or at runtime for observed calls. Ask who calls or depends on a node, or for its consumers or callers, for blast radius. Ask about slow, latency, p95, or timing for runtime evidence; a why/failure question leads with root cause. Use the structured tools (get_root_cause, get_dependencies, …) when you already have a node id and want just that one traversal. |
36
+ | `neat_list_uninstrumented` | When the graph lacks expected runtime evidence, list project libraries outside automatic instrumentation coverage. Returns first-party, third-party, and gap libraries that may need an explicit instrumentation package. |
37
+ | `neat_lookup_instrumentation` | When a library is an instrumentation gap, look up its supported registry recipe. Returns the instrumentation package, matching version range, and registration snippet when one exists. |
38
+ | `neat_describe_project_instrumentation` | When OBSERVED evidence is missing, inspect this project's instrumentation wiring. Returns hook-file presence, .env.neat presence, and installed OTel dependencies before you change code. |
39
+ | `neat_apply_extension` | After reviewing an instrumentation gap and preferably previewing it, apply the chosen library extension. Installs the package and updates the OTel hook, package.json, and lockfile; repeating the same extension is a no-op. |
40
+ | `neat_dry_run_extension` | Before filling an instrumentation gap, preview the extension. Returns the exact file diff, dependencies, and install command without changing the project. |
41
+ | `neat_rollback_extension` | If a library extension needs reversing, remove its package.json dependency and hook registration. Returns the rollback result; run the package manager afterward because this tool does not refresh the lockfile. |
42
+ | `neat_list_connectable` | When a hosted graph lacks provider-side evidence, list the providers this project can connect. Returns control-plane options, or a configuration note when NEAT_CP_URL and a neat_pat_ NEAT_API_KEY are unavailable. |
43
+ | `neat_connect` | When authorized to add hosted provider evidence, connect a listed provider with its API credential. The control plane verifies and seals the credential; the daemon then polls or receives the supported telemetry into OBSERVED. Hosted only. |
44
+ | `neat_connection_status` | When provider evidence is absent or stale in a hosted graph, inspect connections and their connecting, healthy, error, or needs-reconnect status. Returns control-plane state, not a live graph traversal. |
45
+ | `neat_disconnect` | When authorized to remove a hosted provider integration, disconnect it and drop its stored connection. Returns the control-plane result; this changes future provider evidence, not source code. |
46
+ <!-- MCP_TOOL_TABLE_END -->
47
+
48
+ Hosted connector tools need `NEAT_CP_URL` and `NEAT_API_KEY`, a `neat_pat_` NEAT API key. Keys are minted by the control plane's `POST /me/tokens`; the app.neat.is console doesn't offer them yet. `neat login` stores a daemon token for graph queries; it does not configure control-plane connector tools.
49
+
50
+ Graph queries read the daemon's live graph. Instrumentation tools can change local instrumentation files and dependencies. Hosted connector actions call the control plane and can change connection state. NEAT does not call an LLM to answer graph questions.
51
+
52
+ `semantic_search` uses Ollama (`nomic-embed-text`) when reachable, otherwise it can initialize the in-process `Xenova/all-MiniLM-L6-v2` model. MiniLM downloads its ~23 MB quantized model on a cold cache. Set `NEAT_SEARCH_PROVIDER=substring` for search without model initialization or download, `ollama` to use only Ollama, or `transformers` to use MiniLM explicitly. An unset value keeps automatic selection. The same setting applies to the daemon and `neat watch`.
51
53
 
52
54
  ## Where OBSERVED comes from
53
55
 
54
56
  The observed-facing read tools — `get_observed_dependencies`, `get_divergences`, `get_incident_history`, `get_recent_stale_edges` — reflect two OBSERVED sources, not one:
55
57
 
56
58
  - **OTel spans** — pushed by the instrumented app at runtime. The `/neat extend` tools above are how that gets wired up.
57
- - **Pull connectors** — NEAT polls a provider's own API and folds what it finds into the same OBSERVED layer. Supabase, Railway, Cloudflare, and Firebase are supported. So an integration NEAT never saw a span for can still carry OBSERVED edges, incidents, and staleness — sourced from the platform, not the trace.
59
+ - **Provider connectors** — NEAT polls supported provider APIs or receives their telemetry through a configured drain, then folds that data into the OBSERVED layer. Run `npx neat.is connector --help` for the current provider list; its usage text reads the connector registry. A provider can supply observed edges, incidents, and staleness even without an app span.
58
60
 
59
- Connectors are configured out of band, not through this skill: `neat connector add <provider>` / `list` / `remove <id>` / `test <id>` (ADR-130). Credentials are stored as an env-var reference (`$VAR`) resolved at run time and redacted everywhere, so the agent reads the resulting OBSERVED data but never sees a secret. `GET /:project/connectors` reports each connector's poll health over REST if you need it.
61
+ Connectors are configured out of band, not through this skill: `npx neat.is connector add <provider>` / `list` / `remove <id>` / `test <id>` (ADR-130). Credentials are stored as an env-var reference (`$VAR`) resolved at run time and redacted everywhere, so the agent reads the resulting OBSERVED data but never sees a secret. `GET /:project/connectors` reports each connector's poll health over REST if you need it.
60
62
 
61
- A `ServiceNode` also carries a `platform` string when the extractor recognized the host — `'cloudflare'`, `'vercel'`, `'railway'`, or `'supabase'`, read from a `wrangler.toml` / `vercel.json` / `railway.toml` / `supabase/config.toml`. It's a static (EXTRACTED) signal, surfaced as the provider badge on the dashboard's service nodes.
63
+ A `ServiceNode` may carry a static `platform` hint inferred from repository configuration. It is an EXTRACTED claim, separate from connector observations; inspect the node's provenance rather than assuming a provider is connected.
62
64
 
63
65
  ## Install
64
66
 
65
- The simplest path: add the snippet from `claude_code_config.json` to your Claude Code MCP config.
66
-
67
- **macOS / Linux:**
67
+ For an npx-based setup, run:
68
68
 
69
69
  ```bash
70
- # Print the snippet
71
- cat node_modules/@neat.is/claude-skill/claude_code_config.json
72
-
73
- # Or, with the neat CLI:
74
- neat skill --print-config
70
+ npx neat.is skill --apply
75
71
  ```
76
72
 
77
- Merge `mcpServers.neat` into your existing `~/.claude.json`.
73
+ This merges the `neat` MCP server into `~/.claude.json` without replacing other entries. To inspect and merge the configuration manually, run `npx neat.is skill --print-config`. If `neat` is installed globally, the same commands work without `npx`.
78
74
 
79
- **One-shot install** via the NEAT CLI:
75
+ <!-- GRAPH_FIRST_START -->
76
+ <!-- NEAT graph-first directive. Paste this block into your agent's project
77
+ instructions — CLAUDE.md, AGENTS.md, .cursorrules, or the equivalent.
78
+ Agent-agnostic: it is plain guidance, no Claude Code features required. -->
80
79
 
81
- ```bash
82
- neat skill --apply
83
- ```
80
+ ## Query NEAT before searching files
84
81
 
85
- This merges the `neat` server into `~/.claude.json` without touching other entries.
82
+ This project has a live NEAT graph: code, data and infrastructure declarations
83
+ fused with runtime traffic, incidents and supported provider telemetry. It can
84
+ show what exists, what actually ran, where a failure began, and what may break
85
+ when a node changes. The graph is deterministic: the agent supplies the model;
86
+ NEAT resolves named nodes and traverses recorded evidence rather than asking an
87
+ LLM to infer architecture from file names.
86
88
 
87
- ## Reach for the graph first
89
+ Every claim carries provenance and confidence. `EXTRACTED` comes from recognized
90
+ source or configuration, `OBSERVED` from spans or supported provider signals,
91
+ `INFERRED` from a bridged relationship, and `STALE` marks an observed edge that
92
+ went quiet. Missing runtime evidence does not prove a path never runs.
88
93
 
89
- Wiring the tools in is half the job; the other half is getting your agent to
90
- *use* them instead of falling straight to text search. NEAT ships two nudges:
94
+ **For questions about this system's behavior, structure, data dependencies,
95
+ failures, or change impact, call the MCP `ask` tool (`mcp__neat__ask`) before
96
+ Read/Grep/Glob/Bash.** You do not need an exact node id. `ask` resolves names
97
+ and routes to the relevant graph traversal, returning provenance-tagged facts.
98
+ When MCP is unavailable, use the same door through the CLI:
91
99
 
92
- ```bash
93
- neat hooks --apply
94
100
  ```
95
-
96
- That installs both:
97
-
98
- 1. **A Claude Code search-nudge hook.** A `PreToolUse` hook (materialised to
99
- `~/.neat/hooks/neat-search-nudge.mjs`, wired into `~/.claude/settings.json`)
100
- that fires when the agent reaches for `Grep`, `Glob`, or a Bash
101
- `grep`/`rg`/`find`. It injects a short note steering the agent to
102
- `semantic_search` / `get_dependencies` / `get_divergences` first. It is a
103
- **gentle, non-blocking nudge** — the search still runs; the agent just sees
104
- the graph as the better first move. Your existing hooks are left in place,
105
- and re-running is idempotent.
106
-
107
- 2. **Agent-agnostic graph-first guidance** (`GRAPH_FIRST.md`, also written to
108
- `~/.neat/neat-graph-first.md`). A markdown block you paste into your project
109
- instructions — `CLAUDE.md`, `AGENTS.md`, `.cursorrules`, whatever your agent
110
- reads — so the same "ask the graph before grepping" steer reaches agents on
111
- any harness.
112
-
113
- The hook is Claude-Code-specific; agents on other harnesses (Codex, Gemini,
114
- Cursor, …) don't get the `PreToolUse` interception, but the guidance block
115
- gives them the same instruction. Preview either without installing:
116
-
117
- ```bash
118
- neat hooks --print-hook # the hook script
119
- neat hooks --print-guide # the graph-first guidance
120
- neat hooks --print-settings # the settings.json block --apply merges
101
+ npx neat.is ask "why is checkout failing?"
102
+ npx neat.is ask "what breaks if I change the orders table?"
103
+ npx neat.is ask "what does the payments service depend on at runtime?"
121
104
  ```
122
105
 
106
+ For a failure, ask first, then call `get_incident_card` on the named service,
107
+ file or symbol. The card combines the incident, likely cause, blast radius,
108
+ policies and divergence into a work order. Use `expand` one hop at a time and
109
+ `relate` to test whether the suspected cause and symptom share a signal. Check
110
+ provenance and confidence before acting.
111
+
112
+ Before a change, use `get_blast_radius` and `check_policies` to see dependents
113
+ and advisory architectural rules. Use `get_divergences` to compare declared
114
+ intent with observed behavior, `get_graph_diff` to compare a saved snapshot
115
+ with the live graph, and `get_recent_stale_edges` when traffic goes quiet.
116
+ `get_dependencies` maps a node's outgoing graph; `get_observed_dependencies`
117
+ shows only seen runtime/provider calls. `semantic_search` finds node labels,
118
+ not arbitrary source text.
119
+
120
+ Read source when the graph does not model what you need: comments, arbitrary
121
+ string literals, config details, unsupported syntax, or a repository that has
122
+ not been extracted or connected. If a graph answer is empty, check the daemon
123
+ with `npx neat.is list` or restart it with `npx neat.is up`; wire MCP with
124
+ `npx neat.is skill --apply`.
125
+ <!-- GRAPH_FIRST_END -->
126
+
123
127
  ## Prerequisites
124
128
 
125
- - `neat init <repo>` has registered at least one project.
126
- - `neatd start` is running (or you're OK with `npx -y @neat.is/mcp` spawning per request — slower, but works).
127
- - The `NEAT_API_URL` env var points at the running daemon's REST endpoint. Default is `http://localhost:8080`, which matches the daemon's default port.
129
+ - Build a graph from this project with `npx neat.is` (or run `npx neat.is init . --apply` when setting it up manually). The first-run door starts a per-project daemon in the background.
130
+ - Run `npx neat.is skill --apply` to wire this MCP server into Claude Code. Use `npx neat.is list` to see the project's live daemon and its port; `npx neat.is up` restarts it if needed.
131
+ - The MCP server depends on `@neat.is/core`, so a fresh `npx -y @neat.is/mcp` installs about 560 MB the first time (about 300 MB with `--omit=optional`); a global `neat.is` install already carries it.
128
132
 
129
133
  ## What's not in MVP
130
134
 
@@ -134,6 +138,6 @@ neat hooks --print-settings # the settings.json block --apply merges
134
138
 
135
139
  ## Where to look when it doesn't work
136
140
 
137
- - `neatd status` — confirms the daemon is running and which projects are registered.
141
+ - `npx neat.is list` — shows registered projects and their daemon status/ports.
138
142
  - `~/.claude.json` — the config file. Look for `mcpServers.neat`.
139
143
  - `claude mcp list` — Claude Code's built-in inventory of MCP servers.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@neat.is/claude-skill",
3
- "version": "0.10.6-dev.20261007",
3
+ "version": "0.10.6-dev.20261009",
4
4
  "description": "Claude Code skill drop-in for NEAT — wires the @neat.is/mcp server into Claude's MCP config",
5
5
  "license": "Apache-2.0",
6
6
  "homepage": "https://neat.is",