# The Files-First Starter Kit From "Applied AI for Marketing Ops" (appliedaiformops.com) by Lily Luo. Four files that stop you from re-explaining yourself every session: who you are, what is live right now, your standards, and your corrections. **Two ways to use this file:** - **By hand.** Read it top to bottom and fill in the four templates. Works in any chat window. - **Give it to your agent.** Paste this whole file to your AI agent and say "set this up for me." The last section is instructions for the agent. --- Better output from AI comes from four files, not a platform. Most people start with a tool: a project, a connector, an agent. The files are what make output sound like you. A tool just decides how many of them it can read at once. This kit is the smallest version of the system I run for my own work: four short documents that answer who you are, what is going on right now, how output should read, and what you have already corrected. Paste them into a chat window at the start of a session, or point any project or connector at the folder. Either way, you stop re-explaining yourself every time. ## The four files | File | What it answers | |---|---| | 01-who-you-are.md | The facts an AI system should never get wrong about you | | 02-current-state.md | What is live right now, so you do not have to recap it | | 03-standards.md | How output should read | | 04-corrections.md | What you have already fixed, so it stops coming back | ## How to use this 1. Copy the templates below into their own files, or into one pasted document if your tool only takes one. 2. Fill in `01-who-you-are.md` first. Be precise about what is true and how it should be framed. This is the file every other answer should trace back to. 3. Fill in `02-current-state.md` next, and keep it current. This is the file that goes stale fastest, because it describes this week, not your whole career. 4. Write `03-standards.md` from real before and after examples of your own writing, not abstract rules. 5. Start `04-corrections.md` empty. The first entry goes in the first time you catch yourself giving the same feedback twice. ## The one habit that makes this work Every time you correct something, ask whether it is a one-off or a pattern. One-offs just get fixed. Patterns go in the corrections file, dated, so you only ever explain them once. ## Going further This kit stops at four files you paste by hand. If your tool can read a folder on its own, split facts from standards from boundaries, add routing so the right file loads for the right task, and add checks that run before you see a draft, that is the next kit: The AI Operating System Starter Kit (lilyluo.ai/starter-kits/ai-operating-system). Start here. Move there when a chat window stops being enough. --- ## `01-who-you-are.md` (Who you are) The facts an AI system should never get wrong about you. Everything it states about you in a draft should trace back to a line here. Write each fact precisely enough that it cannot be restated into something you would not claim. A true fact, loosely written, is how you end up with a claim you never made. --- ### Identity - Role and scope: - What you want to be known for: - What you do NOT want to be described as: ### True but easy to overstate The facts most likely to get inflated once an AI system gets hold of them, with the framing that keeps them honest. | The fact | How it must be framed | |---|---| | | | ### Not true, and worth saying so Assumptions people or systems make about you that are wrong. Say them once, here, so they stop being repeated. - --- ### A real example Here is a line from my own file, kept exactly as written: a project I run is an experimental multi-agent setup on a small cloud server, not a running product. Scripts poll and answer on their own between the sessions where I actually direct the work, and right now that autonomous part is paused because I do not have time to manage it. Without the file saying so plainly, a draft would describe something closer to an always-on product than a personal system I built and still run by hand at the decision points. That is the shape every row in this file should take: the fact, and the sentence that keeps a system from upgrading it into something bigger than it is. --- ## `02-current-state.md` (Current state) What is live right now. The file that goes stale fastest, because it describes this week, not your whole history, and that is exactly why it is worth keeping. Without this file, every session starts the same way: you explain what you are working on, what is open, and what already got decided, before any actual work happens. With it, that gets loaded automatically, and the session starts on the work. --- ### What is live A short list, not a history. Drop anything that closed. | What | Status | Since | |---|---|---| | | | | ### Open loops Things waiting on a decision, a reply, or a next step. One line each. - ### Key dates Dates that should change what an AI system tells you to do next, not just sit in a calendar. | Date | What happens | |---|---| | | | ### Standing corrections currently in force Pull these from `04-corrections.md`, the small number that apply to almost everything, so they load even in a tool that only reads one file. - --- ### A real example My own version of this file is what keeps three unrelated things straight at once without me repeating myself: a Substack post still being drafted, a fantasy football roster decision that depends on who is on a bye this week, and a trip date that needs a weather check closer to departure. Each one actually lives in its own place, a task brief, a dated reminder, but the current-state file is what keeps all three in view at once instead of making me hold them in my head. With it, a session starts on the decision. --- ## `03-standards.md` (Standards) How you work, and how output should read. This is the file that makes output sound like you instead of like anyone else who typed the same prompt. --- ### Never use - ### Always use - ### The test for any sentence A question you can actually apply, not a quality score: would an ops leader say it out loud to a colleague at lunch, or does it only work typed. ### Two real examples **Example 1** Weaker version: > We leveraged a best-in-class automation to seamlessly streamline the process. Better version: > We moved the task from a manual step to a scripted one. Why: the first sentence could describe any project at any company. The second names the actual change. **Example 2** Weaker version: > It's not just automation. It's a whole new way of working. Better version: > The task used to take a manual review every time. Now it runs on its own and only surfaces the cases that need a person. Why: a sentence shaped like "it's not X, it's Y" reads as a pitch. Naming the actual before and after does the same job without sounding like one. --- ### A real rule from my own file No em dashes, anywhere, including casual replies. The correction that produced this rule was blunt: too many, replace them. Commas or periods do the same work without the tic. It is a small rule, and it is the one a linter can actually enforce before a draft reaches you, which is why it is worth writing down exactly, not just remembering to try to avoid. --- ## `04-corrections.md` (Corrections) What you have already fixed, written down so it stops coming back. This is the file that makes the system compound instead of resetting every session. The habit: when you correct something, ask if it is a one-off or a pattern. One-offs just get fixed. Patterns go here, dated, with your actual words if you have them. --- ### Format **Date and short name** - What happened: the output that triggered the correction - The correction: what it should have been - The rule going forward: stated so it applies beyond this one case --- ### Real entries from my own log **Em dashes** - What happened: drafts kept using an em dash as the connector between two clauses. - The correction: replace them, there were too many. - The rule going forward: no em dashes, anywhere, including chat replies. Commas or periods instead. **Consultant abstractions** - What happened: a draft reply was full of slideware language, consultant jargon standing in for the actual thing that happened. - The correction: get rid of it, use plain speak. - The rule going forward: name the actual system, decision, or number. If a sentence could sit on any consultant's slide, rewrite it specific. **A correction that did not become a rule** - What happened: one draft ran long, and a note came back that it was way too long. - The correction: shortened for that draft only. - Why it stayed a one-off: length depends on what you are replying to and how much detail it actually needs. Not every correction generalizes, and writing that down is part of keeping this file trustworthy. --- ### Your turn Paste your last three real corrections into the format above and ask your AI: "which of these are one-off fixes, and which should become standing rules I apply everywhere?" --- ## For your AI agent If your user pasted this whole file and asked you to set it up, do this: 1. Create a folder named `files-first` (or the name they choose) with four files: `01-who-you-are.md`, `02-current-state.md`, `03-standards.md`, `04-corrections.md`. 2. Split each backtick-named file section above into its own file, keeping the templates blank. Do not fill them in from what you know or assume about the user. The sections marked as real examples are reference only; the user's own files start empty. 3. Interview the user to fill in `01-who-you-are.md` first, one section at a time. Push for precision: for every fact, ask how it must be framed so it cannot be overstated. 4. Then `02-current-state.md`: what is live, what is open, and any key dates, in their own words. 5. Then `03-standards.md`, starting from real before and after examples of their own writing. 6. Leave `04-corrections.md` empty. Tell the user it fills in the first time they catch themselves repeating feedback, not before. 7. If the user's tool supports startup instructions (a CLAUDE.md, a system prompt, project instructions), point it at all four files.