Give it a memory

Interview me about my life so my assistant knows who it is working for. Then write the answers into the Profile table in my Airtable base.

How to run this:
- One question at a time. Wait for my answer before asking the next.
- Follow up when an answer is vague. Ask "what does that look like on a normal Tuesday?"
- Do not tidy my answers into corporate language. Keep my words.
- If I contradict myself, say so and ask which is truer.
- Do not write anything to Airtable until the end.

Cover these, roughly in this order, about twenty questions total:
- Name, where I live, what I do for money
- What happened in the last few years that matters
- What I am good at, and what people come to me for
- What I avoid, and what it costs me
- How I want to be spoken to: blunt, warm, brief, patient
- When my brain works best, and when it does not
- What a good week looks like, concretely
- Who is in my week, and how
- What I currently keep in my head that I wish I did not
- What I would not want an AI touching

At the end:
1. Show me a draft of every Profile field before writing anything.
2. Let me correct it.
3. Then write it to the Profile table, one row.
4. Read it back to me and ask if that is a person you know how to be useful to.

I want to move my existing to-do list into my Airtable base.

Step 1. Ask me which app or file my tasks currently live in. If I am not sure how to export from it, tell me exactly where the export button is.

Step 2. Once I have put the file in this folder, read it and tell me what you found: how many items, how far back they go, and whether they look like tasks or projects.

Step 3. Interview me about it, one question at a time:
- Which of these are still live?
- Which of these are projects with several steps hiding inside them?
- Is there anything in here I have been avoiding for months? Name them back to me.
- Anything private in here you should not put in the database?

Step 4. Propose a split: which rows become Projects, which become Tasks, and which get archived. Show me the list. Do not write yet.

Step 5. After I approve, write them to Airtable. Give every active Project exactly one Next Action, and if the source data does not give you one, ask me for it rather than inventing it.

Rules: never invent a due date. If something has no date, leave it empty. Tell me anything you chose to drop and why.

I want the facts pulled out of my old notes and into the Brain Context table, rather than a raw dump of the notes themselves.

Step 1. Ask me where my notes are and how many there are roughly. Apple Notes, Obsidian, a folder of documents, whatever it is. Help me get them into a folder as plain text or markdown.

Step 2. Sort them before reading them properly. Split into:
- Signal: 30 words or more, contains a decision, a fact, something that worked or failed
- Scraps: short reminders and shopping lists. Archive, do not process
- Sensitive: anything with a password, key, card number, or another person's private information

Tell me the counts. Sensitive stays on this machine and goes nowhere near the database. Confirm that back to me.

Step 3. Read the signal notes and pull out one claim at a time rather than a summary. Each claim carries the date it was written and which note it came from.

Step 4. Before anything is written, run a second pass over your own output whose only job is to find credentials, personal data or anything about another person that they would not want stored. If it finds any, stop and show me. Do not proceed until that pass is clean.

Step 5. Show me the first twenty facts for approval. Then write the approved set to Brain Context, keeping the date and source on every row.

Rules: never write a fact you cannot trace to a source note. If you are unsure whether something is a fact or my speculation, ask.

Connect this app to my Airtable base so it reads and writes my data.

Explain what you are doing as you go. I want to understand this bit.

1. Show me where to find my Airtable personal access token and which permissions to give it. Put it in an environment variable, never in a file that goes to GitHub.
2. Ask me for my base ID and find it with me if I do not know where it is.
3. Build one function that every call to Airtable goes through. It should:
   - Always ask for fields by their field ID rather than their name, and explain to me why that matters
   - Never use a cached response
   - Throw a clear error if Airtable says no
4. Store the table IDs and field IDs in one file, with a comment above each explaining what it holds.
5. Prove it works: fetch today's row from Daily Habits and print it in the terminal.

Rule: before writing the code, tell me in three sentences what would break if we asked for fields by name instead of ID.

Explain caching to me in the context of this app, then fix it.

1. In plain English, tell me what Next.js caches by default, why that is usually a good thing, and why it is wrong for an app reading a database that changes every day.
2. Show me what the symptom looks like, so I recognise it if it happens again.
3. Add the two lines to every API route in this project that reads or writes Airtable.
4. Add a rule to my project notes so you do not forget this in a future session.

Then quiz me: ask me what would happen if I logged the same habit twice without this fix. Correct me if I get it wrong.

top of every route that reads or writes your data

export const dynamic = "force-dynamic";
export const fetchCache = "force-no-store";

Build me a simple home page for this app.

Before you build it, ask me two things:
1. What are the three things I would want to see the second I open this on my phone?
2. Should it show me what is missing, for example a day with no sleep logged, or stay quiet about it?

Then build it:
- My name and one line from my Profile
- Today's row from Daily Habits, with anything unlogged shown as a gap rather than a zero
- Today's commitment from Commitments, or a prompt to set one
- Plain and readable on a phone. No charts, no icons, no colour scheme

Deploy it and give me the URL.

Rule: if a table is empty, say so on the page in plain words. Never show me a zero that is a missing value.

Write a CLAUDE.md at the root of this project so future sessions do not undo what we have built.

Interview me first, one question at a time:
1. How would I describe this app in one sentence to a friend?
2. What have we already decided that I would be annoyed to have to decide again?
3. Is there anything you did in this session that I asked you to change? Those are rules.

Then write the file, covering:
- What the app is, the stack, and where it deploys
- The rule about field IDs rather than field names, and what breaks without it
- The two caching lines every data route needs, and what breaks without them
- Credentials live only in environment variables
- Where the table and field IDs live

Keep it under a hundred lines. Every rule gets one line saying what goes wrong if it is ignored, because a rule with no consequence attached is a rule the next session talks itself out of.