Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryoutcomes and systems / 2026-08-04

Context Is King

How I approach a problem: define the outcome, hold the system, and pack context before you touch the prompt.

6 parts / Hover to explore. Click to read.

How I approach a problem: define the outcome, hold the system, and pack context before you touch the prompt.

Recognisable result
         +
References + constraints
         +
Saved decisions + current files
         |
       model work
         |
Check against the intended result
Define what counts as done, then give the work useful context and somewhere durable to live. More text is not a substitute for the reference or decision that changes the answer.

So, you've asked Claude to build something. It has made something. It just isn't the thing you had in your head.

Before you try another prompt, look at what Claude actually had to work with. Did it know who this was for? Had it seen an example you liked? Could it tell what was already decided?

Those are the questions I start with. There are two parts to the answer: define the result, then give the work a system it can live in.

First, say what would count as done

“Build a landing page” gives you a page. It doesn't tell you whether the page helps the right person do the right thing.

You need something you can check. What has to exist? What will you look at or try? What would make you send it back?

That includes taste. If the writing sounds wrong, the page is wrong. If the button looks lovely and goes nowhere, it is also wrong. A model doesn't get to declare success because it has produced a convincing screenshot.

Write those conditions before the work starts. Someone else should be able to use them to judge the result without having to borrow your brain.

Then, give the work somewhere to live

The next question is how this will work beyond one conversation.

What goes in? Where do decisions get saved? How will you notice a mistake? Who gets to say it's ready?

I want those answers in the workspace. The brief, the useful references, the files we already have, and the things we've agreed. A new session should be able to pick up the work without making me explain the whole project again.

Chat can help you think. Files carry the decisions forward. Use both for the jobs they're good at.

Bring the context that changes the answer

Context is the material that helps the model make the right choice: your examples, constraints, previous decisions, and the details of the actual project.

A clever prompt cannot replace a missing reference. Equally, pasting a hundred pages into the chat won't help if nobody knows which page matters.

Start with what would change the answer. Give it that. Then add what it needs to act on it.

You can swap models. You can rewrite a prompt in a minute. The useful work is building up a project that still makes sense when you do either.

How to use this part of the library

These essays are about how I approach a problem. Pick the one that matches where you're stuck, follow a link, and come back when you need it.

If you want to practise building a product in order, take Define outcomes, then build digital products. The course gives you a sequence to work through. This part of the library gives you ideas you can use across that work.

You'll find specific recipes under workflows, working rules under doctrines, and day-to-day habits under discipline and process.

Pick the next useful question

Get those things clear, and you won't need the prompt to do quite so much heavy lifting.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 8