Call this BEFORE writing any code. Returns the user's own rules and conventions for the area you are working in, plus a list of deeper reference material you can pull in on demand. Pass task: one short sentence describing what you are building (e.g. 'build a Node.js REST API for user auth'). Do NOT paste the user's full prompt — a long query retrieves badly. If the user named a collection with @, pass it as collection instead; an explicit name always wins over inference. Call this again whenever the work shifts to a different area (frontend → backend, say). If it returns nothing, the user has no context saved for this area: say so rather than inventing conventions.

Pull in a specific piece of the user's saved research, chosen from the manifest that devvault_context returned. Search with the vocabulary of the thing you are building ('hero image loading', 'websocket reconnect'). Anything already delivered this session is reported as such rather than sent twice.

Fetch a container's complete content when the rules you were given are not enough. Use the id from a search result or the manifest.

After reading a container whose result said it has no cached rules, distil it and save the result here so no future session has to re-derive it. IMPORTANT: extract EVERY actionable rule in the container, not only the ones relevant to what you are building right now — these rules are reused for unrelated tasks, and a narrow extraction is worse than none. One imperative rule per line. Drop background and explanation; keep code examples and links. Rules a user wrote by hand are never overwritten.

Show which collections exist, with their descriptions. Useful when the user refers to a collection you cannot resolve, or when deciding where to save research.

File the current conversation's findings into the user's vault as structured containers, so neither of you has to re-derive them next time. You decide the structure: group by topic, one topic per container, and nest sub-topics as children. Write real titles. Constraints are enforced server-side and anything over them is repaired automatically (long paragraphs split, extra blocks spill into continuation containers, deep nesting is flattened and linked) — the response tells you exactly what was adjusted, so report that to the user. Always set external_key on every container: re-running the same research then updates in place instead of duplicating. Supplying agent_rules alongside the research is worth doing — it saves a future session from re-reading the prose.