research

Research in Merv

A Merv project holds a living paper, tasks, experiments, reviews, immutable files (artifacts), code, and the machines and agent sessions that do the work. Every call you make runs as the person whose key connected you, with their role in the project, checked by the server on each call. Each tool's description is its contract; this skill is the order to use them in.

Merv's UI is at https://experiments.rapidreview.io/ui/. When the person needs to see the UI, open that address for them in their browser.

Noun tools take {"action":"x","x":{...}}, with the selected projectId at the top level. For example, workflow.read takes {"action":"status","status":{}}.

Orient first

1. Use the saved Merv remote MCP connection. If it is absent, follow the server's /connect/agent.md guide once. If authentication is required, use the client's browser sign-in action. Never ask for credentials or email codes. Call project.list or project.read (list), select the intended project and pass projectId on every call. Ask which project when ambiguous, including in fresh chats; never silently inherit a previous chat's selection. If none are accessible, explain how to create/join one on the website, then list again without reconnecting. Change the explicit projectId to switch projects and read its brief to check your role. For code-linked work, use the bundled git-access skill by default: preserve origin, configure a separate Merv remote, sync the intended user branch initially and after meaningful commits, and verify remote freshness before cloud work. The same saved connection supplies Git access; no Settings key or second sign-in. Report dirty/local-only data as unsynced and distinguish branch sync from reviewed baseline integration. Research work without local code needs no repository.
2. project.read (brief): your first read in a project, and again whenever you lose the thread. Who you are (actor, role), the project, today's date (UTC) and the paper as it is now.
3. workflow.read (status) with no instanceId: every unfinished record, what it waits on and what comes next. Work whose review rounds are used up is listed under escalated.
4. workflow.read (status) with an instanceId (a work item's id): its gate, your next action, blockers, references, revision, and limits (review rounds used and left at each gate). The guidance it returns is how the server says what it expects: follow it.
5. Read more as needed: project.read (records) indexes every task and experiment, experiment.read (get) reads current experiment context with full-history references, task.read (get) one task, paper.read (get) the paper, and project.read (references) resolves ids to labels, states and revisions.