Add theming (WIP)

[whanou]

Still in WIP, need to have a clear look at this before proceeding further.

Adding new theme

Let's say we want to add new theme. For us it means that we need to:

1. Create new file in src/themes and fill it with tokens (i used colors from tailwind for 2 existing themes) (AgentPrismTheme interface)
2. Reexport it from index file
3. Update build-theme-files.ts and run it to generate css files for theme

Consuming themes in the app

1. Import agentPrismTailwindColors and use it in tailwind config so that tailwind will proceed the classes
2. Import or copy content of generated theme (e.g. default.css) and add it to your index.css - we need this so that some theme will be defined by default
3. If you want to change theme - import setTheme and required theme object, and call setTheme(selectedTheme)

Reasoning

• Why such convoluted process? - I wanted to reach 2 main goals - easy support of light/dark theme and ability to change themes on the fly. It requires some extra steps
• Why not just define variables in css file and export it? We need to have both css file (for initial values of the tokens) and ability to change themes, so we need basically 2 "declarations" of theme - as theme object and as generated variables (and their values)
• Why define colors as a b c instead of rgb() or oklch()? - We need this to support opacity syntax

@mikhin what do you think about this? It looks a bit complex, and i will think of a way to bring complexity down

[mikhin]

Why such convoluted process? - I wanted to reach 2 main goals - easy support of light/dark theme and ability to change themes on the fly. It requires some extra steps

Hey! I think we might be solving for a different use case than what our clients need.

From what we understand, most clients (like 99%) will want to:

• Set their brand colors once at build time
• Have light/dark mode work automatically
• Let their host app handle any additional theme features

Since AgentPrism gets embedded into existing apps, the host app is usually responsible for things like theme switchers. So runtime theme switching (beyond dark mode) might not be something clients actually need.

I went back to the Linear task to check what we originally scoped:

Key requirements were:

• Embedded in host apps (primary use case)
• Build-time customization for brand matching
• Dark mode support (runtime)

The expected user flow looked like:

/* Client's app.css - set brand colors once */
:root {
  --agent-primary: 59 130 246;
  --agent-bg: 255 255 255;
}
.dark {
  --agent-primary: 96 165 250;
  --agent-bg: 17 24 39;
}

Just CSS vars defined at build time. Dark mode works via the host app's existing .dark class handling.

[mikhin]

simplifying to focus on build-time CSS var customization

[mikhin]

for text it should be foreground?

[whanou]

Oh, forgot to comment on this - this is not an actual code yet, just a place to test things to see if they work (they do). I'll update this in accordance with a design soon

[mikhin]

Note on all runtime utility functions:

The setTheme(), createTheme(), and theme generation scripts look well-implemented, but I assume these won't be in the final version since they're not relevant to the build-time customization goal from the task.

[whanou]

Initially i was trying to kill 2 birds with one stone - both for "static" theming and runtime switching. After reading your comments and giving it a second thought - i agree, we should proceed with the flow which will suit 99% of users, while being reasonably simpler. I'll update the logic soon