Join Table for One | Other Articles

I have wasted weeks of my time, my engineer’s time, and my startup’s money building the wrong thing.

Not because I was building in an echo chamber. Not because I wasn’t conducting enough customer interviews. Because I wasn’t using the information I already had properly.

Let me explain.

The case for user interviews is that it keeps you close to the problem of the people who are actually going to pay you.

And the standard advice on how it should go is as follows:

1. Define your hypotheses and your open questions

2. Find your ideal target customers

3. Build rapport, focus on behavior, find more information about their problems and do not disclose the product

4. Synthesize your findings

5. Identify the features required for your MVP

Now for whatever reason, there are hundreds of thousands on videos and articles on conducting the interview. From how to find the people to what to ask. But you can hardly find anything on the synthesis of the information you get during the interview.

And I see most founders, including me, get this wrong. We think we are not biased. We try not to think about the solution or the features we cooked up in our heads. But we are wrong.

Our biases do creep in!

After reading forty minutes of transcripts and seeing the comments that sound like agreement, we choose to let them stay with us. We miss the thing she said she does. We miss the confused questions she asked. We even miss the hesitation she had to pay for a solution. And We draw a conclusion from what we want to notice.

Getting Users To Talk Is The Easy Part

Understanding what exactly they need is more difficult.

No matter what you do, you cannot achieve this result via a form. On a form people fill in what you put in front of them, so you can write the most open ended question in the world and still only hear back about the thing you already thought to wonder about. Your blind spots stay exactly where they were.

The ability to synthesize the right information from your user interviews is a serious skill. If you can do that, you can see which hypothesis actually moved and which open questions are still sitting there.

It could be the difference between building something people use and something they seem excited about but don’t actually want.

Capture What You Heard

So how do you “synthesize information” from the interview? What do you even look for? What do you need to update?

Well I am sharing what I know, what I have done, and what has worked for me. I am not claiming to be an expert in this. So do not come after me!

Okay… You have 40 minutes of transcripts. Now what?

If you go through it looking for the bits that agree with you, you WILL find them. And users are not trying to mislead you. They are just polite or helpful or genuinely clever. So the information they give you is something you want to hear.

Usually I try to avoid these typical signs:

• The polite comments like “I would definitely use that”, “I could see myself paying for it” or something similar that promises a payment in the future. Unless they already pay for something of a solution in time or money, the promise doesn’t mean anything.

• The helpful comments that suggest a feature like “Oh you should build a dashboard” or “Can we click a picture of the fridge.” Some of them are genuinely helpful but some of them could be enthusiasts. You need to be able to differentiate.

• The expert comments without context like “oh yes this is a problem” or “someone should solve it.” These people could have seen the issue and their thoughts could help you. But if this person is not the end user, then their support might not mean as much.

The entire job of synthesizing the transcripts is basically to understand:

• Which hypotheses are getting stronger

• Which open questions are getting answered

• What evidence am I collecting

• And what evidence do I still need to get

But a few interviews in when you are frustrated and can’t think straight, things can get a bit muddled up.

But lucky for us, we can train AI to do this job! We can make it an unbiased synthesizer of information. So the thing I am going to show you today is how to train Claude or ChatGPT to do the unbiased pattern recognition for you.

Build It Yourself

Everything below is a step by step method that you can use in either Claude or ChatGPT. I personally prefer Claude over ChatGPT. But you do you!

You do not need to know how to code. You just have to paste the instructions in the box into your chat/code terminal.

Step 1: Building The Brain

Before you build any skill, you need a company brain.

Don’t worry I am not asking you to build anything convoluted. Just a simple structure to store your information and to give the skill a place to drop the documents it creates.

This image is the exact snapshot of how I had structured my startup brain. You don’t have to create all the files. All you need to create are the folders.

A few rules to follow when you create a brain:

1. Store everything as an MD file. MD files are plain text files your AI can open, read and rewrite without a conversion step in between. The file size is small and it saves you a lot of tokens as compared to a pdf.

2. Fix the filenames. It is a boring rule but a bit of structure right now goes a long way when you have tons of information to deal with.

3. Number the files you save. Number your interview transcripts like “interview-01-sam.md” or “interview-01.md.” A level of organization will genuinely help you a lot later on.

You can also paste this instruction in Claude Code/codex or claude cowork to create it for you:

Step 2: Creating The Skill

Now moving onto the skill itself. This is the one that reads the transcript and tells you what moved.

So paste this in:

I always add an interview step in the skills I make. It might feel like boring admin work but if you do not have a brain folder or a way to give specific context, getting your AI to interview you is always a good idea.

Step 3: The Rules

These are important for this skill. It will keep it honest and reliable even when you want to process more information.

Feel free to add your own rules in the script too:

Step 4: The Difference Between Good And Bad

Most people that make skills don’t really focus on the output. They create the skill and then try to fix it once something breaks. That is one way to do it. Another way that I like is to already define what a good vs bad output is.

So this way you skip the initial back and forth.

You can even ask the AI to write its own examples for good and bad so that you can grade them.

Step 5: The First Run

The best thing to have before the first run is a list of hypotheses and a list of assumptions. It is important for the skill to know what it is that you what to understand.

Once everything is set up, drop your transcripts in the interviews folder and run the skill.

This article is a part of an AI Workforce that I am building for early-stage founders. Every Tuesday, I will share a functional task that makes your job easier. Below this is a ready to use task file. This file gives you three things: the interview synthesizer, the validation dashboard (so you don’t have to read MD files), and the persona builder (so you know what kind of people you are catering to). It is available to all the paid subscribers and it is the first (of 55) tasks from the AI Workforce Map.

Ready To Use

Above this was the instruction to build one skill. But we are not building skills.

A task, the way I have structured it, is the whole job rather than one step of it. The task, Capture What You Heard, sits inside Validate The Idea and has three skills in total.

1. The Interview Synthesizer. The one I wrote about above. This skill sharpens your hypotheses, answers what it can, collects evidence for you and files all of these things for you to see.

2. The Validation Dashboard. This dashboard is a way to see your validation journey. The output generated by every skill in Validate The Idea can be seen here.

3. The Persona Builder. It groups the people you talked to based on their behavior and their triggers so that you can start to see past demographics.

This is one of the 55 tasks that I am building. The next one is Study Your Competition. It is also a package of three but it has one agent and two skills.

If you build it and something breaks, reach out. And if there are some tasks that you want me to build for instead, tell me!

In my opinion, it should be a matter of hours!

Over the last 2 years, I have worked on 8 ideas. 5 were pivots and versions of my old startup, and 3 came after I closed the business, all three in just the last 2 months.

Across all 8, I have been trying to perfect one thing: how fast I can go from an idea to actually talking to potential users.

The first one took 3 months to go from an idea in my head to an actual conversation with a user, because I wanted to walk in with something finished. I never once stopped to ask whether they wanted my solution, or whether they even had the problem I assumed they had.

The one I am building right now already has 17 people testing it from day 1. Every one of them is giving me feedback, on the name, the design language, the features, and a few have already started referring their friends and family.

And that, in my opinion, is the right way to build.

So how do I pull that off? It is not magic. It just takes a little strategy and a little courage.

Today, I want to share my strategy.

The Prompts

Everything in this process runs in a Claude or ChatGPT chat on any model.

The only part that takes some time and a little courage is getting real people to answer a survey. Real people who are ideally strangers.

Because responses trickle in over days the priority from day one is getting the survey out as fast as possible.

But before you start with the first prompt, write your hypothesis down on paper. I want you to write what you think the problem is, what you think people are doing about it today, and what you think the potential solutions could be.

Do it before you do anything else. Because everything that follows is created to prove or disprove your opinions.

Once you have that, copy these into your AI chat in order.

Prompt 1: Refining Your Thoughts

You are my validation partner for the next five days. We're going to stay in this one chat the whole time, so keep everything we produce here in mind as we go.

I have an early startup idea and I need to pressure-test it before I build anything.

Here's my raw idea:
[DESCRIBE YOUR IDEA IN 3–5 SENTENCES: the problem you think exists, who has it, and what you're thinking of building]

And here's what I already wrote down by hand, before any data:
[YOUR OWN FIRST DRAFT: what you think the problem is, what you think people do about it today, what you think the solution could be. Paste it rough. If you skipped this, go write it now.]

Your job: interview me to turn this into a clear one-page validation brief.

Rules:
- Ask me ONE question at a time. Wait for my answer before the next one. Don't dump a list.
- Keep going until you can fill every section below. Push on anything vague: if I say "small businesses," ask which ones.
- Don't be a cheerleader. If something sounds like a guess, call it a guess.
- Where my handwritten draft and my answers disagree, point it out.

Interview me until you can confidently fill in:
- The core problem (one sentence, in the user's words, not mine)
- Who exactly has it (specific: role, situation, not "everyone")
- How painful it is today and what they do instead (workaround / competitor / "nothing")
- My core hypothesis (the belief that, if wrong, kills the idea)
- My proposed solution (one sentence)

When you have enough, stop asking and output a document titled VALIDATION BRIEF with:
- Problem statement
- Target user (specific)
- Current alternatives
- My hypotheses (rewrite mine clearly)
- 3–5 additional hypotheses I haven't named but that this idea secretly depends on, the hidden assumptions that could sink it
- Riskiest assumption (the single thing most likely to be false, we test this first)
- Where this user already hangs out online (specific subreddits, communities, Slacks, forums, hashtags), I'll use this to find people
- Kill / Pivot / Continue criteria: what survey + research result would make you tell me to kill this, pivot it, or keep going? Give me concrete thresholds now, before I see any data.

Call it the VALIDATION BRIEF and refer back to it by that name for the rest of this chat. Do not quietly revise it later; if something we learn contradicts it, say so out loud.

Start by asking me your first question.

Prompt 2: Fast Landscape Scan

Using the VALIDATION BRIEF above, do a fast landscape scan with web search. 15 minutes of work, not a deep report. The deep one comes later.

I only need three things, in plain language, no jargon:
1. Is this problem already perfectly solved? List the top 3–5 things people use today (products, tools, hacks, spreadsheets) and one line on where each falls short.
2. Are there signs people actually want it fixed, complaints, workarounds, high-engagement threads? Give me 2–3 real examples with links.
3. Based on what you found, what 2–3 things should my survey probe that I might not think to ask?

Keep it under one screen. Bullets. End with Green / Yellow / Red light to keep going, and one sentence why.

If anything here contradicts the brief, say so plainly instead of smoothing it over.

Prompt 3: Build The Survey

Now build me a short validation survey I can drop straight into Tally or Google Forms. Use the VALIDATION BRIEF and the landscape scan above, especially the riskiest assumption and anything the scan told us to probe.

Non-negotiable rules:
- 5 questions. Aim for exactly five; 7 is the absolute ceiling and you need a reason to go past five. Every extra question costs responses.
- Default shape: 4 multiple-choice or scale questions, and at most ONE open-ended question that lets the person talk in their own words.
- Test my riskiest assumptions first, not my solution.
- Ask what people do and pay today, not what they would do. ("How do you handle X today?" not "Would you use a tool that…?")
- Neutral wording. Don't lead the witness, don't suggest the answer inside the question, don't sell my idea anywhere in the survey.
- Ask for name and email at the end, after every real question.

Give me, ready to paste:
1. Survey title (plain, not salesy)
2. Short description (2 sentences, what it's about + how long it takes, e.g. "Takes 90 seconds")
3. The 5 questions, each with type (multiple choice / scale / open text) and answer options
4. The final optional email question, worded well
5. One line under each question naming which hypothesis it tests, and what a good vs bad answer looks like, so I can read the first few responses live and know whether a question is pulling its weight

I would say ask for a name and an email last, after every real question. In my surveys this single change cut drop-off by 15 to 20 percent. Because identity requests up front make a form feel like a lead capture instead of a two-minute favor.

Another thing to remember is that you want to ask people what they do and pay for today, not what they would do if your solution existed. Because behavior is a far better predictor than what someone says they would do.

My own sweet spot is five questions with three multiple-choice and two open-ended, descriptive questions. And I always build my surveys in Tally with the Pro version. It is so worth the money. It shows partial submissions, so you still get signal from someone who drops off halfway. And I also get to observe how the first few people answer, so I can cut, rewrite, or drop a question mid-survey.

Prompt 3b: Optional Mid-survey Feedback

Here are the first responses that came in:
[PASTE THE FIRST 3–5 RESPONSES, partial ones included]

Against the hypotheses each question was meant to test: which questions are actually pulling their weight, and which are giving me mush? For anything weak, tell me whether to cut it or rewrite it, and give me the rewrite. Keep the count at five.

If people are dropping at a particular question, say which one and why you think so.

Subscribe now

Prompt 4: The Deep Research

While I collect survey responses, do the deep market research. Use full research mode and web search, dig properly. But the report must be written for someone who knows nothing about this industry.

Work from the VALIDATION BRIEF above, and test every hypothesis in it, mine and the ones you added. Don't re-litigate the landscape scan, go deeper than it.

Research rules:
- Do the heavy research, then translate it. Zero jargon. If you must use a term, define it in five words.
- Assume I know nothing about this market. Explain like you're telling a smart friend at a coffee shop.
- Every section starts with ⚡ TL;DR, do this: 1–3 concrete action items, not a summary.
- For each hypothesis: what the evidence suggests + confidence (High / Medium / Low) + one line why.

Structure the report exactly like this:
1. Is the problem real? (evidence people actually struggle with this)
2. Who has it, and how many (rough size in plain numbers, "roughly X million people / Y thousand businesses," not TAM/SAM jargon)
3. What they use today (the real competition, including "a spreadsheet" and "they just live with it")
4. Why now (what changed, why it hasn't been solved)
5. Reasons this could flop (be honest, the red flags)
6. Hypothesis scorecard (table: hypothesis → evidence → confidence)

End with a VALIDATION CHECKLIST + SCORE:
- 8–10 yes/no checks (e.g. "Is the problem frequent?", "Do people already pay to solve it?", "Is there a wedge competitors miss?")
- A score out of 10
- A one-line verdict: Strong signal / Mixed / Weak, and what would have to be true to move up a tier.

This score is a prediction, not the verdict. We'll compare it to what real people say at the end of the week.

Prompt 5: The Final Analysis

Survey responses are in. Give me the final validation call, using the VALIDATION BRIEF, the landscape scan, and the deep research report from earlier in this chat.

Raw survey responses (CSV):
[PASTE CSV, include partial submissions if your form captures them, and mark them as partial]

Do this:
1. For each question, tell me what the responses actually say, in plain language. Flag anything surprising. Note how many people left an email at the end and treat that percentage as a demand signal.
2. Go back to the Kill / Pivot / Continue criteria you set in the brief, before either of us had seen any data. Did the data hit them? Quote the thresholds back to me and be strict. Don't let me talk myself into it, and don't move the bar because the result is close.
3. Score each hypothesis: Supported / Mixed / Not supported (survey + research combined).
4. Cross-check: where do the survey and the research agree, and where do they contradict? Contradictions are where the real insight is. Also compare the research score you predicted earlier against what real people actually said, and tell me what the gap means.
5. Final VALIDATION SCORE out of 10 and one verdict:
   - BUILD: validated enough to make an MVP
   - PROBE: promising but one key thing is unproven; name the single next test
   - PARK: the evidence isn't there; tell me why, kindly but clearly

If BUILD or PROBE: the one riskiest thing still standing, and the fastest way to test it in the next five days.

This is also where you should think of a kill criteria because the best way to test multiple ideas is to think of it as an experiment. You hold the problem tightly and the solution loosely, and you stay open to whatever the feedback says, because an experiment can be proven or disproven, and neither outcome reflects on you. It just tells you whether this particular problem or this particular solution is the right one.

Why It’s Built This Way

I have used this exact structure eight times now, and each time, the fear of showing someone my unfinished idea got a little smaller.

I am still afraid of the judgment. But following a system means that by day five, I am not guessing anymore, and that is worth more than showing up with something polished.

I perfected this because it took me far too long to go from having an idea to actually talking to the people it was for.

If you run it on your own idea this week, reply and tell me which word you landed on. I want to know what got built, what got probed, and what finally got parked.

Durva

Then I burned out and stopped everything for a month.

The distribution problem for solo founders is not that we do not know social media presence matters. We know it does. The problem is that there is no reliable way to figure out which channel is worth the specific hours, given our voice and audience and what we want to accomplish.

So we pick based on what other founders are doing, or what we last read about, or where we feel most comfortable posting. To find out whether it was the right call only after six months.

So, naturally I built something to help with this. Channel Scout is a six-skill pipeline that does what a “distribution consultant” or “GTM consultant” (if they exist) does, running locally on your Claude Pro or Max subscription with no API keys and no extra cost.

Here are the only two commands:

/channel-scout is the full strategy session. This is what you run the first time. It interviews you, scans your competitors, selects a channel, designs kill criteria, tests post drafts. So that by the end, you have two channels to bet on and a metric that tells you when something is not working out.

/channel-scout coach is the daily run. One coaching note, one dashboard refresh, one check of your kill criteria. Runs automatically if you want, or can be triggered manually.

Before You Start

This is built for Claude Code, so you need a Pro or Max plan. If you have never used Claude Code before, the install takes about five minutes and there are tutorial links in the README.

Subscribe now

How It Works

The first time you run /channel-scout, five skills fire in sequence. The full session runs under 90 minutes, with natural stopping points if you need to break. If you stop mid-way, running /channel-scout again picks up exactly where you left off.

These are the five skills:

ONBOARD interviews you, asking what you are building, who it is for, your three closest competitors, how many hours per week you can give to distribution, and what channels you have already tried. While you answer, it fetches your information and homepage in the background to create specific search parameters, ICP descriptors, and competitor feed. By the end of the interview, Channel Scout knows your constraints.

SCAN uses those parameters to fetch competitor information and find three to five channels that would work for you. For each channel it identifies, it extracts the winning content template: the hook pattern that gets traction on that platform, the typical post length, the posting cadence that works. It rates each channel on audience saturation, content gap, and ICP fit.

PREDICT is the part I found hardest to build manually. It scores voice fit for each channel, meaning how much rewriting your natural writing style would need to work on that platform. Then it runs something I called a wind tunnel: three synthetic personas built from real top-performing post language on each channel. Your angle goes through all three.

Channels that would require more weekly hours than you said you have get penalized. At the end, PREDICT picks two channels and writes the full reasoning to a prediction file you can read, question, and push back on.

PROBE drafts two native test posts per channel in your voice, sets your posting cadence from the intel data, and writes kill criteria. Not “give it three months and see.” Specific numbers. If LinkedIn impressions stay below 180 after seven posts, stop. You agree to that number before the first post goes out.

COACH runs every morning, reading a rolling context stack: not your full history, just your scorecard, yesterday’s summary, and the most recent weekly synthesis. It checks your kill criteria, writes one coaching note, and regenerates your dashboard, opening it automatically.

The Number That Matters

The problem was not that I picked the wrong channels. I picked five channels at once, had no criteria for any of them, and burned out before a single one could tell me anything useful. Had I run some experiment like Channel Scout first, it would have surfaced two channels worth betting on and given me a number to watch after the first post went out. It would have told me that given my ICP, my strongest channels were Substack and Reddit.

That is the piece I would have wanted before I opened a TikTok account in 2025.

Now this is not a content system and I am building an individual system for each channel. But those will work only after you have identified the right channels for you.

How To Install It

Two commands in Claude Code:

/plugin marketplace add DM1195/tableforone-channel-scout
/plugin install channel-scout@tableforone-channel-scout

Then type:

/channel-scout

Channel Scout asks for your company name, creates a folder at ~/channel-scout/[your-company]/, and starts the ONBOARD interview. Answer in plain English. Ten minutes in you will have a profile and a watchlist. By end of session you will have two channels to test, two draft posts per channel in your voice, and a kill criteria number for each.

All files live locally. Nothing is sent anywhere. Nothing expires.

The Daily Coach

At the end of your first session, you choose how the daily run works.

Automatic registers a launchd task on Mac or a crontab on Linux that fires at your chosen time. If your laptop was asleep, it runs when you open it.

On open adds a SessionStart hook to your Claude Code settings so the coaching run starts every time you open Claude Code.

Manual means you run /channel-scout coach yourself.

The coaching note is short. Post performance against kill criteria. What shifted in the competitor feeds overnight, if anything changed. One specific recommendation for today.

The dashboard is a static HTML file Channel Scout regenerates after every coach run: scorecard table, today’s note, competitor activity, kill criteria status in one page.

Channel Scout does not read your full post history every morning. It reads the rolling stack, and competitor feeds only get fetched if something actually changed since the last run. That is token discipline built into the design. A daily process should not become an expensive one.

What I’d Do Differently

I tried to make the PREDICT output final. Two channels, full reasoning, done. But the wind tunnel results surprised me often enough that I wanted to be able to push back on the picks. The tool now writes the full reasoning to prediction.md, and if you run /channel-scout again and tell it you want to revisit a pick, it re-runs PROBE with adjusted parameters instead of just confirming the first output.

I wish I had designed for that iteration loop from the start. The first version assumed the model would always surface the same two obvious channels. It does not, and the divergence cases are often the more interesting ones.

If the channel picks surprise you, or something breaks on your setup, reply and tell me what it gave you.

Durva

• Vibe Coding Lab #2: The Tool To Help You Visualize Your Product

• Vibe Coding Lab #1: The Morning Brief To Make You 10x Smarter

  ---

So you’re three hours deep asking Claude to “find the issue” and it’s finding things, but none of them are the actual thing.

I’ve been there.

When you vibe-code, the AI builds fast and you ship faster. Somewhere in between, the code outpaces your understanding of it. The logic exists, but it exists in the AI’s “head”, not yours. So when something breaks, you can’t point to what or where. You grep through files. You ask Claude for help without being specific. You’re scared to delete anything because you don’t know what depends on it.

That’s not a skill issue. That’s a visibility issue.

Sprintt is the agent library I’m building for solo founders. It has 127 functions and 42 dependencies across 28 features. I built every one with Claude. Until last week, I couldn’t tell you what most of them did. I was exactly where you are.

So I built a tool that shows you what’s there.

Skip Explanation And Get The Prompts

Overview Of The Skill: What It Does

This simple and free claude skill helps you visualize your vibe-coded product and identify the gaps you could have missed. Point it at any project folder. A browser tab opens with three views of your codebase: three different ways of looking at the same code, depending on what you’re trying to figure out.

App Flow:

Three columns: pages on the left, database tables in the middle, external services and API routes on the right. Pages are grouped by URL section: all your /admin/* pages together, all your /onboarding/* together etc. Each page is a card you can expand to see the components inside it. Each component shows what data it queries, where it navigates, what server actions it calls. Arrows connect components to the specific tables and services they touch.

Constellation:

Same data, radial layout. Four concentric rings: pages on the outside, then API routes, then database tables, external services at the center. Routes and tables don’t sit randomly. They gravitate toward the pages that use them. If your agents table is read by both dashboard and admin pages, it floats between those sections. The layout shows you something no file tree does: how siloed or shared each resource actually is.

Function Map:

Every function in the codebase as a block, grouped by file. Click one to see what calls it and what it calls. Dead code flagged. Linter issues surfaced. Claude writes a plain-English explanation of what each function does, and if it has bugs, generates a ready-to-paste fix prompt for Cursor. This is the deep-dive view for when something’s broken and you need to actually trace it.

Two toggles work across the views:

• Heatmap. Colors nodes by connection count. Tables go blue for reads, red for writes. Pages get more saturated the more routes call them. Lets you see at a glance which tables are your hottest and which pages are doing the most work.

• Orphans. Highlights anything with zero connections. A page no route leads to. A table nothing reads. A service nothing imports. Orphan doesn’t always mean broken. Sometimes the connection is dynamic, sometimes the analyzer missed it. But now you have something specific to investigate instead of a vague sense that something’s off.

Your code never leaves your machine.

How To Get It Running

Two ways. Pick one.

The Fast Way (1 Minute)

If you have Claude Code installed and don’t mind downloading from my free GitHub repo, paste these two commands:

/plugin marketplace add DM1195/tableforone-codebase-visualizer
/plugin install codebase-visualizer@tableforone-codebase-visualizer

Then in any project, ask Claude Code: “map my codebase” and point it to a folder.

Build It Yourself

If you’d rather build it yourself, or customize it for your stack, it’s five prompts run in sequence in Claude Code, about 30 to 45 minutes. The prompts produce the function-level analyzer, the app flow parser, the visualization, the constellation layout, and the skill wrapper that orchestrates it all.

The full prompts, the design constraints, and the gotchas are in this doc. One thing to note: don’t paste all five at once. Run each, see what you get, fix what’s off, then move on.

The plugin is open source. Repo here. The doc has the full setup, all five prompts, and a few features I cut from this post for length.

Get The Prompts

What This Is Really About

The work isn’t writing code anymore. The work is seeing what you built.

Once you’ve shipped something you can’t see inside, your options narrow fast: abandon it, or rebuild it from scratch. Most founders pick one of those after losing weeks. The hope is that now you don’t have to.

If something doesn’t work, send me a message. Wrong stack, missing feature, broken on your setup, whatever it is. I’d rather know than have you hit a wall and give up on it.

And if you’re a solo founder trying to figure out how to build and ship without a team behind you, Table For One is where I write. The tools, the decisions, the mistakes, written specifically for people building solo. Free to subscribe.

- Durva

Subscribe now

This is a new Tuesday series where I share the small tools I build for myself, with the actual instructions you need to set them up. You don’t need to know how to code. You need to be able to copy and paste. First up: a daily personal newspaper that publishes itself at 6am, costs a few cents a day, and lives at a URL you bookmark on your phone.

Like most founders, I subscribe to about a hundred Substacks (okay, maybe twenty). I have at least three podcasts on rotation that I want to listen to and never do. I have set news alerts for my industry. And most mornings used to start the same way. Coffee. Scrolling my mailbox for news. Checking what’s happening on Twitter. Feeling overwhelmed and shutting my phone.

The result? In almost every founder meetup or dinner I was the last person who knew what was happening in the world of tech.

So one day I decided to use Claude to my advantage.

I built a morning brief agent that runs at 6am Pacific every day. It reads news from a list of topics I care about, scans five founder-heavy subreddits and Twitter, opens the newsletters that landed in my Gmail in the last 24 hours, and checks for new podcast episodes from a curated list of shows. It assembles all of that into a single beautifully designed webpage, with framed paintings from the Art Institute of Chicago laid between the sections, and publishes it to a private URL I’ve bookmarked on my phone. No email. No app. No notification. Just a bookmark I open with my coffee.

The whole thing costs about a nickel a day in Claude usage. The hosting is free. The setup, if you follow this post, takes about thirty minutes.

Here it is. Steal it.

A Note Before We Start

I built this using Claude Code. If you've never used it, here are the install tutorials. PS you need the Pro plan.

For Mac
For Windows

You don’t need to learn to code. Claude Code understands plain English. You’ll see grey boxes throughout this post. You don’t read or edit them. You paste them into Claude Code when I tell you to, and Claude Code does the rest.

You also don’t have to use every section. There are five (news, social, substack, podcasts, and art). Pick what you want during the setup step below. The post will tell you to skip the agents you didn’t pick.

The rest of this post assumes you have Claude Code running.

The Move That Actually Matters

I’ve vibe coded over twenty projects, some for me and some for my clients, so trust me when I say this. Ideate before you build. The order matters more than the prompts.

I did not start in Claude Code. I started in Claude Design. Before I wrote a single instruction for an agent, I designed what the finished brief would look like. The layout, the typography, the framed art, the section order. Once I knew what I was building toward, the agents almost wrote themselves, because I had a template with empty slots and I just needed to fill them.

You should do the same. Skip the ideation step (this post is the ideation, the sources and sections and order are already decided). But the design is yours. Open Claude Design and paste this:

I'm building a daily morning brief that will live on a webpage I bookmark on my phone. It pulls from a few sources I care about. [ADD WHAT YOU ACTUALLY CARE ABOUT] Design what this should look like. I want it to feel like a [ADD WHAT YOU WANT IT TO LOOK AND FEEL LIKE]. Each section should feel distinct. Ask me thoughtful questions before you start designing. Show me a draft I can iterate on. Then ask me what I want to change.

The first version will be rough. Iterate. Change the colors. Move the art. Make the headlines bigger. Try a serif. Try a sans. I spent an hour just getting the gold frames around the paintings to look like real frames instead of yellow rectangles. It matters more than you think. This is the thing you’ll open every morning.

When you like the design, save the HTML. You’ll hand it to Claude Code in the next step.

How The Thing Is Organized

In Claude Code, you can create something called a skill. It’s a folder of instructions Claude Code reads whenever you ask it to do a particular kind of task. Think of a skill as a job description you write once and Claude Code refers to every time.

The morning brief skill is one folder with a handful of files inside it. A main instruction file (the orchestrator, which is the manager), a config file with your preferences, sub-agent files (one per section you chose), and the template file you just designed. The folder lives at ~/.claude/skills/, inside a subfolder you'll name during the next step. The squiggle (~) is shorthand for your computer’s main user folder.

You’re not going to build this folder yourself. Claude Code will, in the next step.

Make It Yours

This is the most important step. We're going to do the personalization and the setup in one go. By the end, you'll have your folders, your config file, your template, and an orchestrator built around exactly the sections you want.

Tell Claude Code:

I want to build a daily morning brief. Interview me to set it up.             
                                                                                                                                                                  
  Step 1 — Understand what I actually need                                                                                                                        
                                                                                                                                                                  
  Before asking about sections or topics, ask me these four questions (one at a time, wait for each answer before continuing):
                                                                                                                                                                  
  1. What problem does this brief solve for you? What would you do differently if you had better information each morning?                                      
  2. What's something you wish you'd known 3 months ago — a story, a shift, a number — that you only found out too late?                                          
  3. What's one space adjacent to your work that you're curious about but don't currently follow?                                                                 
  4. When you think about the content you currently read, what feels like noise — topics that show up but you always skip?                                        
                                                                                                                                                                  
  Use my answers to build a picture of what I actually need signal on. You'll use this to suggest topics in Step 3.                                             
                                                                                                                                                                  
  Step 2 — Choose sections                                                                                                                                        
                                                                                                                                                                  
  Ask me which sections I want:                                                                                                                                   
  - News — Google News on topics I follow                                                                                                                         
  - Social — Reddit and Twitter/X                                                                                                                                 
  - Substack — newsletters in my Gmail                                                                                                                          
  - Podcasts — new episodes from shows I follow
  - Art — a daily painting curator from the Art Institute of Chicago (this is handled automatically in the orchestrator — no setup needed from me)
                                                                                                                                                                  
  Step 3 — Interview me on each section I chose                                 
                                                                                                                                                                  
  For News: Based on my answers in Step 1, suggest 8–10 specific topic strings I could track — not generic labels like "entrepreneurship" but precise search    
  phrases like "founder case study", "frontier AI startup adoption", "creator economy solo founder". Walk me through each suggestion and explain why you're       
  recommending it based on what I told you. Let me accept, reject, or modify each one. Also ask: how many articles per day (default 6), and max age in hours      
  (default 24).                                                                                                                                                   
                                                                                                                                                                  
  For Social: Ask which subreddits I want. Suggest 4–6 based on my topics — include at least one that isn't the obvious choice. For Twitter/X: ask if there are   
  specific accounts I want to track. If I don't have names, suggest 4–5 handles relevant to my topic mix and explain who they are. Save confirmed handles as a    
  twitter_handles array in config. Ask for max threads (default 5).                                                                                             

  For Substack: Ask if I've connected the Gmail MCP connector in Claude settings. If I haven't, walk me through it: open Claude settings → Connectors → Gmail →   
  authorize. Wait for confirmation. Ask for my Gmail address and whether there are any senders I want to skip (promotional Substack emails, digest roundups,
  etc.).                                                                                                                                                          
                                                                                                                                                                
  For Podcasts: Ask me for show names. Look up the RSS feed URL for each show on the web and save it alongside the show name. If you can't find an RSS feed, tell 
  me and skip it. Do not invent URLs. Ask for max age in hours (default 48).    
                                                                                                                                                                  
  Step 4 — GitHub and timezone                                                                                                                                  
                                                                                                                                                                  
  Ask for my GitHub username and timezone.                                     
                                                                                                                                                                  
  Step 5 — HTML template                                                                                                                                        

  Ask me to paste the HTML template I designed. Save it as templates/template.html.                                                                               
                                                                                
  Step 6 — Create the skill                                                                                                                                       
                                                                                                                                                                
  Ask what to name the skill folder. Validate: no spaces, no slashes, letters/numbers/hyphens/underscores only. If ~/.claude/skills/{name}/ already exists, tell  
  me and ask whether to pick a different name or overwrite.                     
                                                                                                                                                                  
  Create the folder at ~/.claude/skills/{name}/ with three subfolders: agents/, staging/, templates/. Save my HTML at templates/template.html.                  
                                                                                                                                                                  
  Step 7 — Write config.json            
                                                                                                                                                                  
  Write config.json in the skill root with this shape:                                                                                                            
                                                                                
  {                                                                                                                                                               
    "schedule": { "time": "07:00", "timezone": "America/New_York" },                                                                                            
    "delivery": {                                                                                                                                                 
      "github_pages_url": "https://{username}.github.io/morning-brief/",        
      "github_repo": "{username}/morning-brief",                                                                                                                  
      "github_pat_file": "~/.config/morning-brief/github-pat"                                                                                                   
    },                                                                                                                                                            
    "topics": ["...confirmed topic strings..."],                                
    "news": { "articles_per_run": 6, "max_age_hours": 24 },                                                                                                       
    "social": {                                                                                                                                                 
      "platforms": ["reddit", "twitter"],                                                                                                                         
      "subreddits": ["..."],                                                                                                                                    
      "twitter_handles": ["..."],                                                                                                                                 
      "max_threads": 5                                                                                                                                            
    },                                                                                                                                                            
    "substack": {                                                                                                                                                 
      "gmail_account": "...",                                                                                                                                   
      "max_age_hours": 24,                                                                                                                                        
      "skip_senders": ["reaction@mg1.substack.com", "forum@mg1.substack.com", "no-reply@substack.com"]
    },                                                                                                                                                            
    "podcasts": {                                                                                                                                               
      "feeds": [{ "name": "Show Name", "url": "https://..." }],
      "max_age_hours": 48                                                      
    },                                                                                                                                                            
    "learnings": {                      
      "articles_path": "~/notes/learnings/articles/",                                                                                                             
      "podcasts_path": "~/notes/learnings/podcasts/"                                                                                                              
    }                                                                           
  }                                                                                                                                                               
                                                                                                                                                                
  Step 8 — Write SKILL.md                                                                                                                                         
                                                                                                                                                                  
  Write SKILL.md in the skill root. It is the orchestrator that runs daily. It must do the following in order:                                                    
                                                                                                                                                                  
  1. Read config.json and today's date in four formats: display (Monday, May 12, 2026), uppercase display, filename (2026-05-12), issue number (No. 12 for the  
  12th).                                                                        
  2. Read the instruction files for each chosen agent, then spawn all of them simultaneously as parallel sub-agents. Each agent writes its output to              
  ./staging/{name}.json. The agents are:                                       
    - agents/news-agent.md → staging/news.json                                                                                                                    
    - agents/social-agent.md → staging/social.json                                                                                                              
    - agents/substack-agent.md → staging/substack.json                                                                                                            
    - agents/podcast-agent.md → staging/podcast.json                                                                                                              
  3. Art curation (handled directly in the orchestrator — no separate agent):   
    - Read staging/art-state.json for seen_ids and rotation history                                                                                               
    - Pick today's search term by day-of-month using a 13-term rotation: impressionism, post-impressionism, realism, american scene painting, modernism, landscape
   painting, portrait, still life, romanticism, baroque painting, genre painting, expressionism, urban scene                                                      
    - Fetch from AIC API: https://api.artic.edu/api/v1/artworks/search?q={term}&fields=id,title,artist_display,date_display,medium_display,image_id,description,st
  yle_titles,subject_titles&limit=50&query[term][is_public_domain]=true                                                                                           
    - Filter: image_id must be present and not in seen_ids. Pick 4.                                                                                               
    - For each, write 2–3 sentences grounded only in API data (style_titles, subject_titles, medium_display, description). Do not invent biographical details.    
    - Build image URLs: https://www.artic.edu/iiif/2/{image_id}/full/1600,/0/default.jpg                                                                          
    - Update art-state.json: append today's 4 ids to seen_ids, trim to 120, update history.                                                                       
  4. Read all four staging JSON files.                                                                                                                          
  5. Read templates/template.html. Replace every <!-- INJECT:NAME --> marker with the appropriate content. Never leave any marker unreplaced in the output. Key   
  injections:                                                                                                                                                     
    - INJECT:DATE, INJECT:DATE_UPPER, INJECT:ISSUE_NUMBER, INJECT:TALLY                                                                                           
    - INJECT:COVER_HEADLINE — 6–10 word editorial headline across today's themes                                                                                  
    - INJECT:COVER_STAND — 2–3 sentence framing of today's edition, under 45 words                                                                                
    - News section: use articles[0] from news.json as the lead; articles[1…N] as grid cards                                                                       
    - Art: inject 4 artwork URLs, titles, artists, dates, mediums, and curator notes                                                                              
    - Social: sentiment, pullquote (not pull_quote), and threads (not items) from social.json                                                                     
    - Substack: newsletters array from substack.json                                                                                                              
    - Podcast section: inject only if has_episodes is true in podcast.json; omit entirely if false                                                                
    - INJECT:COLOPHON_TALLY, INJECT:COLOPHON_ART, INJECT:YEAR                                                                                                     
  6. Write assembled HTML to staging/morning-brief-YYYY-MM-DD.html. Verify no <!-- INJECT:... --> markers remain before writing.                                  
  7. Push to GitHub Pages via the Contents API (GET the SHA first, then PUT). Also push to archive/YYYY-MM-DD.html. If the PAT file is missing or the API errors, 
  log and continue — do not abort.                                                                                                                                
  8. Save learnings: write one markdown file per run to learnings.articles_path and (if episodes exist) learnings.podcasts_path.                                  
  9. Print a completion summary: date, live URL, article/newsletter/episode counts, learnings path.                                                               
                                                                                                                                                                  
  Add this rule at the end of SKILL.md: If any agent fails, omit that section from the template and continue. Do not block the brief on one bad fetch.            
                                                                                                                                                                  
  Step 9 — Show me what we built                                                                                                                                  
                                                                                                                                                                  
  Print the full folder structure so I can see everything that was created.

Claude Code will ask the questions one by one. Answer in plain English. By the end, your folders exist, your config file is written, your template is in place, and your orchestrator is built around exactly the agents you want. If you said you don’t care about podcasts, there’s no podcast agent in your orchestrator. If you only want news and art, that’s all your orchestrator runs.

Don’t worry about the format Claude Code uses to show you the folders. It’ll look like a little tree of file names. If the folders you expected are in there, you’re good.

The failure-handling line at the end is doing more work than it looks. The first version of this whole system would crash whenever Reddit was slow to respond, which was often. Now if any one source breaks, the brief just ships without that section. An imperfect brief at 6am beats a perfect brief at noon.

This is the only part of the build where you’re talking about yourself instead of pasting. The whole brief reads to you, not to me. So this step is the one that matters most.

The News Agent

Skip this if you didn’t pick it during the interview.

This one handles news. It reads Google News for the topics in your config, picks the most relevant ones for a solo founder, writes a short summary of each, and adds two things I find more useful than the summaries themselves. The first is Claude’s Take, one sharp sentence on what the article actually signals, not just what it says. The second is a content angle, a specific post idea the article suggests, so I can grab it later when I’m staring at a blank Substack draft.

Tell Claude Code:

Create a file inside the agents folder, named news-agent.md, with the following contents:

You are the News agent for the Morning Brief.

1. Fetch the Google News RSS feed for each topic listed in
   config.json under "news_topics". Construct URLs like:
   https://news.google.com/rss/search?q={topic}&hl=en-US

2. Dedupe across feeds by URL and by title similarity.

3. For each remaining article, score it 1-5 on relevance to
   "a solo founder building a B2B or prosumer product." 5
   means must-read. 1 means skip.

4. Keep only articles scored 4 or 5. From those, pick ONE lead
   (highest score, breaks ties by recency) and up to 4 secondaries.

5. For each kept article, write:
   - title (rewrite for clarity; do not parrot SEO headlines)
   - summary (2-3 sentences, what happened and why)
   - claude_take (ONE sentence. What does this actually signal,
     not what does it say. Sharp. No hedging.)
   - content_angle (ONE sentence. A specific Substack or
     LinkedIn post premise this article suggests for a solo
     founder to write.)
   - source, url, published_at

6. Write the result to ./staging/news.json with this shape:
   { "lead": {...}, "secondary": [...] }

Do not include articles you scored below 4. A short brief is
better than a padded one.

The Claude's Take field is what makes this read like a real publication instead of a feed reader. Anyone can summarize an article. Naming the signal underneath is the editorial muscle. That one sentence is the reason I read the brief instead of just looking at headlines.

The Social Agent

Skip this if you didn’t pick it during the interview.

This one handles Reddit and Twitter. It pulls the threads doing well in your subreddits (above a minimum threshold of upvotes and comments, so dead threads get skipped) and the highest-signal tweets from the accounts you follow. For each one, it writes a short take on the community mood and what it means, not on what the thread is about. It produces a sentiment breakdown (a quick read on whether the founder internet feels positive, neutral, or negative today), and it pulls one sharp anonymous quote as a daily pull quote.

Tell Claude Code:

Create a file inside the agents folder, named social-agent.md, with the following contents:

You are the Social agent for the Morning Brief.

1. For each subreddit in config.json under "subreddits", fetch
   the top posts from the last 24 hours via:
   https://www.reddit.com/r/{name}/top.json?t=day&limit=15
   Filter to threads with score >= 50 or comments >= 25.

2. For each Twitter handle listed in config.json under
   "twitter_handles", fetch the user's recent tweets (last 24
   hours) using the Twitter MCP connector if available. If no
   connector is set up, fall back to scraping the public
   profile via nitter.net or similar mirror. Filter to tweets
   with likes >= 100 OR retweets >= 25 OR replies >= 20.

3. For each remaining Reddit thread, read the post and top 5
   comments. For each remaining tweet, read the tweet and top
   replies. Then write:
   - title (use the original)
   - source ("reddit/r/{name}" or "twitter/@{handle}")
   - signal (2-3 sentences. NOT what the thread is about. What
     the community mood is, and what that mood means for a
     solo founder paying attention.)
   - url, score, comments

4. Across all items kept, produce a single sentiment object:
   { "positive": int, "neutral": int, "negative": int }
   The three values must sum to 100. Base this on overall
   tone for the day, not any one thread.

5. Pick ONE pull quote from the day's items. A real comment
   or tweet, no more than 30 words, attributed by username.
   Choose for sharpness, not popularity.

6. Write to ./staging/social.json:
   { "sentiment": {...}, "pull_quote": {...}, "items": [...] }

If no items cleared the filters on either source, write
{ "has_content": false } and stop.

The pull quote is my favorite feature. One sharp anonymous voice every morning, sitting under the sentiment bar. It's the thing that makes the brief feel like a person put it together instead of an algorithm.

The Substack Agent

Skip this if you didn’t pick it during the interview.

This one reads your actual Gmail. It uses an MCP connector, which is a permission slip you give Claude to talk to another app on your behalf. You’ll connect Gmail once in your Claude settings, and after that this agent can read newsletters that landed overnight. It writes a short summary of each, pulls out the most useful idea, and suggests a content angle in case you want to write a response later.

Tell Claude Code:

Create a file inside the agents folder, named substack-agent.md, with the following contents:

You are the Substack agent for the Morning Brief.

1. Use the Gmail MCP connector to search for emails received in
   the last 24 hours from senders listed in config.json under
   "newsletter_senders".

2. For each email, extract the article body (strip the email
   chrome, footers, unsubscribe links). Get the canonical URL
   from the email if present.

3. For each newsletter, write:
   - title (the post title, not the email subject if different)
   - author (sender name, cleaned)
   - summary (3-4 sentences. What the piece argues. Not "the
     author talks about." What they actually claim.)
   - key_insight (ONE sentence. The single most useful idea
     for a solo founder, stated as a takeaway not a quote.)
   - content_angle (ONE sentence. A response, counterpoint, or
     extension a solo founder could write this week.)
   - url, received_at

4. Write to ./staging/substack.json as a list. If nothing came
   in overnight, write [] and stop. An empty Substack section
   is fine. A fake one is not.

The Podcast Agent

Skip this if you didn’t pick it during the interview.

This one checks for new podcast episodes in the last three days from a list of shows in your config. It only keeps episodes that are actually relevant, and for those, it writes a short summary plus a few timestamped key moments so you know what to skip to. If nothing new and good came out, the whole podcast section gets omitted from the brief that day.

Tell Claude Code:

Create a file inside the agents folder, named podcast-agent.md, with the following contents:

You are the Podcast agent for the Morning Brief.

1. For each show listed in config.json under "podcasts", search
   for episodes published in the last 72 hours. Use the show's
   RSS feed URL from the config.

2. For each new episode, score 1-5 on relevance to a solo
   founder building a B2B or prosumer product. Keep only
   episodes scored 4 or 5.

3. For each kept episode, write:
   - title, show, host, duration, published_at, audio_url
   - summary (3 sentences. What the episode is actually about,
     not the marketing description.)
   - key_moments: a list of up to 3 objects, each:
     { "timestamp": "HH:MM:SS", "note": "what's said here" }

4. Write to ./staging/podcast.json:
   { "has_episodes": true, "episodes": [...] }

   If no episodes cleared the bar, write:
   { "has_episodes": false }

   The orchestrator will omit the Podcast section entirely
   when has_episodes is false. Do not pad.

The podcast agent reads RSS feed URLs from your config. The interview step already looked these up for you when you named your shows, so you shouldn't have to do anything here. If a podcast section never shows up and you think it should, the RSS URL is probably the thing to check first.

The Art Curator

Skip this if you didn't pick it during the interview. If you change your mind later, paste the prompt below and ask Claude Code to add the curator to your orchestrator.

This is the part I’m proudest of, and it’s what turns the brief from a dashboard into something that feels like a magazine.

Every edition includes four paintings from the Art Institute of Chicago’s collection. The AIC has a free public image service (no account, no key) that serves high-resolution versions of everything they own. About a hundred thousand works.

The curator is a sub-agent. Every morning it picks one art movement from a rotating list of thirteen (impressionism, post-impressionism, baroque, urban scene, surrealism, and so on), searches the AIC for that movement, filters out anything that’s appeared in the last thirty days, and selects four fresh paintings. The next day, a different movement. By day fourteen it’s cycled through all thirteen and starts over, but with completely different paintings, because the previous set is still on the recently-seen list. Nothing repeats within a month.

For each painting, the curator writes a short story in a specific voice. The factual base comes from the AIC’s own metadata (style, museum description, medium, year). The curator can only assert things the data supports. No invented biographies, no fake anecdotes. The story is short, in second person, with a little bite.

Tell Claude Code:

Create a file inside the agents folder, named art-curator.md, with the following contents:

You are the Art Curator for the Morning Brief.

Your job is to pick 4 fresh paintings from the Art Institute
of Chicago's public collection every day, and write a short
story for each in the voice described below.

1. Read ./staging/art-state.json. It contains:
   - "seen_ids": AIC artwork IDs that have appeared in the
     brief in the last 30 days
   - "movement_rotation": a 13-item list of art movements
     ["impressionism", "post-impressionism", "baroque",
      "urban scene", "surrealism", "japanese woodblock",
      "american modernism", "cubism", "fauvism",
      "abstract expressionism", "renaissance", "romanticism",
      "realism"]
   - "rotation_index": integer 0-12, wraps around

2. Pick today's movement using rotation_index. Search the AIC
   API:
   https://api.artic.edu/api/v1/artworks/search
     ?q={movement}
     &fields=id,title,artist_display,style_titles,
             description,medium_display,date_display,image_id
     &limit=50

3. Filter out:
   - Any artwork whose id appears in seen_ids
   - Any without an image_id
   - Any without an artist_display

4. From the remaining candidates, select 4. Prioritize
   variety (no two works by the same artist) and recognizable
   quality (works with a museum description tend to be the
   majors).

5. For each painting, write:
   - image_id (use directly from the API)
   - title (use the API's title)
   - artist (just the name, no dates)
   - year (from date_display)
   - story: 2-4 sentences, second person, with bite. Use
     style_titles, description, and medium_display as the
     factual base. ONLY assert what the API data supports.
     Do not invent biographical details, prices, or anecdotes.

6. Write the result to ./staging/art.json as a list of 4
   objects.

7. Update ./staging/art-state.json:
   - Append today's 4 ids to seen_ids
   - Drop any ids older than 30 editions
   - Increment rotation_index by 1, wrapping at 13

If the API errors or fewer than 4 candidates clear the filter,
write { "fallback": true } and stop.

The line about not inventing biographies is the one I rewrote the most. The curator is good at writing in voice. It’s a little too good at inventing context to fit the voice. The first version once told me, confidently, that a 17th-century Dutch painter had been disowned by his family. He had not. He had simply painted a lot of taverns.

So now the stories are quieter sometimes. But they’re true.

Publishing It

Now for the last step. You need three things to happen: your brief has to live on the internet somewhere, it has to run automatically every morning, and you have to know the URL to bookmark.

All three happen in one prompt. Claude Code will walk you through the parts you have to click yourself, wait for you to confirm each one, verify it worked, schedule the brief to run at the time you want, and give you the URL at the end.

Tell Claude Code:

I'm ready to ship my morning brief. Walk me through this one step at a time. Wait for me to confirm each step is done before moving to the next, and verify the result whenever you can. First, help me set up GitHub Pages. Tell me how to create a free GitHub account (if I don't have one), how to make a new public repository called morning-brief, how to turn on GitHub Pages in the repo settings, and how to generate a personal access token with the right permissions. After each click step, ask me to confirm. After I confirm the token, save it to my config.json. Then verify the GitHub repo and Pages are set up correctly by checking the URL. Second, ask me what time I want the brief to run and which timezone I'm in. Convert that into the right cron schedule for UTC and set up a Claude Code remote routine that runs my news-digest skill at that time, every day. Third, run the brief once now as a test so we can confirm the whole pipeline works end to end. If anything fails, tell me what failed and how to fix it. Finally, give me the bookmark URL where my brief will live, and tell me when the next scheduled run is.

That’s the last thing you have to paste.

When Claude Code finishes, you’ll have a URL. Open it on your phone. Bookmark it. Tomorrow morning, when you reach for your coffee, that’s where you’ll go.

If you get stuck on the GitHub part, reply to this email or message me and I’ll walk you through it.

What I’d Do Differently

I tried to make every section equally important. Same card size, same length, same weight. It read like a feed. The fix was hierarchy. Make the most important thing the biggest and the least important thing the smallest. One lead article gets a drop cap. Four secondary articles sit in a grid below it. The sentiment bar is a thin strip, not a section. Podcasts only show up when there’s something worth listening to.

I also included too much. Eight subreddits. Ten newsletters. Six podcasts. The brief got long and I started skimming. So I cut everything in half. I read all of it now. Fewer inputs, sharper outputs.

The first version had no failure handling. One slow API call would kill the entire 6am run. Now every agent has a quiet contract. If you fail, the brief still ships without your section. Things break. The brief still comes out at 6am.

Ready To Steal

My whole system is in this post. Top to bottom. The design step, the interview, the agents you chose, the art curator, the deploy, the schedule. Paste them in order. The interview does the heavy lifting in the middle. By the time you’re done, you have a bookmark.

It’s set up for me. The topics, the subreddits, the senders, the podcasts. The first thing you should do, before anything else, is design your own brief and run the interview. Make it yours. The whole point is that it reads to you, not to me.

If you build something with this, reply and send me the link. I want to see what your 6am looks like.