Notes on coding agents and the pages they leave behind, on moving between notes apps, and on the plain mechanics of keeping what you think. Written and published from a Sumibako vault.
Plan mode writes a good plan and leaves it in a terminal. Three ways to hand it to someone, from a draft pull request to one command that returns a link.
Prashant Shaw
Founder, Sumibako
6 min read
Plan mode is the best thing Claude Code does. You switch it on, describe the change, and it reads the codebase and writes out what it intends to do before it touches a file. Most days that plan is the most useful document produced all day. It is also, most days, the one nobody else gets to read.
This post is about the second half: getting the plan out of the terminal and in front of the person who needs it. Three ways, with the honest trade-offs of each. I use all three, for different readers, and the third one is mine, so read that section with the appropriate suspicion.
📍 Where the plan actually goes
You enter plan mode by pressing Shift+Tab until the status bar says plan mode is on, by starting a single prompt with /plan, or by launching with claude --permission-mode plan. The Claude Code docs cover the approval flow. While the plan is on screen, Ctrl+G opens it in your editor, so you can strike out the step where it wants to rewrite your auth layer "while we are in there".
For the plan itself, that is where the built-in support ends. Plan mode has no share button. I looked, twice, the second time with more coffee. What Claude Code does have, since June 2026, is artifacts: ask for one and it publishes a page on claude.ai, which on a Pro or Max plan you can share as a public link. It needs a paid Claude plan, and the page is a capture that Claude edits rather than a document you do. I compare it with Cursor's and Codex's versions in a separate post. The plan file itself lives on your machine,
, and in the conversation, which is the part that gets compacted when the context fills up. If your reviewer, your client, or the teammate picking this up tomorrow is not sitting at your terminal, moving the plan is your job.
Historically that has meant pasting it into a chat message, where it enjoys a useful life of about four hours. Here are the three ways that last longer.
1️⃣ Commit it and open a draft pull request
Ask Claude to write the plan to a file in the repository, then treat it as the first commit of the work:
gh pr create with --draft opens it without asking anyone to review code that does not exist yet.
When it is right: the reader has access to the repository and the plan is going to be reviewed like code, line by line, with comments in the margin. The plan then lives next to the diff it produced, which is the best place for it once the work is done.
When it is wrong: the reader does not have repository access. A client, a manager, a designer, a contractor on a different repo. GitHub answers all of them with a sign-in page, which is a poor way to say "here is what I am going to do for you". It is also heavy for a plan that will be revised four times before anyone approves it, because every revision is a commit, a push, and a notification to everyone watching the repo about a document that is still wrong.
2️⃣ Put it in a gist
One command, and you get a link. Gists render Markdown properly, keep a revision history, and a gist created this way is secret by default: not listed anywhere, readable by anyone who has the address.
When it is right: a one-off. The plan is finished, the reader needs it once, and you do not expect to revise it. This describes roughly none of my plans, but it may describe yours.
When it is wrong: revisions. The gist is a copy. When Claude revises the plan, the copy does not know, and updating it means gh gist edit with the gist's id, which you now have to keep track of, per plan. Nothing stops you and nothing helps you, and the practical result is a link that goes stale the first time the plan changes, which is to say on Tuesday. The gist is not in your notes either. In a month you will have forty of them and only the GitHub gist list to find the one you want, and the gist list is where documents go to be forgotten with dignity.
3️⃣ File it into your notes, and get the link from the same command
This is the one I built, so here is where you get suspicious.
The first time you run it on a machine, it prints a link and stops. Open the link, check that the code on the page matches the one in the terminal, and approve. Run the same command again and it files the page into your Sumibako vault and prints the public link. There is no token to paste, which matters more than it sounds: it means Claude Code can run this command itself, relay the link to you, and carry on once you have approved it. Nobody copies a secret out of a settings page into a chat window, which is a sentence I hope never to write again.
The part that makes it different from a gist is the second run. The file's path is the key. Publish docs/plans/auth-rewrite.md again after a revision and it updates the same page, so the link you sent yesterday shows today's plan. Five revisions are one page and one link, not five.
And the page is in your notes, under a page called Agent notes, with the rest of what your agents have written. It arrives with an icon the agent chose, because the skill tells it to pick one and a page without one looks unfinished. You can open it on your phone, search for it in a month, edit it by hand, and the link keeps working.
**WARNING: **A public link is exactly that: anyone with the address can read it, and the only protection is that search engines are told not to index it. Do not publish a plan that quotes a credential or a customer. The skill below tells Claude to check for exactly that before it passes --public.
The free plan holds a thousand pages, a thousand of them published, and 500MB, which I have not come near, and I am the one writing a blog into it. The numbers are on the pricing page, and everything the command can do is on the agents page.
🤖 Letting Claude do the filing
The workflow I actually use is one prompt, after approving a plan:
Write the plan to docs/plans/auth-rewrite.md, then publish it with npx sumibako publish docs/plans/auth-rewrite.md --public and give me the link.
If you want Claude to know the command without being told, there is a skill:
Or, for a single session, paste this instead: "Fetch https://sumibako.com/skill.md in full and follow it." The skill teaches it the publish command, the update-in-place rule, the icon, and the check before anything goes public. It also teaches it what exit code 3 means, which is the "not connected yet, here is the link" state from the first run, so it relays the link instead of declaring an emergency.
🧭 Which one, then
The reader
Use
Has repo access and will review it like code
A draft pull request
Needs it once and it will not change
A gist
Is outside the repo, or the plan will be revised after it is sent
A page with a link
Whichever you choose, do it before the context window fills. The plan is the one thing from the session that was worth keeping, and by default nothing keeps it. Not even Claude, who wrote it, and who will cheerfully write a slightly different one tomorrow.
ChatGPT Space and Pages explained: which plans can make a page, what replaced Library, how Projects differ, sharing and training, and the missing export.
