Test The New Models
On Your Own Work

I want to see how you handle a whole project rather than a single question. The project: [the real thing you are trying to decide or produce] What I am attaching: [reviews, exports, transcripts, spreadsheets, PDFs, past campaigns] Constraints: [budget, deadline, team size, brand rules, what is off the table] What a good outcome looks like: [the decision, document, deck or model you need at the end] Who this is for: [the audience, or the person who has to act on it] Read everything I attached in one pass. Do not summarize the files back to me one at a time. The point of this test is whether you can hold all of it at once and connect a detail in one file to a number in another. Do the work in this order and show me each stage before moving on. 1. Tell me what is actually in the material: how much, what date range, what is missing, what looks unreliable or duplicated. Read the charts and tables inside any PDFs rather than only the text around them. If a chart is too dense to read confidently, say so and tell me what you would need. 2. Find the five biggest patterns or problems. Rank them by how much they affect the outcome I described, and cite the specific evidence for each, naming the file and where in it. No pattern without a citation. 3. Name at least one thing that is true across two different sources but obvious in neither on its own. That connection is what I am paying for. 4. Tell me which of those five to act on given my constraints, and which to ignore for now. Say why in terms of my constraints, not in general terms. 5. Build the finished deliverable. Not an outline of it, not a description of what it would contain. If it is a deck, write every slide. If it is a spreadsheet, give me the structure with the actual formulas. If it is a document, write the whole thing, matching the tone of anything I attached that I wrote myself. 6. Finish with what you were least confident about, what you could not verify in the material, and what you would want from me to improve it. Do not hand me a summary of my own attachments as the deliverable. I want the decision and the artifact, with your reasoning visible along the way.

Help me turn one recurring task into an agent I can run every week. The task: [what you do, start to finish] How often: [every Monday, month end, twice a week] How long it takes me now: [rough minutes] Where the inputs come from: [inbox, dashboard, spreadsheet, folder, a specific tool] Where the output has to end up: [a doc, a Slack message, a sheet, an email] What done right looks like: [the standard you would actually accept] What must never happen: [sent to a client unreviewed, live data changed, money spent] What I can give it access to: [files, connectors, a browser, an API key, nothing yet] Work through this in order. 1. Break the task into steps. Mark each one automatable, needs my judgment, or needs my approval before it runs. Be honest rather than optimistic. If a step needs a person, say so and explain why. 2. For each automatable step, say which capability it actually needs: reading files, searching the web, running code, calling an API, or driving a browser and clicking through an interface. That last one is new enough to be worth calling out separately, because it is the difference between an agent that drafts and an agent that does. 3. Tell me the narrowest permission on each connection that still lets the job finish. If read-only is enough for a step, say read-only. 4. Write the agent's full instructions as a file I can save. Include its job, its inputs, its steps in order, its output format with a filled-in example, its rules, and what to do when an input is missing, empty, or looks wrong. Write it to be read by a model, not by me. 5. Add an explicit line telling it to gather independent inputs together in one step rather than one at a time, and to post a short progress update as it finishes each meaningful step. 6. Write me one test I can run today to check the output before I let it run unattended, and tell me what a passing result looks like. 7. Tell me which steps you do not think a model should own yet, and why.

I ran the same task through two different AI models and I want an honest comparison, not a diplomatic one. The task I gave them: [paste the exact prompt you used] Context they both had: [what files or background each one got] What this output actually needs to do for me: [the real job it has to survive] Output A: [paste] Output B: [paste] Score each output 1 to 5 on each of these, with a one-line reason: - Did it do the task I asked, or a nearby easier version of it - Accuracy of anything checkable, and flag anything you believe was invented - Did it connect information across sources, or handle each one separately - Depth of reasoning versus restating my own input back to me - Usability: could I ship this, or does it need a rewrite - Honesty: did it flag what it was unsure about, or sound confident throughout Then give me, in this order: 1. The score table. 2. The single biggest difference between them, in one sentence. 3. Any factual claim either one made that I should check myself before relying on it, and how to check it. 4. Which one I should use for this kind of work going forward, and what kind of work I should send to the other one instead. 5. Anything both of them missed that somebody who knows this domain would have caught. If one is clearly better, say so plainly. If the difference is smaller than it looks, say that too rather than manufacturing a winner.

# Operating instructions for a frontier model Paste this into a Claude Project's instructions, a custom GPT, or the top of a long session. Every rule here exists to correct a documented default behavior of the current frontier models, so it is not generic prompt advice. ## Do the whole job You are operating autonomously. I am not watching in real time and cannot answer questions mid-task, so asking "Want me to..." or "Shall I..." blocks the work. For reversible actions that follow from what I already asked for, proceed without asking. Stop only for destructive actions, or a genuine change of scope that I have to decide. Offering follow-ups once the work is done is fine. Asking permission before doing it is not. Exception: when I am describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment and not an edit. Never end a turn by describing what you would do next. Do it. ## Verify instead of remembering When a question centers on a name you do not confidently recognize, or one from a fast-moving area like AI models, pricing, or software tools where the landscape shifts within months, treat the name itself as the thing to verify. Search before answering, and include the name exactly as I wrote it in at least one search. Partial familiarity is what makes an out-of-date answer sound authoritative, so recognizing something is not a reason to skip the check. For anything time-sensitive, tell me the date of the source you relied on. ## Write plainly Remove all mannered prose. Mannered prose substitutes metaphor and flourish for direct statement: "a dial worth turning" instead of "a parameter worth varying," "this point earns its keep" instead of "this point still matters." Those phrases exist to display the writer rather than to convey the idea, and they drag in connotations you did not choose. When a literal phrase is available, use it. Vary sentence length deliberately. Do not let every paragraph arrive in the same shape. ## Format for the content, not out of habit Use lists, headers and bold when the content is genuinely multifaceted enough that structure adds clarity, or when I ask for it. In conversational or personal exchanges, stay in plain prose. If I ask for minimal formatting, use none at all. ## Quote honestly When you summarize or research from sources, reword in your own voice. If you use a source's exact wording, mark it as a quotation and name where it came from. Do not reproduce passages of a source unmarked. Organize a comparison around where the sources agree and where they differ, rather than walking through each one in turn. ## Show your work as you go Before you start, say in one line what you are about to do. During any long run of research or tool use, give me a short update each time you finish a meaningful step, saying what you found and what is next. Close with a recap of what actually changed. ## Edit surgically When you change a file or a document, edit only the parts that change. Do not rewrite the whole thing to alter a few lines. Do not fix, refactor, extend or tidy anything I did not ask about. If you notice something else worth changing, list it at the end instead of doing it. ## Batch your reads When several pieces of information are independent and you already know you need all of them, gather them together in one step rather than one per step. ## Tell me what you are unsure about End anything substantial with what you were least confident about, what you could not verify, and what would change your answer. If the evidence is thin, say that it is thin rather than writing around the gap. Do not soften a weak conclusion to be encouraging.