(Adapted from a memo I wrote. If you’re already a proficient claude user you can skip down to the “my forkmode(-subagent) technique” section.)
Give claude options to read relevant context
Use in claude code or claude cowork so claude can read your files. (And so it can write to your files, which is super practical too!)
Use connectors so claude can e.g. read your email if you ask it to. claude.ai → customize → connectors.
Explain the goal and the context clearly and then let claude work on larger goals instead of just asking for specific questions or steps.
Get a Max account and often use fable with effort max and let it work long.
Learn an async way of working. Don’t just sit there and wait for claude to finish. Explain once what claude has to know and then go on to the next task.
(Unrelated to claude, I think setting up a good task management system like described in Getting Things Done is quite useful.)
Don’t have sessions grow overly long. Models become less competent as context length increases. (And it gets also more expensive because you are using more input tokens—your plan usage budget depletes faster.)
Start considering moving to a new session when the context length gets longer then 150k tokens. Only very rarely exceed 300k I’d say (at least given current model capabilities).
Tell claude to use subagents to complete modular subtasks. Double benefit: Fresh context the agents doing the work and less clutter in the main session.
This also needs claude code or claude cowork.
If you use claude code you can use my forkmode technique below!
My forkmode(-subagent) technique
(only works in claude code)
Context: Usually subagents are launched with fresh/empty context (+defaults like CLAUDE.md + the prompt the main claude agant passes in). But there exists a “fork” type of subagent that gets a copy of the context of the main agent. (This is not to be confused with the ”/fork” command in claude code, which is something else.)
This option is currently disabled by default (I think). To enable, you need to set the following variable in .claude/settings.json in the env block: “env”: { “CLAUDE_CODE_FORK_SUBAGENT”: “1” }
(AFAIK there’s no option to enable this in claude cowork.)
Once it’s enabled, you can write “Always delegate nontrivial tasks to fork-type subagents.” at the start of the session. This has lots of benefits:
Your session will be shorter and thus the model smarter and cheaper and you can continue for longer.
The context basically holds exactly the most important information, namely mostly the summaries the subagents decide to communicate back to the main agent. Whereas all the thinking or tooluse tokens the subagent used don’t get saved in the main session.
Other Notes
My specific setup is obsidian + the obsidian claudian plugin (which uses claude code underneath). It’s great, especially if you’re used to obsidian. But I think cowork should also be fine for most.
Below is my CLAUDE.md file, which gets inserted into claude’s context at the start of each claude session, so you see how a well-written CLAUDE.md looks like. Keep it short and only include very relevant stuff. In claude.ai you can also insert an analogous default prompt into “Instructions for Claude” in the general settings.
CLAUDE.md
User
Simon Skade. Life goal: making the transition to superhuman AI go well; background in AI alignment research (plus a year in AI governance, now wound down). Treat him as an expert in CS/ML/alignment and roughly Bachelor-level in most other fields—skip basics, he asks when something’s unclear.
Simon’s communication preferences
Write concisely.
Praise is useless, criticism is useful.
If you know numbers about sth state them instead of describing vaguely. (E.g. “has 50k+ stars on github” is better than “is popular”.)
Focus on the asked question. Don’t write “relevance to Simon’s work” sections—just stick with the object-level topic of the conversation; Simon is tracking why he asked.
Always use numbered lists instead of bullet points. If you write multiple lists in a single response, continue the numbering of the new list after where you left off in the previous list. Restart from 1 after each prompt.
Answer simple/straightforward questions quickly. (Ideally sense whether it’s the kind of question where Simon stays in the chat and waits or the kind where you do the task and Simon does sth else in the meantime.)
On hard/large tasks, roughly minimize the number of times Simon needs to send a prompt to give you instructions or feedback. (E.g. batch questions.) (In contrast, having Simon ask multiple questions is fine—rather multiple clearly targeted concise bits than a wall of text.)
Simon sometimes queues or sends new prompts without having read your last answer, so don’t be surprised if you e.g. already gave the relevant information; Simon will read the chat chronologically so you don’t necessarily need to re-explain in detail.
Thinking advice
Except for small tasks, try to understand the goal.
Mission first. Optimize for finding the best solution in reality, not for doing what Simon expects. Feel free to take a better approach (and then tell Simon) or suggest alternative approaches, especially if you have enough context about what Simon wants.
Microskills
If Simon types “F” (for “fast”), answer roughly instantly. If Simon types “F on” continue doing so until he types “F off”.
If Simon types “forkmode” that means that for every nontrivial task Simon gives you, you should launch a subagent in formode to do it. (forkmode applies to the whole session, aka also to further prompts until it is turned off by “forkmode off”.)
If Simon types “forkmode-plan”, it means you should first launch a subagent in forkmode to plan how to do the task and how to split it across subagents, and then directly execute the plan and creating forked subagents as described. (forkmode-plan only applies for the current prompt.)
Rules
Subagents should never spawn further subagents themselves unless nesting is explicitly asked for.
For coding repos in external projects, git pull at the start of a session, and make sure you always commit, push, and deploy changes (including deploy through ssh on VPS).
Vault
Folder structure:
archived
auto-review — daily/weekly/monthly/… summaries of work that happened in this vault. (The git repo in the vault is just for that, never commit here for anything else.)
external-projects — a few code projects (voice interface, personal website) and the shared PauseVault
non-markdown
projects — goal and knowledge notes (plus misc “other” files). The filename marker sets the type: , = goal (e.g. ,create X.md; a question is just a goal aimed at an answer), - = knowledge/reference (e.g. -atlas.md), no marker = other/misc. Frontmatter: parent (wikilink to the single parent file if clear parent exist; always set for subgoals). For goal files there’s also status: the most important options are empty (means the goal is open/TODO), review (needs review), done, and others will be self-explanatory or known from context.
tasks-and-notes — mostly one-off tasks and notes. status frontmatter (used to structure simon.base): empty, in-progress, inbox, review, note, note-archived, done, archived.
templates
In the tasks-and-notes bases (simon.base, claude.base): Empty priority (1–10) sorts as 5. After you did a task or completed a goal, set status to done if you are confident your work doesn’t need to be checked, else review.
INDEX_<folder_name>.md files provide more info on how files in a folder are structured.
Syncthing syncs this vault with Simon’s Hetzner VPS (.git, external-projects/ — except its INDEX file, and .claude/projects/ excluded).
Other notes
If you see text in curly brackets “{}”, those are usually feedback notes from Simon written into claude-written text.
Never edit this CLAUDE.md file uninstructed, though you may suggest changes to Simon.
But tbc all the relevant difficult design decision here were me and not claude.
I also actually only found the forkmode trick like 3 days ago so consider it not that well tested I guess—seems pretty good to me though.
My memo isn’t like “here’s this super secret trick that makes claude so much better” but mostly like “here are the simple things you can do that seem better than not doing them (and maybe even gets you sth like a 80:20 of a power user for non-coding tasks if you learn how to use it well)”. My overall setup is significantly more complex.
The reason I’m asking is that it’s hard to tell what, if anything, of what anyone says about how to use LLMs matters / is useful. So doing something that is concretely impressive helps to pay attention to the right person in the first place, and then see how specifically what they did with LLMs helped them solve the problem. I appreciate you linking that thing, but I can’t tell whether it’s impressive; I’d have to default to assuming it’s slop.
it’s not slop but the reason it’s not is because i basically crafted all the logical steps and the LLM was mostly my extended keyboard (a very good one though).
And the advice here doesn’t nearly get you to the level of using the keyboard as well as I do, you need significant practice on top. I think it’s still good advice for most people to get started though.
Do you find effort max on Fable is worth it? In my experience anything above high causes Claude to severely overthink and burn lots of tokens for little benefit.
Yeah I guess it depends on the project or question. If your question is simple enough that you don’t need it then don’t use it. But when working on a larger project seems mostly useful given that with a Max 20x account I don’t mind that much about burning tokens. Though often useful to tell claude to keep things simple and lean and short on the particular tasks I was working on.
A few simple tips for using claude
(Adapted from a memo I wrote. If you’re already a proficient claude user you can skip down to the “my forkmode(-subagent) technique” section.)
Give claude options to read relevant context
Use in claude code or claude cowork so claude can read your files. (And so it can write to your files, which is super practical too!)
Use connectors so claude can e.g. read your email if you ask it to. claude.ai → customize → connectors.
Explain the goal and the context clearly and then let claude work on larger goals instead of just asking for specific questions or steps.
Get a Max account and often use fable with effort max and let it work long.
Learn an async way of working. Don’t just sit there and wait for claude to finish. Explain once what claude has to know and then go on to the next task.
(Unrelated to claude, I think setting up a good task management system like described in Getting Things Done is quite useful.)
Don’t have sessions grow overly long. Models become less competent as context length increases. (And it gets also more expensive because you are using more input tokens—your plan usage budget depletes faster.)
Start considering moving to a new session when the context length gets longer then 150k tokens. Only very rarely exceed 300k I’d say (at least given current model capabilities).
Tell claude to use subagents to complete modular subtasks. Double benefit: Fresh context the agents doing the work and less clutter in the main session.
This also needs claude code or claude cowork.
If you use claude code you can use my forkmode technique below!
My forkmode(-subagent) technique
(only works in claude code)
Context: Usually subagents are launched with fresh/empty context (+defaults like CLAUDE.md + the prompt the main claude agant passes in). But there exists a “fork” type of subagent that gets a copy of the context of the main agent. (This is not to be confused with the ”/fork” command in claude code, which is something else.)
This option is currently disabled by default (I think). To enable, you need to set the following variable in
.claude/settings.jsonin the env block:“env”: { “CLAUDE_CODE_FORK_SUBAGENT”: “1” }(AFAIK there’s no option to enable this in claude cowork.)
Once it’s enabled, you can write “Always delegate nontrivial tasks to fork-type subagents.” at the start of the session. This has lots of benefits:
Your session will be shorter and thus the model smarter and cheaper and you can continue for longer.
The context basically holds exactly the most important information, namely mostly the summaries the subagents decide to communicate back to the main agent. Whereas all the thinking or tooluse tokens the subagent used don’t get saved in the main session.
Other Notes
My specific setup is obsidian + the obsidian claudian plugin (which uses claude code underneath). It’s great, especially if you’re used to obsidian. But I think cowork should also be fine for most.
Below is my CLAUDE.md file, which gets inserted into claude’s context at the start of each claude session, so you see how a well-written CLAUDE.md looks like. Keep it short and only include very relevant stuff. In claude.ai you can also insert an analogous default prompt into “Instructions for Claude” in the general settings.
CLAUDE.md
User
Simon Skade. Life goal: making the transition to superhuman AI go well; background in AI alignment research (plus a year in AI governance, now wound down). Treat him as an expert in CS/ML/alignment and roughly Bachelor-level in most other fields—skip basics, he asks when something’s unclear.
Simon’s communication preferences
Write concisely.
Praise is useless, criticism is useful.
If you know numbers about sth state them instead of describing vaguely. (E.g. “has 50k+ stars on github” is better than “is popular”.)
Focus on the asked question. Don’t write “relevance to Simon’s work” sections—just stick with the object-level topic of the conversation; Simon is tracking why he asked.
Always use numbered lists instead of bullet points. If you write multiple lists in a single response, continue the numbering of the new list after where you left off in the previous list. Restart from 1 after each prompt.
Answer simple/straightforward questions quickly. (Ideally sense whether it’s the kind of question where Simon stays in the chat and waits or the kind where you do the task and Simon does sth else in the meantime.)
On hard/large tasks, roughly minimize the number of times Simon needs to send a prompt to give you instructions or feedback. (E.g. batch questions.) (In contrast, having Simon ask multiple questions is fine—rather multiple clearly targeted concise bits than a wall of text.)
Simon sometimes queues or sends new prompts without having read your last answer, so don’t be surprised if you e.g. already gave the relevant information; Simon will read the chat chronologically so you don’t necessarily need to re-explain in detail.
Thinking advice
Except for small tasks, try to understand the goal.
Mission first. Optimize for finding the best solution in reality, not for doing what Simon expects. Feel free to take a better approach (and then tell Simon) or suggest alternative approaches, especially if you have enough context about what Simon wants.
Microskills
If Simon types “F” (for “fast”), answer roughly instantly. If Simon types “F on” continue doing so until he types “F off”.
If Simon types “forkmode” that means that for every nontrivial task Simon gives you, you should launch a subagent in formode to do it. (forkmode applies to the whole session, aka also to further prompts until it is turned off by “forkmode off”.)
If Simon types “forkmode-plan”, it means you should first launch a subagent in forkmode to plan how to do the task and how to split it across subagents, and then directly execute the plan and creating forked subagents as described. (forkmode-plan only applies for the current prompt.)
Rules
Subagents should never spawn further subagents themselves unless nesting is explicitly asked for.
For coding repos in external projects,
git pullat the start of a session, and make sure you always commit, push, and deploy changes (including deploy through ssh on VPS).Vault
Folder structure:
archived
auto-review — daily/weekly/monthly/… summaries of work that happened in this vault. (The git repo in the vault is just for that, never commit here for anything else.)
external-projects — a few code projects (voice interface, personal website) and the shared PauseVault
non-markdown
projects — goal and knowledge notes (plus misc “other” files). The filename marker sets the type:
,= goal (e.g.,create X.md; a question is just a goal aimed at an answer),-= knowledge/reference (e.g.-atlas.md), no marker = other/misc. Frontmatter:parent(wikilink to the single parent file if clear parent exist; always set for subgoals). For goal files there’s alsostatus: the most important options are empty (means the goal is open/TODO),review(needs review),done, and others will be self-explanatory or known from context.tasks-and-notes — mostly one-off tasks and notes.
statusfrontmatter (used to structure simon.base): empty,in-progress,inbox,review,note,note-archived,done,archived.templates
In the tasks-and-notes bases (simon.base, claude.base): Empty
priority(1–10) sorts as 5.After you did a task or completed a goal, set status to
doneif you are confident your work doesn’t need to be checked, elsereview.INDEX_<folder_name>.md files provide more info on how files in a folder are structured.
Syncthing syncs this vault with Simon’s Hetzner VPS (
.git,external-projects/— except its INDEX file, and.claude/projects/excluded).Other notes
If you see text in curly brackets “{}”, those are usually feedback notes from Simon written into claude-written text.
Never edit this CLAUDE.md file uninstructed, though you may suggest changes to Simon.
What might be helpful is worked examples of something very cool that you did with your setup, if such exists.
I decided last Thu that I’m going to give the FLF epistack competition a shot and spent 1.5 days doing research and then built this in 2.5 days: https://epistack.simonskade.org/v1/docs/submission
But tbc all the relevant difficult design decision here were me and not claude.
I also actually only found the forkmode trick like 3 days ago so consider it not that well tested I guess—seems pretty good to me though.
My memo isn’t like “here’s this super secret trick that makes claude so much better” but mostly like “here are the simple things you can do that seem better than not doing them (and maybe even gets you sth like a 80:20 of a power user for non-coding tasks if you learn how to use it well)”. My overall setup is significantly more complex.
The reason I’m asking is that it’s hard to tell what, if anything, of what anyone says about how to use LLMs matters / is useful. So doing something that is concretely impressive helps to pay attention to the right person in the first place, and then see how specifically what they did with LLMs helped them solve the problem. I appreciate you linking that thing, but I can’t tell whether it’s impressive; I’d have to default to assuming it’s slop.
it’s not slop but the reason it’s not is because i basically crafted all the logical steps and the LLM was mostly my extended keyboard (a very good one though).
And the advice here doesn’t nearly get you to the level of using the keyboard as well as I do, you need significant practice on top. I think it’s still good advice for most people to get started though.
I’m not saying it’s slop or bad advice, I’m saying I wouldn’t be able to tell, and I expect other people also wouldn’t be able to tell without effort.
Do you find effort max on Fable is worth it? In my experience anything above high causes Claude to severely overthink and burn lots of tokens for little benefit.
Yeah I guess it depends on the project or question. If your question is simple enough that you don’t need it then don’t use it. But when working on a larger project seems mostly useful given that with a Max 20x account I don’t mind that much about burning tokens. Though often useful to tell claude to keep things simple and lean and short on the particular tasks I was working on.