Published: 2026-08-21
Claude Code as a Non-Code Workspace: Project Scaffold and Custom MCP Connectors
Chapters / key moments (click to jump — plays here on the page)
The framing here is marketing, but the useful content is a clean walkthrough of using Claude Code for work that contains no code at all — and the reason it's worth doing. Herk's argument is that Claude Code operates out of a directory rather than a chat thread, so context accumulates on disk instead of evaporating between sessions. The transferable pieces: a CLAUDE.md written as an index rather than a document, a four-folder project layout, an interview skill for getting what's in your head into the project, a habit for verifying what the agent can actually read, and the exact click path for adding a custom MCP connector.
Source video
"Turn Claude Into a One Person Marketing Team in 38 Mins" by Nate Herk — Watch on YouTube →
Key Takeaways
- The reason to use Claude Code for non-code work is the directory, not the coding. Because it works out of a project folder, every session adds files that the next session can read — as opposed to a web chat where context resets. "Just because it has the word code, don't think we're going to be coding."
- Start from an empty folder and let the agent create the scaffold. Make a new empty directory, open it in Claude Code via open folder, and accept trust workspace — which is what grants read, create, edit and move rights inside that folder. Then paste in a large context dump and ask for a CLAUDE.md plus any other context files it thinks are relevant.
- Write CLAUDE.md as an index, not as the content. The generated file is short and its operative line is a pointer: read these files before writing anything. The substance lives in separate context files — in this build, brand positioning, customer avatar, product facts, voice and copy, a message bank, playbooks, competitive landscape and an open-questions file. Keeping CLAUDE.md thin and delegating to files is what stops it becoming an unreadable dumping ground.
- Four folders carry the whole project:
CLAUDE.mdas the operating doc,context/for the facts,assets/for inputs you drag in (logos, source images, a brand-guidelines PDF), andoutput/for anything the agent produces. Telling the agent explicitly which output subfolder a deliverable belongs in keeps a long-running project navigable. - Treat CLAUDE.md as a living file. His instruction pattern is to interrupt with "by the way, add that to the CLAUDE.md, this is important" whenever something durable surfaces mid-session — cheaper than trying to write a complete one up front.
- Use an interview skill to extract context you can't articulate. The "grill me" skill is just a markdown file whose instruction is to relentlessly interview the user about a topic until shared understanding is reached, asking one question at a time and digging until satisfied. Drag the file into the chat, ask for it to be installed in the project, then run it. This is the same pattern the 10X content machine uses for voice capture — an interview is a better context-extraction interface than a blank prompt.
- Verify what the agent can actually see before assuming a bug. When a dragged-in subfolder rendered oddly in the file panel, he didn't guess — he asked the agent to list the files it could read in that path and confirmed all 11 were visible, establishing the problem was cosmetic. Asking the agent to enumerate what it sees is a cheap first debugging step for any file-visibility confusion.
- Adding a custom MCP connector is a fixed click path: in the tool you're connecting, find its MCP/CLI section and copy the URL it offers for Claude; in Claude go to Customize → Connectors → Add custom connector, paste the URL, give it a name, and confirm. You then complete an OAuth sign-in and grant permission. After that the agent drives the service and you stop touching its interface directly.
- Ask for cost reporting inside the prompt. He routinely ends generation requests with an instruction to report what the run cost and to file the results in a named output folder — a simple way to keep spend visible on tool-heavy, asset-generating work.
- Run several requests in parallel chats against the same project. Because the context lives in files rather than in one thread, multiple concurrent sessions all read the same brand and product context — he fires off three unrelated deliverable requests at once.
- You can point the agent at a public GitHub repo by URL as a design input, and combine it with the local assets and context to produce something noticeably less generic than an unbriefed first pass. He's explicit that the first output is a draft: assume it isn't right on the first prompt and plan to iterate.
- Remember that a local preview isn't shipped. The generated site ran on
localhost:8931, which is only reachable on that machine — publishing still means pushing to a host. Worth stating because it's a common point of confusion for non-technical users following an agent build.
Project Structure Shown
my-project/
├── CLAUDE.md # short operating doc — points at the context files
├── context/ # brand positioning, avatar, product facts, voice,
│ # message bank, playbooks, landscape, open questions
├── assets/ # inputs you drag in: logos, images, guideline PDFs
└── output/ # deliverables, in named per-campaign subfolders





