My actual taste file

Yesterday I wrote that I keep my taste in a file the AI reads. Since then, one question has come back more than any other, in the comments and in DMs: can I see it?

Here it is. The real file, lightly cleaned of internal project names. This is what sits behind everything I've shipped this year: the rebuilt portfolio, the app that runs my writing pipeline, the tools that ran my job search. Every one of them started from these lines.

What this is not: a template. If you copy it, you'll get my products, not yours. The useful part is the shape of it, and how it got written. Both below.

The file

Three modes, a handful of rules under each, one page. Scroll through the full text right here. The copy on GitHub annotates every rule with the reasoning behind it.

# taste.md

Read this before writing any UI. These are my defaults.
When they conflict with a library default, mine win.

## Pick a mode by product type

Taste is not one look. Pick the mode first, then apply it
without mixing.

Mode A: minimal tool. Dashboards, admin, internal tools,
reports. The default.
Mode B: juicy consumer. Games and playful consumer apps.
The deliberate opposite of A.
Mode C: editorial brand. Portfolio, blog, marketing. A quiet
reading base with expressive brand moments.

## Mode A: minimal tool (the default)

- Light mode by default. Dark is a toggle, never the opener.
- No drop shadows. Separate elements with hairline borders
  and tonal layering. One exception: a soft shadow on a true
  floating layer, like a modal.
- Declutter aggressively. One rich table beats a page of
  stat tiles. If I don't look at a widget, cut it.
- Progressive disclosure over density. Show the essentials,
  collapse everything else behind a tap or a hover.
- This applies to documents too. Organize a report around
  the reader's questions, answer visible, evidence collapsed.
- Strong typography. Tight type scale, hierarchy from weight
  and spacing, tabular numerals for anything with figures.
- Time reads as days, not dates. "7d ago", never "July 21".

## Mode B: juicy consumer

- Dark, saturated, tactile. Shadows, motion, haptics and
  sound are features here, not clutter.
- An expressive display font. Buttons that feel pressable.

## Mode C: editorial brand

- Quiet where you read, expressive at the brand moments.
- A refined minimal base with juice layered on top. One
  gradient wordmark, one shader moment, subtle sound.

## All modes

- Clear hierarchy, deliberate typography, no clutter.
- Self-hosted variable fonts, never a font CDN.
- Every product forks its theme from one shared base, so
  they share DNA without looking identical.
- Always ship a reduced motion and mute opt-out.

Every line is a correction I got tired of repeating

Nothing in this file came from a design book. Every line is something I said to an agent, or to myself, more than twice.

"No drop shadows" is there because I kept getting card grids with soft shadows on every edge, and I find that dated. I corrected it on three projects in a row before I wrote it down. "One rich table beats a page of stat tiles" is a sentence I actually said while reviewing a dashboard that had seven charts I never looked at. The progressive disclosure line exists because a tool once showed me seven score bars per row and I couldn't read any of them.

That's the test for what earns a line: not "do I believe this," but "have I corrected this specific thing more than twice." A principle you admire but never enforce doesn't belong in the file. It's noise the agent will misapply.

Taste is a mode, not a look

The part of the file that does the most work is the top: pick a mode by product type.

My dashboards are light, quiet, and hairline-thin. The game I shipped this summer is dark, loud, and every button has a fat pressable shadow. Both are my taste. If the file only described one look, every product would come out wearing the same outfit, and half of them would be wrong.

Here are three things I built, in three modes, from the same file.

Same person, same file, same workflow. Three different outfits, picked on purpose.

This is the difference between a taste file and a brand guideline. A brand guideline makes everything match. A taste file makes everything judged. The judgment "this is a playful consumer app, so shadows are a feature here" is as much my taste as the shadows themselves.

What the file actually changes

The mechanics are boring on purpose. The file lives in the repo. The agent reads it before writing UI, the same way it reads the conventions doc before writing code.

The effect is not that the output gets good. The effect is that the output starts from my defaults instead of the model's. Models have taste defaults, and they're nobody's: dark hero sections, gradient buttons, shadows everywhere, a stat tile row on every dashboard. Without the file, I spend the first three rounds of review removing those. With the file, round one already looks like mine, and review time goes to the decisions that matter.

Where the file stops working

The honest part. The file captures taste. It does not generate it.

The agent applies the letter, not the eye. It will hairline everything, including the one place a shadow was right. It will collapse detail that should have stayed visible. The file gets it to my defaults; my eyes in the browser get it to done. I have never shipped a screen I didn't look at, and the file hasn't changed that.

It also drifts. Twice now I've deleted lines that stopped being true. A taste file you never prune becomes a brand guideline for who you used to be.

If you're writing yours

Don't start from principles. Start from your last ten corrections. Open your recent projects, find the things you changed after the first AI pass, and write down the ones that showed up more than twice. That list is your actual taste. The principles you'd have written from scratch are the taste you wish you had.

Write the why next to the what. "No shadows" is a rule. "Separation comes from hairlines and tone, not shadows" is a rule an agent can extend to cases you didn't list.

And keep it to one page. One file, read in full, every session. The moment it needs a table of contents, it's documentation, and nobody reads documentation. Including the agent.

Get the file

It's on GitHub, free, in a repo I'm using to publish the files my agents read: github.com/MahdiF/agent-files. That version annotates every rule with the reason behind it, which is the part worth stealing. More files will land there as I clean them up.

People keep asking whether publishing this means anyone can copy my taste. They can copy the file. The file is the output of years of corrections; copying it skips the part where it becomes yours. Taste was never the secret. Applying it on every screen, every session, without getting tired, was. That's the part the file automates.