Save an artifact (HTML page, React/JSX component, report, game, etc.) permanently to the user's HyperVault and get back a shareable URL.

React/JSX content is detected automatically and wrapped into a working standalone page — you can pass a bare component and it will just work.

Read the current source of one of the user's artifacts, so you can iterate on it.

Returns the editable source: the raw React/JSX for a JSX artifact (what the page re-wraps and renders), or the stored HTML otherwise — not the wrapped page chrome. Pair it with write_artifact to make an edit: read, modify the returned content, then write it back.

Write a new iteration of a mutable artifact — a git commit on the living document.

The artifact is updated to the new content in place (its URL never changes), and the write is kept as a version you can list with artifact_history and revert to. Only artifacts saved with mutable=true accept writes; an immutable artifact returns an error telling you to re-create it as mutable. React/JSX is auto-detected and re-wrapped, exactly like save_to_hypervault. Writing content identical to the current version is a no-op (returns unchanged: true, no new commit).

Typical loop: read_artifact(ref) → modify the returned content → write_artifact(ref, new_content, message="what changed").

List the version history (git commits) of a mutable artifact, newest first.

Each entry carries the commit message, its author (you'll appear as your API key prefix), the content fingerprint, and whether it's the current head. Use the returned version ids with read_artifact(ref, version=...) to inspect an old iteration, or write its content back to revert.

Claim a vanity subdomain (e.g. nova.vault.cool) for the user's vault.

The claim takes effect immediately — the address serves the user's public vault as soon as this returns. Names are lowercase letters, digits, and hyphens, 2–63 characters. Pro accounts can hold up to 10 subdomains, and every one of them serves the user's full vault.

Connect two items already in the user's HyperVault.

Items can be artifacts or memories, in any combination: artifact↔artifact, memory↔memory, or memory↔artifact (a semantic bridge between the wiki and the vault). Connections are bidirectional and appear as edges in the vault's graph view. Use list_my_vault_items or recall_from_memory first to find the right items.

List the artifacts already saved in the user's HyperVault.

Useful before saving (to avoid duplicates), or to link new artifacts to existing ones via save_to_hypervault's connect_to parameter.

Returns: dict with items: a list of {url, slug, title, type, tags, is_pwa, is_jsx, created_at}, newest first.

Permanently delete an artifact from the user's HyperVault.

Deletion is immediate and irreversible: the share URL stops working and the item's graph connections are removed. Use list_my_vault_items first to find the right item, and only delete when the user clearly asks.

Save a multi-file "artifact group" — several .html/.css/.js/.jsx files that run together as one project — to the user's HyperVault.

Unlike save_to_hypervault (a single file), a group bundles a whole little project: markup, styles, and script(s) as separate files that reference each other normally (e.g. <link href="style.css">, <script src="app.js">). It is always run/previewed as a container, similar to a JSFiddle: the returned URL opens a minimal editor/preview UI where the files render together, routed through the required root index.html.

Read an artifact group's full file set and metadata, so you can iterate on it (e.g. before calling edit_artifact_group_item).

List the artifact groups already saved in the user's HyperVault.

Useful before creating a new one (to avoid duplicates) or to find a slug to pass to read_artifact_group / add_artifact_group_item / etc.

Returns: dict with items: a list of {url, slug, title, tags, file_count, visibility, created_at}, newest first.

Add a new file to an existing artifact group.

Fails if a file already exists at that path — use edit_artifact_group_item to change one, or read_artifact_group first if you're not sure what's already there.

Replace the content of an existing file in an artifact group.

Fails if no file exists at that path yet — use add_artifact_group_item to create one. This is also how you update index.html itself.

Remove a file from an artifact group.

The root index.html can't be removed this way — a group must always keep its entry point. Replace its content with edit_artifact_group_item instead, or delete the whole group with delete_artifact_group if you no longer need it.

Permanently delete an artifact group from the user's HyperVault.

Deletion is immediate and irreversible: the share/preview URL stops working and the group's graph connections are removed. Use list_artifact_groups first to find the right one, and only delete when the user clearly asks.

Store a chunk of context in the user's private memory wiki (Imaging V2).

Call this whenever the user says "remember this", "memorize this", or shares a decision, preference, or insight worth keeping beyond this session. The backend auto-titles, auto-tags, and summarizes the chunk, then links it to related memories in the user's knowledge graph. Memories are private to the user — they never appear on public pages.

Search the user's private memory wiki with a natural-language query.

Use this to answer questions like "what did I say about the Rust borrow checker last month?" — it combines full-text search with relevance scoring over the user's stored memories. The top matches include the exact stored content; the rest return summaries. Each result also lists the titles of linked memories, so you can follow the knowledge graph with further recall calls.

List everything in the user's private memory wiki, newest first.

Useful for a broad look at what the user has memorized before deciding what to recall in detail — each entry carries the summary and tags, not the full content.

Delete one memory from the user's wiki (recorded as a delete commit).

Only call this when the user explicitly asks to forget or delete a memory. The memory's knowledge-graph links are removed with it. The deletion is a commit, so the page stays in history and can be restored with mind_revert.

Edit a wiki page — the change lands as an update commit, never overwriting history (see memory_history for the page's revisions).

Content edits re-derive the summary and merge in fresh auto-tags; new knowledge-graph links ride in the same commit.

Every revision of one wiki page, newest first — its edit history.

Each revision carries the commit that produced it: message, author (the user, or the agent key prefix that wrote it), branch, and time. Pass a revision_id to mind_revert to restore an old version.

git log for the user's mind: the branch's commit history, newest first, with per-commit change counts and authorship.

List the branches of the user's mind, with live memory counts.

Returns: dict with branches: [{id, name, is_default, head_commit_id, created_at, memory_count}].

Branch the user's ideas: fork the wiki so edits, new memories, and forgets there don't touch the source branch until merged.

Branch names are lowercase letters, digits, and /_- (max 63 chars).

Diff the user's mind between two refs — branch names, commit ids, or timestamps ("what changed in my memory since last week?").

Without memory_id: memories added/changed/removed (with content hunks) and links added/removed. With memory_id: just that page's diff.

Merge understanding: fold a branch into a target (default main) with a three-way merge from their common ancestor.

Memories only one side touched merge automatically; links merge set-wise. If both sides changed the same memory the call fails with the conflict list (each has base/ours/theirs snapshots and hunks) — resolve by calling again with resolutions like [{"memory_id": "...", "resolution": "theirs"}] or [{"memory_id": "...", "resolution": {"title": "...", "content": "..."}}] for a hand-merged version. Relay conflicts to the user when the choice isn't obvious.

Restore a memory to an earlier revision — including undeleting a forgotten one. History is never rewritten: the restore lands as a new commit.

Find revision ids with memory_history.

Time-travel: the whole wiki (memories + links) as it stood at a commit, branch head, or moment in time.

Create a universal task board — a shared, versioned task list that you and the user work from together.

One call creates both halves: a JSON data artifact (tasks-{project}) that you sync through with the other task_* tools, and an interactive board page (taskboard-{project}) the user opens to watch and steer the work live. The board URL is the deliverable — after creating one, tell the user to open board.url; the data artifact isn't meant to be read by humans.

Use this at the start of any multi-step piece of work the user will want visibility into. Seed it with the plan you already have — passing tasks up front is much better than creating an empty board and adding tasks one call at a time.

List the user's existing task boards, so you can join one instead of creating a duplicate.

Call this at session start when the user refers to ongoing work ("keep going on the choir firmware") and you don't already have the project id.

Returns: dict with boards: [{slug, project, title, url, created_at, updated_at}], and the schema URL.

Read a task board's full list — every task with its status, assignee, lock, and note thread.

Read this at session start, and re-poll it at tool boundaries so the user's steering from the board page (re-prioritizing, adding tasks, unblocking you) is picked up while you work. Pass since_version for the cheap poll: when nothing changed you get {unchanged: true, version} back instead of the whole list.

Get a board's rollup — counts, progress, epics, and who's holding what — without pulling every task.

Prefer this over tasklist_get whenever you're reporting status to the user or deciding what to pick up next; a large board's full list is token-heavy.

Add a task to an existing board.

Add work as you discover it — a task you create here shows up on the user's board immediately, which is the point. Prefer seeding known work through create_task_board's tasks argument; use this for what comes up mid-session.

Patch one task on a board — status, progress, a note, or any other field. Only the arguments you pass are changed.

Push every meaningful change the moment it happens: the user's board polls the same list, so a note or a progress bump is how they see you're alive and steer you before you go too far. note appends to the task's thread (nothing is overwritten) and metadata merges key-wise.

Claim a task before you start it — a lock plus assignment, so multiple agents can share one board without colliding.

Claiming sets the task to in_progress, assigns it to you, and takes a lock (60 minutes by default, 24 h max; re-claiming your own task renews it). Claim deliberately: prefer tasks already assigned to you or unassigned, and never silently take another agent's live claim — a live foreign lock fails with a 409 naming the holder. Use force only when the holder is clearly gone (expired locks are claimable without it).

Mark a task done: status done, progress 100, lock released, in one call.

Complete a task as soon as it's actually finished — don't batch completions at the end of a session; the user is watching the board fill in. Pass a closing note saying what landed. A done task can't be re-claimed.

Extract the original source prompt from a HyperVault artifact URL.

HyperVault artifacts can carry the prompt that generated them as a hidden