Setting Up Bloomineasy, Part Two: Add DESIGN.md and Run the Design Pass
Use DESIGN.md, reference URLs, screenshots, and assets to turn a verified Bloomineasy install into a site with a clear visual direction.
After the vanilla install is working, use a DESIGN.md-driven prompt to customize the public theme, homepage, navigation, article cards, widgets, logo, and content surfaces without destabilizing the CMS.
Use DESIGN.md, reference URLs, screenshots, and assets to turn a verified Bloomineasy install into a site with a clear visual direction.
After the vanilla install is working, use a DESIGN.md-driven prompt to customize the public theme, homepage, navigation, article cards, widgets, logo, and content surfaces without destabilizing the CMS.
Use this after Part One is verified
The design pass should not start while installation is still unresolved. First complete the vanilla setup, sign in as the first admin, confirm starter content is present if you seeded it, and make sure the public site and admin both run.
Then the job changes. The agent is no longer installing Bloomineasy. It is applying a design source of truth to the public site while preserving the CMS behavior that already works.
Why DESIGN.md comes before component edits
`DESIGN.md` gives the agent a shared brief: what the site should feel like, what visual decisions are intentional, what assets matter, and what should stay out of scope. Without that file, design work often becomes a string of isolated color and layout changes.
A useful `DESIGN.md` does not need to be huge. It should give enough direction for typography, color, spacing, brand voice, homepage priorities, article presentation, imagery, and non-goals.
Useful DESIGN.md ingredients
- Audience and site purpose
- Brand adjectives and anti-adjectives
- Type direction and readability rules
- Color direction, contrast needs, and accent behavior
- Homepage structure and priority content
- Article card, article page, and listing expectations
- Asset rules for logos, favicons, photography, or generated images
- What must not change, especially auth, admin, routing, SEO, widgets, and API behaviorThe second prompt: DESIGN.md customization pass
Paste this prompt after the first setup is working and after `DESIGN.md` exists or is ready to share. It deliberately asks for intake one question at a time because design inputs are often scattered across files, screenshots, URLs, and brand assets.
The prompt also tells the agent to summarize before editing. That gives the project owner a chance to catch wrong assumptions before the public site is changed.
DESIGN.md customization prompt
You are customizing a verified Bloomineasy install using DESIGN.md.
The app is already installed and running. Do not redo installation, auth setup, Convex setup, Vercel setup, schema setup, or deployment setup unless I explicitly ask.
Your first job is intake. Ask one question at a time, then stop and wait for my answer before asking the next question.
Question sequence:
1. Ask: Where is the DESIGN.md file I should use? If it is already in the project, ask me for the path.
2. After I answer, ask: Do you have any reference URLs I should inspect? Ask for exact page URLs and whether each is "must match" or "inspiration only."
3. After I answer, ask: Do you have screenshots, screen grabs, logos, favicons, product images, or brand assets to use? Ask me to attach them or provide project file paths.
4. After I answer, ask: Should the design apply to the public site only, or also to the admin? Recommend "public site only."
5. After I answer, ask: Should the result be a close visual match, an inspired-by adaptation, or just a token/theme pass? Recommend "inspired-by adaptation."
After intake is complete, read:
- AGENTS.md
- README.md customization section
- the provided DESIGN.md
- any supplied local assets
- any supplied reference URLs/screenshots
- any supplied screenshots/assets or brand files
Use this priority order:
1. DESIGN.md as the source of truth.
2. Supplied brand assets.
3. Supplied screenshots.
4. Supplied URLs.
5. Existing Bloomineasy structure and components.
If references conflict with DESIGN.md, stop and summarize the conflict before editing.
Goal:
Apply DESIGN.md to the public-facing site so this clone feels like my project, not the default Bloomineasy demo.
Implementation targets:
- Update public theme tokens in `app/(public)/globals-public.css`.
- Update `app/(admin)/preview-theme.css` so widget previews match the public theme.
- Update public components in `components/public/`, especially nav, footer, hero, article cards, homepage sections, CTAs, and hard-coded demo copy.
- Replace or adapt `components/logo.tsx` and static assets if logo or brand asset guidance is provided.
- Keep `/admin/settings` compatible; tell me which site settings I should set manually.
Constraints:
- Keep Better Auth + Convex unchanged.
- Do not add Clerk, public sign-up, or auth providers.
- Keep admin styling stable unless I explicitly ask to redesign admin.
- Preserve article publishing, taxonomy routes, widgets, SEO metadata, sitemap, API ingestion, legal pages, and admin workflows.
- Do not remove privacy, terms, complaints, contact, blog, or article routes.
- Do not turn the site into a marketing-only landing page; keep it useful as a content/CMS site.
Before editing, summarize:
- What DESIGN.md says in 5-8 bullets.
- What maps to theme tokens.
- What maps to component/layout changes.
- What maps to content/settings changes.
After editing:
- Run relevant tests, or at minimum `bun run lint` plus any focused public/theme tests available.
- Start or use the dev server on port 5992.
- Check homepage, blog listing, article page, contact page, and widget preview.
- Report exactly what changed and anything that could not be applied cleanly.What should change and what should stay stable
The design pass should touch public theme tokens, the homepage, navigation, footer, article cards, article pages, CTAs, widget preview theme, logo treatment, and hard-coded public demo copy where needed.
It should not casually rewrite auth, Convex schema, admin workflows, taxonomy routing, article publishing, API ingestion, legal routes, sitemap behavior, or the widget system. Those are product foundations, not mood-board material.
Read Part Three next
After the design pass, the next prompts should become more ambitious. Part Three shows how to prompt for creative direction, taxonomy, homepage strategy, article clusters, widgets, and critique passes without turning Bloomineasy into a generic landing page.
