# The Context Capture Starter Kit From "Applied AI for Marketing Ops" (appliedaiformops.com) by Lily Luo. Four pieces that keep your AI setup current on its own: a startup step, a scheduled capture routine, a corrections loop, and stale-context prompts. **Two ways to use this file:** - **By hand.** Read it top to bottom and build each piece with your AI agent's help. - **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. --- Files solve the first problem: output that does not sound like you. They do not solve the second one, which is that the files themselves go stale, and nobody tells you when. This kit is for the point where you have facts, standards, and a corrections file in place (if you do not yet, start with The Files-First Starter Kit, lilyluo.ai/starter-kits/files-first) and you are ready for your setup to keep itself current instead of waiting for you to remember to update it. ## The four pieces | Piece | What it does | |---|---| | A startup step | Loads your current state before any work begins, so a session never opens on "what are we doing again" | | A capture routine | Pulls context from email, chat, and meetings into the right project on a schedule, so you are not the only place that information lives | | A corrections loop | Turns a correction you have given more than once into a rule you approve | | Stale-context prompts | Tells you when a working session or a pane has gone stale, before it costs you a bad draft or a wasted session | ## What you need to build this More than a chat window. You need a tool that can run on a schedule, or at least on startup, and a place for it to write what it captures: a folder, a project, a notes system it can append to. This is the level where "AI tool" starts meaning something you configure. ## The point of all four together Each piece is small on its own. Together, they keep your setup current without you doing the updating by hand. You still make every judgment call. The system just makes sure you are making it with this week's information instead of last week's. --- ## `01-startup-step.md` (The startup step) The first thing that runs, before any work begins. Its only job is to load what is true right now, so you never open a session by re-explaining it yourself. --- ### What it loads | Loads | Why | |---|---| | What is live right now | The projects and tasks actually in motion, not the full history | | Open loops | Anything waiting on a decision or a reply | | Key dates | Dates that should change what happens next | | Standing corrections | The small set of rules that apply no matter what the session is about | ### What it should not do Load everything. A startup step that reads your whole archive on every session is slow, and it dilutes the two or three things that actually matter this week with everything that does not. ### How to build it 1. Write the one file this step always reads: current state, open loops, key dates, standing corrections. Keep it short enough that you would actually read the whole thing yourself. 2. Point your tool's startup setting at that one file, nothing else. Most chat tools, project tools, and agent platforms have some version of this: a system prompt, a project instruction, a session hook. 3. Keep the file current. A startup step is only as good as what it loads, and a stale current-state file is worse than none, because it is confidently wrong instead of just missing. ### A real example My setup starts every session the same way: it reads what is live, what is open, and the handful of standing rules that apply regardless of the task, before anything else happens. A recent one: it caught a newsletter post I still had marked as staged, twenty-five days after it had actually gone out, because reconciling the board is part of what runs at the start of a session. I did not have to notice the mismatch myself. The file was current and the step ran first. --- ## `02-capture-routine.md` (The capture routine) One scheduled job that pulls context from where it actually happens, email, chat, and meetings, into the project it belongs to. Without this, every piece of context that is not a file you deliberately wrote stays wherever it landed, and you become the thing that connects it back to the work. --- ### What it does 1. Runs on a schedule, not on request. Daily is enough for most projects. 2. Reads the sources you have decided matter: a specific inbox, a specific chat channel, a calendar of meetings. One routine can cover more than one source. 3. Decides which project each piece of context belongs to. 4. Writes it into that project in a form you can read later: a short note with a date and a source, not a dump of the raw message. 5. Leaves nothing behind that needs you to go find it. If it is worth capturing, it is worth filing in the one place you would actually look. ### What it should not do - Decide what matters and silently drop the rest. Flag anything it is unsure about instead of deciding for you. - Capture everything from every source into one undifferentiated pile. A capture routine that cannot tell which project something belongs to just moves the sorting problem to later instead of saving you work. ### Scoping it to start Pick one project and one source first. A single routine that reliably catches the emails relevant to one project is worth more than a system that is supposed to watch everything and actually watches nothing well. Add sources and projects once the first one is boring, meaning it runs and you stop checking whether it worked. ### A real example My own setup runs a scheduled sweep that files raw captures, a dictated note, a dropped file, a session transcript, into the project it belongs to, so context keeps accumulating while I am doing other things instead of piling up somewhere I have to remember to check. The habit it replaced was reconstructing a decision from scattered notes because nothing had filed it anywhere findable. Now the sweep files it, and the next session can find it without me doing the filing. --- ## `03-corrections-loop.md` (The corrections loop) A corrections file by itself still depends on you remembering to update it. A corrections loop is the step that closes that gap: at the end of a session, something files what you corrected, and a review step turns the patterns into rules once you approve them. --- ### How it runs 1. At the end of a session, or on a schedule if sessions do not have a clean end, capture what you corrected: a rewrite, a rejected draft, a piece of feedback you gave more than once. 2. Ask the same question every time: was this a one-off, or does it generalize. Log the one-off. Write the generalizable one as a rule. 3. Append new rules to your standards or corrections file. Do not silently edit the file yourself from memory of what you think you said; let the actual correction speak for itself, dated, in your words. 4. Periodically review the log for anything that shows up more than twice without becoming a rule. That is a sign the rule exists but is not loading where it needs to. ### Why this has to be a loop, not a note A correction you make once and never revisit is a correction you will make again next month, on a different draft, from a different person, and it will feel new again. The loop stops that: once a correction is logged and reviewed into a rule, it applies without you repeating yourself. ### A real example My own setup runs this at the end of most sessions: what got corrected, and does it generalize. One real entry: after a draft came back "way too long," a standing rule was proposed to default feedback replies to short. It got rejected on review, because length actually depends on the content and what it is replying to, not a fixed target. That is a useful entry too, logged as a correction that did not become a rule, so the next session does not re-litigate it or over-apply a fix that was never meant to be universal. --- ## `04-stale-context-prompts.md` (Stale-context prompts) Two kinds of staleness cost you the same way: a draft that sounds confident and is wrong. This piece catches both before they reach you, instead of after. --- ### The two triggers **Age.** A session, pane, or conversation that has been open longer than a day without a refresh is working from context that may no longer be current. Set the threshold to whatever fits how fast your work actually changes. A day is a reasonable default for anything with daily moving parts. **Size.** A session that has grown past a size limit you set is carrying more history than it needs, and every turn after that point re-sends all of it. Pick a limit for your tool and treat crossing it as a prompt to refresh, not a warning to ignore. ### What the prompt should do - Tell you plainly: this pane is old, or this session is large, refresh before continuing. - Not refresh automatically without telling you. You decide when a clean break is worth losing whatever is still useful in the current thread. - Point at where the current state lives, so refreshing is a genuine restart from the startup step, not a blank window. ### Why this is worth automating Nobody checks the age of their own chat window by habit. The cost of a stale session is invisible until the output is subtly wrong, and by then you have already spent the time reading it. A prompt that fires on its own catches this because it does not depend on you remembering to ask. ### What to set the thresholds to A pane open more than a day, or a session that has grown past a size threshold, is worth a pop-up that says refresh and clear context. The real fix is a hard limit on how long a session is allowed to run, so cost from stale context never gets the chance to compound. --- ## For your AI agent If your user pasted this whole file and asked you to set it up, do this: 1. Confirm the user already has a current-state file and a corrections file (from The Files-First Starter Kit or equivalent). If not, point them there first; this kit builds on those. 2. Build the startup step first: whatever your platform supports (a system prompt, a project instruction, a session hook) that loads current state, open loops, key dates, and standing corrections before any work begins. 3. Build the capture routine next, scoped to one source and one project to start. Ask the user which inbox, chat channel, or meeting source matters most, and which project it belongs to. 4. Build the corrections loop: a step at the end of a session that asks what was corrected and appends generalizable rules to the corrections file. 5. Add stale-context prompts last. Ask the user what age threshold and size limit fit their tool, and set up a prompt, not a silent auto-refresh. 6. Test each piece against a real session before calling it done. A piece that has never caught a real stale pane or a real missed correction has not been verified.