Rechargly Marketing · companion guide
Written for someone who is already good at this. Not an introduction to Claude - a guide to what genuinely changes when it has a filesystem, and where the new leverage actually is.
You are not learning a new tool. You are learning a different shape of the same tool, and almost everything you already know still applies. Three things change, and they change a lot.
In Cowork you attach the things you want considered. Here, everything in the folder is reachable and Claude decides what to open. You stop curating attachments and start curating a library. That is a better deal, but it means the quality of the folder now determines the quality of the answers.
Output does not just appear in the conversation - it lands in files, in HubSpot, in Notion. Which is why the confirm tokens exist. In Cowork, the worst case of a bad answer is a bad answer. Here, the worst case is a bad answer that got sent.
Not "it remembers our chat". It remembers because things were written into files that are read at the start of every session. That is a mechanism you can inspect, edit and correct, which makes it far more reliable than a model's recollection - and it means when it gets something wrong about you, you fix a file rather than re-explain.
This is the concept worth twenty minutes, because everything else follows from it. There are four layers, and knowing which one you are putting something into is most of the skill.
| Layer | What it is | Lasts |
|---|---|---|
The routerCLAUDE.md | Read at the start of every single session, always. The standing rules and the map of where things live | Forever, until edited |
The memory filesmemory/ | Who the brain is, who you are, decisions that stay true. Also read every session | Forever, until edited |
The librarywiki/, voice/ | Everything else. Not loaded automatically - read on demand when relevant | Forever, read when needed |
| The conversation | What you have said in this session | Until you clear it |
The mental model: the router and memory are what it always knows. The library is what it can find out. The conversation is what it is currently thinking about.
Almost every "why doesn't it know that?" moment is something sitting in layer three that nobody pointed it at, or something that was only ever said in layer four and never written down.
The conversation has a finite size. As it fills, older exchanges get summarised or lost, and quality degrades in a way that is hard to notice from the inside - it becomes slightly vaguer, slightly more likely to forget a constraint you set an hour ago.
Two moves:
/clear - wipes the conversation and starts fresh. The router and memory files reload automatically, so you lose the chat, not the brain. Use this far more often than feels natural./compact - summarises the conversation so far and continues. Use when you are mid-thread on something long and genuinely need the thread.The habit that separates people who are good at this from people who are frustrated by it: a fresh session per real task. Not per day. Writing a campaign brief and then analysing last month's numbers in the same conversation makes both worse - the second task inherits all the wrong context and none of the right attention.
Before you clear, ask: "is there anything from this session worth writing down?" Then write it down. That is the whole discipline.
The single most valuable judgement in running a system like this, and the one nobody teaches. Get it wrong in one direction and the brain knows nothing; wrong in the other and it drowns.
Decisions and the reasoning behind them. "We are not doing X because Y." Six months later the decision is remembered and the reason never is. This is the highest-value thing you will ever save.
Anything a customer said, verbatim. Their words are the raw material for everything. Never paraphrase on the way in.
Corrections. When the brain gets something wrong and you fix it, that correction belongs in a file. Otherwise it gets it wrong again next week.
What did not work, and why. Failures are more useful than successes and get recorded far less often.
Anything you can regenerate in thirty seconds. A draft that was superseded, a list you can rebuild from HubSpot on demand. Saving it costs more than remaking it.
Status that expires. "Waiting on Alex" belongs in _hot.md for three days, not in the wiki forever. A knowledge base full of stale status is worse than an empty one, because it reads as current.
The full transcript of anything. Save the finding, not the recording. A wiki nobody can search is a wiki nobody uses.
Things saved "just in case". The clearest signal something is noise is being unable to say who would look for it and when.
The test that settles it: would a future session doing real work need this to avoid making a mistake? If yes, save it. If it is only interesting, let it go. Interesting is the enemy here.
| This | Goes here |
|---|---|
| Live for the next few days | wiki/_hot.md |
| Durable knowledge about the market, brand or audience | a page in wiki/ |
| A decision that should change how the brain behaves | memory/memory.md |
| Your own thinking, in your words | voice/ - and you file that yourself |
| Not sure yet | /new, and decide on Friday |
Switch with /model. Three practical rules cover almost everything.
| Model | Use it for | Why |
|---|---|---|
| Sonnet the default | Drafting, research, most analysis, everyday work | Fast enough to stay conversational, strong enough for real work. Leave it here unless you have a reason |
| Opus | Genuinely hard thinking. Strategy, a messy judgement call, /roast, /angle on something that matters, untangling something confusing | Better reasoning, slower. The difference shows up on hard problems and is invisible on easy ones |
| Haiku | Bulk mechanical work. Reformatting, tidying a list, simple repetitive passes | Fast and cheap. Do not use it for anything requiring judgement |
The common mistake is reaching for the biggest model to fix a bad prompt. If an answer is wrong because the brain did not have the right context, a smarter model produces a more confidently wrong answer. Fix the context first, then upgrade the model if it is genuinely a thinking problem.
Claude can dispatch sub-agents that go away, do a piece of work in their own separate context, and come back with a conclusion. It is powerful and it is over-used.
Broad searching. "Find everywhere in the wiki and HubSpot where we describe pricing." Sweeping many places when you only want the conclusion.
Genuinely parallel work. Three campaign ideas researched at once, independently, then compared.
Independent opinions. The reason /roast works - voices that have not heard each other find different flaws. Five agents that read each other's output converge on the same answer, which defeats the point.
Anything you know the location of. "What does the brand page say?" is one file read. An agent is slower and adds a layer of summary between you and the truth.
Sequential work. If step two needs step one's answer, running them separately just adds handoffs.
Anything where nuance matters. An agent reports back a summary. Summaries lose exactly the specific phrasing that /listen exists to capture.
The rule of thumb: agents are for breadth. One conversation is for depth. If you want an answer you will act on directly, stay in the conversation. If you want a sweep of somewhere you have not looked, send an agent.
Underrated, and probably the fastest way to get information into the brain.
Take a screenshot, then paste it into the Claude Code prompt with Ctrl+V. It reads it properly - a dashboard, a competitor's landing page, an analytics chart, a design someone sent, a screenshot of a Slack thread from a channel it cannot reach.
This is the workaround for every source it has no connection to. If you can see it, it can see it.
/roast to compare it to yours. Blunt, fast, useful.Files work the same way. Drop a PDF, spreadsheet or document into the project folder and refer to it by name. For a one-off, drop it into wiki/raw/, use it, then let /process-inbox decide on Friday whether it earns a permanent place.
The morning file is wiki/_hot.md, and it is the highest-leverage file in the whole system because it is read at the start of every session.
Three rules keep it working:
morning → /today reads _hot.md, calendar, Slack, HubSpot
proposes three things. You confirm or replace.
during → /new capture anything, no filing decisions
evening → /daily-review two questions, rewrites _hot.md for tomorrow
Friday → /process-inbox the week's captures get filed or binned
/pulse what actually happened
The whole thing is about ten minutes a day. Its value is entirely in being boring and unbroken - a rhythm run four days a week produces a brain that knows four-fifths of what happened, which is worse than it sounds because you cannot tell which fifth is missing.
Everything in wiki/ is plain Markdown with [[double bracket]] links between pages. Point Obsidian at the wiki folder and you get search, backlinks and a graph view over exactly the same files Claude reads and writes.
Nothing is duplicated. It is one folder seen two ways, and both stay in sync because they are literally the same files.
Browse, wander, see what links to what, notice a page nobody has touched in months, read on your own without a conversation running.
Ask, produce, connect to live systems, write. Anything where you want an answer rather than a look around.
The links matter more than they look. A page with no inbound link is invisible in practice - nobody will find it again. When a page is written, something should point at it.
Most of them will still work. Some will not need to.
A prompt you paste repeatedly becomes a file at .claude/commands/name.md, and it becomes /name. Same text, plus a one-line description at the top. That is genuinely the whole conversion.
Most well-built Cowork prompts contain a chunk of preamble establishing context - who you are, what the company does, what tone to use. Delete all of that. It is already in the router and the memory files, loaded every session. What is left is usually the actual instruction, and it is usually much shorter and better.
Anything that was a workaround for the model forgetting things between sessions. That problem does not exist here, and carrying the workaround forward just adds noise to every run.
Suggested approach: do not port anything in week one. Work normally, and when you catch yourself typing something similar for the second time, that is the one to turn into a command. You will end up with four or five that get used constantly instead of twenty that do not.
Drop anything you want to keep into wiki/raw/ in the meantime, and decide later.
/clear is free.It sounds equally confident when it is wrong. There is no tone shift, no hedge, no tell. The only defences are that it cites sources and flags its own inferences with [my read, worth checking], and that you check anything expensive before it ships. A claim carrying neither a source nor a flag is a bug - say so, and it will fix the habit.
Placeholder facts survive. An invented example statistic, put in to show the shape of a paragraph, has an alarming tendency to end up in published copy. This brain is instructed to leave a visible gap like [NEED: real figure, source unknown] instead. If you see a specific-sounding number you did not supply, treat it as fabricated until you have checked it.