3 Things To Build
In Claude This Weekend

You are going to interview me and then build my context base: a folder of files that holds everything you would need to know about me and my work to be genuinely useful, instead of me re-explaining myself at the start of every single chat.

This is a build session, not a chat. By the end you will have written real files to disk.

## How the interview works

- Ask me ONE question at a time. Wait for my answer. Never dump a list.
- Start broad, then follow the thread. If my answer is vague, push until it is concrete: real names, real numbers, real examples, real dates.
- If I give you a lazy answer, say so and ask again a different way.
- Keep it conversational. A smart friend getting to know my business, not a form.
- Plan for 25 to 35 questions across the areas below. Do not stop early because you think you have enough. You do not.
- Every 8 to 10 questions, tell me roughly how far along we are so I know the shape of it.

## What to cover

Work through these in a natural order. Do not read them out as a checklist.

1. **Me.** Name, where I am, what I do, how long, how I got here. What I am unusually good at. What I am genuinely bad at.
2. **The work.** What I actually produce. Who pays me or judges me. How the money works: what I charge, what I made last month, what I want to make. Every active project by name, with its real status.
3. **The people.** Everyone who matters by name: clients, collaborators, my boss, my team. For each one, the two or three things you would need to know to help me with anything involving them.
4. **The week.** How my time actually goes. What eats the hours. What I dread. What only I can do. What repeats every week without fail.
5. **The voice.** How I talk and write. Words I use constantly. Words I would never use. Have me paste in two or three things I wrote that sound like me, and pull the patterns out yourself instead of asking me to describe them.
6. **The rules.** How I want you to respond: length, directness, whether you push back or agree, whether you ask before acting or just go. What you should always do. What you should never do.
7. **The gaps.** What I would hand off tomorrow if I could. What I have tried to automate and failed at.

## Then build the folder

When you have enough, say "I have what I need, building your context base now" and write these files to a folder called `context/` in my current directory. Actually create them. Do not print them in the chat and ask me to save them myself.

- **`START-HERE.md`**: The map and the standing orders. Says what each other file holds, and instructs any future version of you to read all of them before answering anything, and to update them the moment a fact changes. Include the date it was built.
- **`me.md`**: Who I am, strengths, weaknesses, how I want to be talked to.
- **`work.md`**: The business or job in full detail. Offers, pricing, real numbers, every active project with status and next action.
- **`people.md`**: One short block per person. Name, relationship, context, what matters about them.
- **`week.md`**: What repeats, what eats my time, and a ranked list of what is most worth handing to you first.
- **`voice.md`**: How I write, with the real examples I gave you and the patterns you pulled out of them.

Rules for the files:
- Write in plain language. No corporate register, no filler.
- Use my real specifics everywhere. A context base full of generic statements is worthless.
- If I never gave you something, write `UNKNOWN, ask Zach` rather than inventing it. Use my actual name.
- Keep each file under 600 words. Dense beats long.

## Last step

After the files exist, tell me exactly how to point you at this folder in future sessions, and give me one test question I can ask in a brand new chat to prove the context base is actually loading.

Start now. First question only.

You are going to interview me about one task I do every week, and then write it as a real Claude skill I can trigger by name forever after.

Do not ask me to describe the task in the abstract and then write something generic. Interview me properly first. The whole value here is that the skill encodes my actual process, including the parts I would forget to mention.

## Step 1: Pick the task

Ask me what I do at least once a week that follows roughly the same steps each time.

If I name several, help me rank them. The best candidate has the highest ratio of repeatable steps to judgment calls, and costs me more than 15 minutes a week.

Reject a task that is too open-ended, and tell me why. "Think through a strategy problem" is not a skill. "Write the follow-up email after a sales call" is perfect.

## Step 2: Extract how I actually do it

Ask me ONE question at a time. Wait for each answer.

- Walk me through it start to finish, in order, as if narrating your screen.
- What do you need in front of you before you can start?
- What does the finished thing look like? Have me paste in a real example of a good one, and a bad one if I have it.
- How do you know it is good? What do you check before calling it done?
- What goes wrong? What trips you up? What variations come up?
- What do you always end up fixing by hand afterward?

Then write the process back to me and ask me what you missed. Do not move on until I confirm it.

## Step 3: Improve it before you build it

This is the step that makes the difference, so do not skip it.

My current process is not my best process. If you encode it as-is, you lock in every flaw.

Look at what I told you and answer these for yourself, then bring me your observations:

1. Which steps exist only out of habit and could be dropped?
2. What is missing? Quality checks, a validation step, an edge case I never formalized?
3. Is the output in the right format, or would a different one be far more useful to me downstream?
4. What would a genuinely world-class version of this output look like, specifically?
5. What are the most common ways this goes wrong, and can the skill prevent them rather than just warn about them?

Say: "Before I build this, here is what I would change and why." Then wait for my yes.

## Step 4: Write the skill

Ask me what to call it. Kebab-case, descriptive. Then create the folder `.claude/skills/[skill-name]/` and write `SKILL.md` inside it. Actually write the file. Do not paste it into the chat for me to save.

Structure:

```
---
name: [skill-name]
description: [What it does and when to use it, in 2-3 sentences, including the phrases I would actually say to trigger it]
---

# [Skill Name]

[One paragraph: what problem this solves and why it matters]

## When to use this
[The trigger, in plain language]

## What I need before starting
[The exact inputs, from my answer in step 2]

## Steps
[Numbered, in order, detailed enough that a different AI with zero other context would produce the same quality result]

## What done looks like
[The specific standard, from my answer in step 2]

## Never do this
[My failure modes from step 2, written as hard rules, not soft advice]
```

Write the steps so specifically that they name real files, real folders, real tools, and real defaults from my answers. A skill full of "consider the audience" is a wasted skill.

## Step 5: Test it, then tell me to do it again

Run the skill once, right now, on a real example. Show me the output. Ask me what is off, fix the SKILL.md, and run it again until it matches what I would have made by hand.

Then tell me this, in your own words: the second skill is the one that changes my week. Ask me what the next weekly task is, and offer to run this whole process again immediately.

Start now. First question only.

You are going to help me replace one piece of software I pay for every month with a version you build me this weekend.

I do not have a coding background. Assume that the entire time. Never tell me to "just" do something. Every instruction is one concrete action I can take without knowing what it means.

## Step 1: Find the right target

Ask me to list every subscription I pay for monthly, with the price. Ask me to check my card statement rather than doing it from memory, because the forgotten ones are usually the best candidates.

Then, for the ones worth considering, ask me one at a time:

- What do I actually use it for? Not what it sells itself as. What do I personally open it and do?
- Which features do I touch in a normal week?
- What do I pay, monthly and yearly?
- What annoys me about it?

Now score each candidate out loud on:

- **Surface area.** How much of the product do I actually use? The best target is one I use 10% of.
- **Data sensitivity.** Anything holding payment data, health records, or other people's private information is a bad first build. Say so.
- **Integration load.** How many other services would it have to talk to? Zero or one is a weekend. Four is not.
- **Blast radius.** If my version broke on a Tuesday, what happens? If the answer is "a client is hurt," pick something else first.

Recommend exactly one. Tell me plainly why the others lost. If everything on my list is a bad first build, say that and help me pick something smaller that is not a subscription at all.

## Step 2: Cut it down until it fits a weekend

This is where these builds die, so be aggressive.

Write out the one sentence describing what my version does. If that sentence has an "and" in it, cut it and show me the shorter version.

Then give me two lists:

- **This weekend:** the smallest thing that is genuinely useful to me on Monday.
- **Not this weekend:** everything else, written down so I can see it is not lost, just later.

Deliberately put accounts, logins, billing, multi-user support, and mobile apps in the second list unless one of them IS the point. Most of what a subscription charges for is the part I do not need.

Tell me honestly how long the first list will take. If it is more than about six hours of my actual attention, cut again before we start.

## Step 3: Decide what we are building it with

Pick the stack for me. Do not present me with options and ask me to choose, because I do not have the basis to choose.

Default to the simplest thing that works: a single-page web app I open in my browser, with data saved locally, unless what I described genuinely needs otherwise.

Tell me in two sentences what you picked and why. Then tell me exactly what I need installed before we start, with the download link, and wait for me to confirm each one is done before moving on.

## Step 4: Build it in visible pieces

Work in chunks that each end with something I can look at and click.

For every chunk:

1. Tell me in one sentence what we are about to make.
2. Build it.
3. Tell me exactly what to run or open, and exactly what I should see.
4. Ask me what I actually see before continuing.

Never stack three steps together. If I say something looks wrong, stop building and fix it before moving on.

Roughly every hour, stop and tell me plainly: what works now, what is left, and whether we are still on track to finish. If we are not, cut scope rather than rushing and tell me what you are cutting.

## Step 5: Make me actually use it

When the first list is done, do not congratulate me and stop.

- Walk me through using it once, for real, on real data.
- Ask what felt wrong. Fix those things now, while it is fresh.
- Show me how to open it tomorrow without asking you. Write that down in a `README.md` next to the project, in plain language, assuming I have forgotten everything.
- Tell me exactly what to check before I cancel the subscription, and what I would lose.

## When it goes sideways

It will. When it does, follow these without me having to ask:

- **An error I do not understand:** explain what it means in plain English first, then fix it. Never paste an error back at me as if it is my problem.
- **Same thing broken twice:** stop patching. Say "let me try a different approach" and change tack.
- **I got lost:** re-orient me. What we are building, what works already, what the current step is.
- **It is clearly not going to fit:** say that out loud, early, and cut to the version that does. A working smaller thing beats an unfinished bigger one every single time.

Start with step 1. Ask me for the subscription list.