Walkthrough
From a vague bug report to a brief worth handing over
One worked example, start to finish. The case is deliberately ordinary: checkout fails sometimes, nobody knows why, and you would like an assistant with the repository open to help rather than guess. Roughly ten minutes.
The situation
Someone forwards you a message: "checkout is broken for some people, can you look?" You have the repository. You want to hand this to a coding assistant, and you want it to go and read the code rather than invent a plausible-sounding theory.
That last sentence is the part most planning tools drop, and it is the part this walkthrough is really about.
Step 1. Say where you are standing, before you draw anything
Open the Prompt tab and fill in Situation first. It is four choices and takes about fifteen seconds:
- Codebase → This repo. The code exists and the assistant can see it.
- Running in → Claude Code. It has file and shell access.
- Start by → Reading the code. Before any theory.
- Boundaries. One per line. Here:
Reproduce before theorising.
The panel shows you the exact lines this produces, because the point is being able to read what you are about to hand over:
## Situation
- This is a planning canvas exported from Pathfinder. It is a plan, not a codebase,
and not a record of what exists. Everything below is what somebody mapped out;
none of it is verified unless this section says otherwise.
- The relevant repository is open to you. Read it before trusting this canvas: the
canvas records what somebody believed, the repository is what is actually there.
Where the two disagree, the repository wins and the disagreement is worth reporting.
- You are running in Claude Code with file and shell access. Prefer reading the
repository over asking about it, and cite file paths for any claim you make.
- Start by reading the code. Reconcile it against this canvas and report what does
not match before proposing anything.
Change Codebase to None yet and the same canvas tells the reader that nothing in it can be checked and every technical claim is unverified. Same blocks, opposite instruction. That is the whole reason this section exists.
Step 2. Get the mess out of your head
On an empty canvas you get a Brain Dump box. One idea per line, no formatting, no thinking about types:
checkout 500s for some people
started sometime last week maybe?
probably the payment service
we deployed on Tuesday
does it happen on staging
no test covers the retry path
Press Turn into blocks. Each line is classified and dropped on the canvas as a typed block, with a correction chip under any it was unsure about. Fix the wrong ones with a click. Two minutes of typing beats twenty minutes of dragging boxes.
The shortcut for this exact case: the Investigate a Bug template in the palette. It lands thirteen blocks, arranges them, and sets the Situation to match in one click. Use it as scaffolding and delete what does not apply.
Step 3. Separate what you know from what you assume
This is the step that earns its keep. Look at the line "probably the payment service". That is not a problem, and it is not a question. It is a belief you are about to act on without checking, which makes it an Assumption.
The distinction is not pedantry, because the export treats the three differently:
- Problem: the observable symptom. Checkout returns 500 on card payments. Stated without a theory attached.
- Assumption: a belief nobody has checked. It started with Tuesday's deploy. The prompt tells the reader to pressure-test it, and when the repository is reachable, to go and settle it rather than ask.
- Open Question: a genuine unknown. Does it happen on staging? The prompt tells the reader that guessing here is how the plan goes wrong.
Select the "probably the payment service" block and switch its type to Assumption. A Question block has a one-click Promote to Assumption button for exactly this moment.
Step 4. Connect them, and say why
Drag from the dot on a block's edge to another block. Then select the arrow and give
it a label from the presets: depends on, blocks,
underpins, mitigates. Unlabelled arrows say two things are
related; labelled arrows say how, and the export carries the label through as the
dependency order.
If an arrow leaves from an awkward side, select it and pick a side under Connection points, or drag its endpoint handle onto the port you want. Connections route themselves around other blocks, so you should rarely need to.
Step 5. Press Tidy
L, or the Tidy button. The canvas is rearranged into layers along the flow, connections are re-pointed to match, and the toast tells you how many crossings are left. The direction toggle beside it switches between left-to-right and top-to-bottom.
It is one undo step. If you hate the result, Cmd/Ctrl+Z puts every block back exactly where it was.
Tidy is also a diagnostic. If the result looks like a straight line with everything dangling off one node, your canvas has one real idea in it and a lot of decoration.
Step 6. Read what the tool is telling you
Blocks with a pulsing icon have a gap. An isolated block is connected to nothing, which usually means it does not belong or you have not finished the thought. An assumption not anchored to a goal or requirement is one nobody has said why they care about.
The readiness pill in the corner is blunt on purpose. If it says the canvas is thin, the prompt will be thin, and no amount of mode-switching fixes that.
Step 7. Pick what you want back
The mode reshapes the whole document, not just a header line:
- Investigate: establish what is true. Every finding must carry its evidence, unknowns stay marked as unknown, and disagreements between canvas and reality get reported rather than smoothed over. The right mode here.
- Explore: pressure-test the canvas itself. Gaps and questions, no solutions.
- Plan: a phased plan with outputs per phase.
- Build: requirements as a task checklist, once the plan is settled.
- Clarify: questions only, ranked blocking first.
Step 8. Hand it over
Copy AI-ready prompt in the corner, or Export ▾ for a file. What lands in the paste buffer opens like this:
## Situation
- ... (the four lines from step 1)
## Task
Investigate. Establish what is actually true before anything is changed or
proposed. Work outward from the Problems and Open Questions below.
For each finding, state the evidence you based it on. Where you could not
establish something, say so plainly rather than filling the gap with a plausible
guess. Where this canvas and reality disagree, report the disagreement.
Treat each Assumption below as believed-true-until-disproven. Several of them are
probably settleable from the repository you have open. Check those against the
code and label each result verified or still open, rather than asking about
something you could have read.
Then the blocks, grouped by type, with the connections as a dependency list. The assistant knows what kind of document it is holding, what it can reach, and what to do first, before it has read a single one of your boxes.
Step 9. Before you present it
A canvas you are about to walk somebody through has a different job from one you are working in. Select the blocks that carry your point and give them a Highlight: Alert for the thing to look at first, Focus for what you are discussing, Festive if you want a moving border nobody can ignore.
Right-click any block and choose Select all Problems to mark a whole type at once. Then turn on Spotlight, which fades everything you did not mark. The contrast does the work, not the colour.
Highlights say "look here" and nothing more. They travel with a share link and reach the image export, but they stay out of the prompt on purpose: the block type already says what a block is, and colour that means two things at once means neither.
Step 10. Bring the answer back
An investigation that ends in a chat log is an investigation you will run again in three weeks. Put what came back into the canvas:
- An answered question goes in the question's Answer field. It travels with the canvas and shows up in the next export.
- A settled assumption becomes a Decision, with the evidence in its description. Then delete the assumption. It is not one any more.
- Something new that was discovered becomes a block wired to whatever it affects.
Now the canvas is worth more than when you started, which is the only test of whether a planning tool was worth using.
Other formats
- Download Markdown: every block type as a section, connections with their labels, and a Mermaid graph of the topology for anything that renders it.
- Download JSON: the whole canvas including the Situation. This is the one to hand a terminal session directly.
- Share → Copy link: the entire canvas encoded in the URL. Nothing is uploaded; the link is the data.
- Copy AI diagram-builder prompt. The other direction. Paste it into any assistant, describe your problem, import the JSON it hands back.
- Examples: three more finished maps to load and reshape: inherit a codebase, migrate a system, the blank bug template.
- llms.txt: the format spec, if you would rather generate canvases than draw them.