You ask AI to help you think through a design, and it starts building before you’ve agreed on the direction. You explain that you want feedback on the problem, and it comes back with a finished solution. After enough of these conversations, you’re spending a lot of time explaining how to work with you.
I kept running into this, so I started building my own AI design assistant around the way I actually design: how I critique work, how I explore ideas, and when I want a conversation before anything gets built. I think of it as giving a junior designer the context they would need to collaborate with me.
At The Design Project, we’ve been exploring how shared product knowledge helps people and agents work together. This adds the personal part: the methods and experience you bring to each project. Here’s how I set mine up, what I chose to save, and the check that caught a gap before I started using it.
Table of contents
- What is a personal AI design assistant?
- How your personal brain fits with company and feature context
- How to build your AI design assistant
- Connect your personal instructions to Claude Code or Codex
- Test whether your assistant is actually using your preferences
- Keep your AI design workflow learning from corrections
What is a personal AI design assistant?
A personal AI design assistant is an AI tool configured with your critique methods, collaboration preferences, references, and reusable lessons. It reads those instructions alongside the product’s requirements, so it can give feedback and explore directions in a way that fits how you work. You still make the design decisions.
I call those saved instructions my personal brain. They describe things like whether I want the agent to identify a problem or suggest a solution, how much reasoning I want to see, and where it should pause for my input.
For example, I usually want to agree on an approach before the agent starts designing. Someone else might prefer a quick draft they can react to. Both are useful ways to work, and the assistant needs to know which one you expect.
You can set this up with editable Markdown files and an agent that can read them. I created a setup skill for building your AI design assistant to make the questions easier to work through, but you can also answer them yourself. The skill guides the setup; your answers become the personal instructions you keep using.
How your personal brain fits with company and feature context
Your personal brain describes how to collaborate with you. The company brain explains the product and its rules, while the feature brain contains the requirements for the task you’re working on. The agent needs those sources together, with your preferences applied within the company’s constraints.
Think about joining a product team. You learn who the customers are and how the company operates. When you pick up a ticket, you learn what that particular feature needs to do. You also bring your own experience, critique methods, and way of working into the room.
| Context | What belongs there | Example |
|---|---|---|
| Company brain | Product purpose, users, business rules, and shared standards | This invitation flow must follow our permission rules. |
| Feature brain | Requirements and decisions for the current task | This invitation needs an expiration date. |
| Personal brain | Your critique methods and collaboration preferences | Show me the tradeoffs before implementing. |
That distinction helps you decide where a correction belongs. A permission issue should update the relevant product guidance. A preference about how options are presented belongs in your personal instructions. Your preference for a particular visual style still has to fit the company’s design system and audience.
Our guide to context engineering and the product brain covers the shared knowledge in more detail. For this setup, I wanted to capture the part I could bring with me across projects.
How to build your AI design assistant
Start by documenting four areas: your critique methods, how you work with AI, optional visual references, and how lessons should be saved. Review the resulting files, connect them to your agent, and try them in a fresh conversation before relying on the setup for design work.
The sequence looks like this:
- Describe how you critique a design.
- Define how AI should collaborate with you.
- Add references that explain your visual taste, if useful.
- Decide how reusable lessons should be saved.
- Review the files and connect them to a real project.
1. Describe your design critique methods
Start with what you want to understand when you review a design. Do you look at the problem first, follow the user’s journey, or begin with the execution? The order matters because it tells the assistant where to focus its attention.
For me, the problem comes first: does this approach support the user’s goal and the product’s purpose? Then I look at whether someone can understand and use it successfully, followed by the visual execution. I prefer structured checks, and I ranked my priorities as clarity, consistency, error prevention and recovery, then simplicity.
That ranking reflects how I think. I want someone opening the product to understand what to do and how to do it. If that understanding is missing, polishing the typography won’t resolve the main concern.
Also describe what you want the critique to produce. I like direct feedback and a short priority list, with room to ask for more detail. I often want the agent to identify the problem and leave me space to work through the solution.
Here’s an adapted instruction based on my answers:
When reviewing a design, start with the user’s goal and the problem being solved. Prioritize clarity, consistency, error prevention and recovery, then simplicity. Name the concern and explain its likely effect. Give me a short priority list, and leave room for me to explore the solution unless I ask for recommendations.
2. Define how AI should collaborate with you
Write down the decisions you keep having to repeat in chat. Should the agent explain its approach before creating something? When information is missing, should it ask questions? Do you want one recommendation or several directions with tradeoffs?
My preference is to discuss the approach before building. I want focused questions when information is missing and a concise explanation first, with more reasoning available when I ask. During exploration, I like a few clearly different directions, including ideas I haven’t considered.
That is one of the most useful things AI can do for me. It can explore references and possibilities beyond the first direction in my head. I want to participate in choosing the direction before it turns into a screen full of decisions I never made.
For your own setup, capture at least these three things:
- What the agent should explain before it starts creating.
- How it should present alternatives and challenge assumptions.
- Which decisions require your input before it continues.
Make the instructions concrete enough to recognize in a real task. “Explain the approach and wait for my input before implementation” is easier to check than “collaborate thoughtfully.”
3. Add visual references when they help
References are optional. You can include products you admire, work you’re proud of, or examples that show your preferences for hierarchy, density, typography, and interaction. Explain what you like about each reference so the assistant has something more useful than a folder of screenshots.
I skipped this section in my setup because I was working inside an established company design system. The critique and collaboration preferences were more immediately useful there. For personal projects or work across different products, I can see references becoming a bigger part of the brain.
Keep the scope clear: references help the agent understand your taste, while the project’s users, accessibility needs, and approved components still guide the design. Personal preferences should fit those requirements.
4. Choose how lessons become personal instructions
Decide whether the assistant should save clear lessons as you work, suggest updates for review, or wait until you explicitly ask. I chose to update my preferences as we work because I want the repeated corrections to become useful context for the next task.
There’s an important judgment call here. If I say, “Skip the explanation for this quick experiment,” I’m making an exception for that task. My usual preference to discuss the approach still applies afterward.
When a correction could mean either a temporary exception or a broader preference, I want the agent to ask which one I mean. That keeps a rushed instruction from quietly changing how every future project works.
5. Review what the assistant saved
Read the resulting files before using them. My setup produced a README and separate files for critique methods, working preferences, references, and lessons. The references and lessons could grow later; the initial value came from capturing how I wanted the agent to work with me.
If you’ve already spent time in a project, you can ask the agent to propose reusable lessons from your conversations. Review those proposals yourself. A correction about one component or customer should stay with that project unless it reflects a broader working preference.
Connect your personal instructions to Claude Code or Codex
Saving the files is only part of the setup. Your agent needs a reliable instruction telling it where those files live and when to read them. Keep personal preferences separate from shared team instructions so your way of working doesn’t accidentally become everyone else’s default.
In Claude Code, you can use user-level instructions for preferences across projects, or a local project file for preferences specific to one repository. Claude Code’s memory documentation describes ~/.claude/CLAUDE.md, CLAUDE.local.md, and imports. Keep the local file out of shared source control, and check how it reaches any new worktrees or workspaces you create.
For Codex, the AGENTS.md documentation explains global instructions in ~/.codex/AGENTS.md and project-level guidance. Use the personal configuration to tell the agent where to find your saved preferences, then verify that it reads them alongside the project’s instructions.
These tools have different loading rules, so confirm the setup in each one you use. An instruction file that works in one agent doesn’t automatically configure another. In my setup, I checked both Claude Code and Codex and also looked at how Conductor carried local instructions into new workspaces.
The same idea applies to the repeatable tasks you package as agent skills: the agent needs to find the relevant instructions at the point it does the work.
Test whether your assistant is actually using your preferences
Start a fresh conversation in the project and ask the agent to summarize your working preferences before you give it a design task. Compare its answer with the saved files, then check whether its behavior follows those instructions during a small piece of work.
This check mattered in my setup. I had saved my personal brain, but I still had to tell the agent to read it. Once it summarized the preferences, I asked it to make sure the instructions would be picked up in future conversations too.
Try this adapted prompt:
Before we start, identify the personal instruction files you’ve read. Summarize my critique priorities, how you should present alternatives, when you should pause for my input, and how corrections should be saved. Explain how these preferences fit with this project’s rules and feature requirements.
Then try a small critique or exploration. If your preference is to discuss the problem first, the agent should do that before proposing a finished redesign. If you want several directions with tradeoffs, check that the options are meaningfully different.
A correct summary is a useful first check. Following the preferences during the task is the next one. Repeat the check when you switch tools or start in a new workspace.
Keep your AI design workflow learning from corrections
Your personal brain becomes more useful when repeated corrections turn into clear, reusable instructions. Keep reviewing what gets saved, remove guidance that no longer fits, and leave product-specific requirements in the company or feature context where they belong.
Here, learning means updating the files the agent can read in later sessions. You still need to check that it loads the right context and applies it appropriately. Anthropic’s guide to effective context engineering describes why curating the information available to an agent matters, including keeping that context focused and useful.
The part I’m most interested in is how this changes the conversation. I can spend more time deciding whether an approach makes sense and less time repeating that I wanted to discuss it before anything was built. There’s still plenty to refine, but the working relationship has a clearer starting point.
If you want to try the same setup, build your AI design assistant with TDP’s setup skill. Start with the correction you keep making, then check whether the next conversation actually changes.
Related reading
- Context engineering: build a product brain for your AI workflow
- AI product development workflow: Give your team a product brain
- Agent skills: stop re-teaching AI your design system
