Start here

A first workflow · no installation required

Turn one piece of work into context you can check and reuse.

When a new agent session starts, a long transcript can obscure the decision that matters. A small handoff gives the next session a goal, the source behind it and an explicit next step. Try this with one repository you already know.

1. Capture the decision and its limits

Write a short Markdown file. Use this example as a template and replace its paths and headings with ones that exist in your repository. The example describes a documentation check; it is not a claim that any command has passed.

# Repository handoff

Goal: document how this repository starts locally.
Decision: use the commands in README.md as the starting point.
Evidence: README.md, section “Development”.
Uncertainty: the commands have not been run in this environment.
Next step: run the documented command and record its result.
Constraint: do not change application code for this check.

The uncertainty line matters. Without it, a later session may read “use this command” as “this command has been tested.” Keep the evidence and the action separate.

2. Ask one bounded question

Give your agent the handoff and the named source file. In a chat without file access, paste only the relevant section with its filename and heading.

Read this handoff and the Development section of README.md.
List the exact prerequisites and startup command.
Cite the file and heading for each answer.
If the README does not answer something, say what is missing.
Do not infer that the command works just because it is documented.
Do not change files or run commands yet.

A useful answer names the prerequisites, identifies the exact command, and points back to the section you supplied. If a prerequisite is missing, the answer should preserve that gap.

3. Check the result against the source

  1. Open each cited heading. Confirm that it exists.
  2. Compare the command and prerequisites with the actual text.
  3. Separate what the source says from what the agent inferred.
  4. If you choose to run the command, record the environment and result. A command printed in an answer is not a successful test.

If the answer adds an unsupported prerequisite or invents a heading, correct the handoff before reusing it. More context does not automatically repair a bad source.

4. Keep only what the next session needs

Update the handoff with the observed result and the remaining step. Keep the source pointer. Move the detailed log to a separate file if it grows large. This gives the next session a concise continuation point and leaves the evidence available for inspection.

For the design behind this separation, read State That Survives the Session. It describes an architecture and its limits; it does not report a measured improvement in recall.

Where to go next