Trail 1, a checklist an assistant can pick up again next week

An assistant that works for an hour keeps its plan in the conversation. An assistant that works for three sessions over a week does not, because the next session starts from nothing. Trail 1 is the part of VenusMCP that holds the plan outside the conversation, so any session can open it, see what is done and carry on.

When to use it

Trail 1 is for work with more than a few steps or more than one session: an app, a feature that touches several files, a migration, a setup. It is not for questions or one step tasks, where a plan only adds overhead.

The four calls

Trail 1 is four tools that share one project.

Plan

venus_trail_plan takes the goal and everything about the situation that shapes the plan: the stack and its versions, the existing code and files, the constraints, what is already done and what done looks like. It returns a project id and a checklist.

Step

venus_trail_step updates one step. A step is marked doing when work starts and done once its done-when check passes. Each update returns the next step, and a short note can be attached when something is worth remembering, such as a file path, a decision or a version.

Revise

venus_trail_revise is for when the plan stops matching the work. Mark the step blocked with the reason, then revise. The revision happens in the same planning chat, so it keeps the earlier reasoning, and finished steps are kept as they are.

Open

venus_trail_open returns a saved project, so a later session can continue it.

What a good plan input looks like

The quality of the checklist follows the quality of the first message. Compare two inputs.

A weak one: build a login page.

A better one: add email and password sign-in to an existing Next.js 14 app that uses Postgres through Prisma. The user table exists and has no password column. Sessions must use cookies and not local storage. The work is done when a new account can sign in, sign out, and be refused with the wrong password, and the existing tests still pass.

The second gives the planner versions to be careful about, a starting state, a constraint and a definition of done. Every step in the returned checklist then carries a check that can be run.

Where the plan is kept

The project is stored as a record on the server, and records are not kept forever, so a plan for work that will outlast a few weeks should also be written down in the repository. Because the server is open and has no accounts, a project can carry an owner key: a private phrase of 8 or more characters given when the plan is created. The server keeps only a hash of it. Opening a project later with the same phrase proves it is yours, and the phrase itself is never stored.

Write the project id where the next session will find it: a notes file in the repository, a memory, or the conversation with whoever you are working for.

When a step fails

The useful moment in a long task is the one where the plan is wrong. Mark the step blocked and say why in the note, then revise. The reason goes into the revision, the earlier steps stay done, and the new steps replace the ones that no longer fit. Nothing needs to be explained again from the beginning, which is the thing a fresh session would otherwise cost.

Trail 1 is available as a tool from VenusMCP, and the rest of the tools are described in the guide.

Written by Caisson AI. Questions or corrections go to hello@caissonai.co.