Hexis

List every draft known to the repository (protected versions + unprotected drafts, local and on the shared remote). Returns `{ branches: [{ name, isProtected, ahead, behind, hasRemote }] }`. Takes no arguments — branch listing is repo-global, not scoped to any one draft.

List a change request's changed files (GitHub: list pull request files). Each answers `path`, `change` (`added`, `changed`, `deleted` or `moved`, a moved one with its `previousPath`), `additions` and `deletions` — the same words `open_change_request` uses — plus who must approve it (`requiredApprovers`) and who has (`approvedBy`). No patch is returned unless you ask with `include: ["patches"]`. Read-only. Files you may not read are left out and counted in `withheldFiles`, never named.

List a change request's reviews (GitHub: list reviews): who approved what, and when. Hexis approves per FILE, so each entry names a `reviewer`, the `files` they approved and the time of the latest of them; `stale` is true for approvals a later push invalidated. Nothing records who DECLINED a request, so no entry reports one. Read-only: an entry keeps only the files you may read, and one with no readable file at all is counted in `withheldReviews` rather than named.

List change requests (GitHub: list pull requests), newest first. Filter by `state` (`open`, the default, `closed` — which covers applied and declined alike — or `all`), `head` (source branch), `base` (target branch) and `author` (an email or a `login`). Each answers in Hexis's own words: `url`, `number`, `title`, `state` (`open`, `merged` or `closed`), `sourceBranch`, `targetBranch`. Read-only, and limited to what you may read: a request whose files are all closed to you is not listed unless you opened it, and `withheldFiles` counts the ones left out of each.

The history of one file on `branch`: its commits, newest first — who made each, when, and its subject — as the app's History tab shows them. `limit` caps the list (default 20, at most 100). Read a version with `read_file_at` and its diff with `compare_file`. Takes the read the file itself takes; a folder has no history of its own (ask per file).

Description is built at runtime.

Description is built at runtime.

Merge branch `source` into branch `target` as you, and publish `target`. An agent proposes and syncs; a person merges: this tool never lands a change request. It refuses while a change request from `source` into `target` is open (naming it): ask the user to review it in the app. It refuses when `target` is a protected branch unless you could commit every changed file directly to it. SYNC: merging the target into your draft (`source` = the change request's target, `target` = your draft) is always allowed, even with the draft's request open. Writes are committed asynchronously; the merge first w…

Create a directory (recursive). It lists as an empty folder and persists in git until it is deleted explicitly.

Move or rename a workspace FILE or FOLDER; a folder moves recursively, with everything under it. `dest` is the full new path, not the folder to move into. Committed + pushed as you. The destination must not exist — a move never overwrites a file or merges into a folder. Access follows the DESTINATION folder, so a move can change what you (and others) may do with the file: the dry run answers `{ src, dest, kind, descendants, access: { before, after }, accessChanges, allowed, reason? }`, where `access` is your own `{ read, write, download, owner }` at the source and at the destination AS IT WILL…

Description is built at runtime.

Read a workspace file as text. Returns `{ path, content, canWrite }`. Per the shared content rule: text as text, documents and email as extracted text, an image as the picture, anything else as a one-line description. Also reads a `__tool_chain_spill__/…` ref back from a truncated `call_tool_chain`: it belongs to no workspace, so `branch` is ignored and no `canWrite` comes back. `offset`/`limit` slice the content (characters; bytes for a spill ref; ignored for an image): page through large files and spills, never read multi-MB whole. `canWrite`: may you change this file directly on the default…

One file as it was at a point in history: `at` is a commit (from `list_file_changes`, on `branch`'s own history) or the name of another branch (its published tip). Answers `content` (null when the file was not there) and `sha`, the commit it was read at; for a commit, also `before`, the file just before that commit. To put an earlier version back, write it with `write_file`. Takes the read the file takes at that point.

Description is built at runtime.

Ask for a one-time address to send FILE BYTES to, so their content never passes through this conversation. Use it for anything `write_file` cannot carry faithfully: a large file, a file full of backslashes or `\u` escapes, a binary file (a PNG, a PDF, a zip), or many files at once (zip them). Returns `{ uploadUrl, token, expiresAt, expiresInSeconds, maxBytes }`. THEN: (1) POST the file as the raw request body to `uploadUrl` with `?filename=<name>` — `curl -X POST --data-binary @skill.zip "<uploadUrl>?filename=skill.zip"` — which answers what it received; (2) call `apply_file_upload` with the s…

Schedule the file at <path> for commit + push using whatever bytes are on disk (no content rewrite) — for binary uploads or files left uncommitted. On lock contention returns `{ saved: false, reason }` rather than throwing. The commit lands asynchronously.

Publish the current branch to the shared remote so teammates and any change request pick up your commits. No arguments. Refused on protected branches without write permission.

Switch the agent to a different draft for the NEXT user turn. The current turn finishes on the original draft (writes from this point still land there), so finish anything important first. Validates the target exists (use list_branches if unsure) and pre-warms its clone; the frontend navigates on turn completion. After calling, summarise the switch and stop.

Get full TypeScript interface definitions for named tools (names from `list_tools`). The schemas are the source of truth — do not guess shapes.

Extract a .zip already in the workspace (defaults to the zip's parent). Returns extracted files + skipped entries. Existing files are overwritten.

Bring another branch into `branch` as a merge commit by you, and publish it: `from` (a draft's target, to refresh the draft), or left out, the branch's own shared state when it moved while this workspace held commits (`branch_status` says `behindRemote`). Never a protected branch. CONFLICTS: the first call answers `conflicts` naming every conflicted path with the file at the merge base, on each side (`ours` = `branch`, `theirs` = `from`) and the working copy with git's markers, and leaves the branch as it was. Decide each file (keep both sides' information unless one is clearly stale; `list_fi…

Change the title and/or the description of an OPEN change request. Allowed for its author and for anyone who may merge it (an admin, or someone who may approve every file it changes) — the same rule as the app's Edit control; anyone else is refused (403), and so is a merged or closed request (409), in words. `description` replaces the request's description whole — the text `get_change_request` answers as `body`; `appendDescription` instead adds a paragraph after the description as it stands when the write happens, so two notes racing each other both land (never together with `description`). Gi…

Write a workspace TEXT file. The change is committed + pushed as you. Returns `{ path, bytes, outcome }`, where `outcome` is `created`, `replaced` or `updated`. Large, escape-heavy or binary content does not go through here: use `request_file_upload` + `apply_file_upload`.

Batch-write many files in ONE commit — far faster than calling write_file once per file when creating many files at once (e.g. seeding a knowledge base). Each entry is `{ path, content }`, and the files it writes are committed + pushed together as you. Prefer this over many write_file calls. Text files only. Returns `{ count, files }`: one entry per REQUESTED path, in the order you gave them, each `{ path, outcome }` — `created` / `replaced` / `updated` for a path it wrote, or `refused` with `error` (the code) and `message` (why) for a path it could not. `count` is how many were written. A pat…