Files
monie-landing/AGENTS.md
Denis Krylov 49b976c53f
Some checks failed
Deploy monie-landing (kaniko) / build-and-deploy (push) Failing after 9m46s
chore: initialize project
2026-04-04 22:13:10 +03:00

500 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AGENTS.md
## Project
Monie Landing — marketing website for a product for individual service masters.
This is not a salon CRM.
This is not an enterprise business automation system.
This is not a dashboard-first product.
The product is built for independent masters:
- nail artists
- barbers
- brow artists
- lash makers
- cosmetologists
- massage specialists
- other solo beauty/service professionals
The landing page must present Monie as a simple, modern tool that helps one master manage bookings, clients, and income without complexity.
---
## Core product idea
Monie is a personal business page for a master.
It combines:
- personal profile
- services and prices
- online booking
- simple calendar
- client list
- income visibility
The product should feel like:
- a personal brand page
- a booking tool
- a lightweight work assistant
It should NOT feel like:
- a salon admin panel
- a CRM for teams
- an overloaded ERP-like system
- a back office for managers
---
## Strategic positioning
YCLIENTS is positioned around business automation: online booking, customer base automation, notifications, analytics, finance, payroll, stock control, and management of larger operations.
Monie must be positioned differently:
- not for business owners managing staff
- not for networks and franchises
- not for administrators
- for the master personally
The key shift is:
from "manage a business"
to "run your own practice simply"
---
## Main message
The user is not a company.
The user is a master.
The landing should communicate this feeling immediately:
"I am a master. I want a beautiful page, easy booking, and clear control over my work and income."
---
## Design direction
The visual style must be:
- modern
- premium
- clean
- soft
- confident
- minimal
- mobile-first
- conversion-focused
The emotional tone must be:
- personal
- calm
- aesthetic
- trustworthy
- not corporate
- not aggressive
- not noisy
Avoid:
- enterprise SaaS look
- complex tables on first screens
- admin-dashboard feel
- too much dense UI
- “business automation” aesthetics
- generic startup gradients everywhere
- crypto-like visual language
- ugly CRM blocks
- too many borders and widgets
---
## Product metaphor
Think of the product as closer to:
- a personal booking page
- a professional profile
- a masters mini-site
- a simple scheduling assistant
Not as:
- a back office
- a team management system
- a reporting center
---
## UX principles
Every UI decision must optimize for:
1. clarity
2. trust
3. speed of understanding
4. emotional comfort
5. conversion
The landing must explain the product in a few seconds.
The visitor should instantly understand:
- this is for masters
- this helps with bookings
- this helps avoid chaos in messages
- this helps track work and income
- this gives them a professional online presence
---
## Hero section rules
The hero must communicate 3 things immediately:
1. what the product is
2. who it is for
3. what action to take next
Hero should feel personal, not corporate.
Bad direction:
- “Business automation platform”
- “CRM and analytics for service companies”
- “Optimize operational efficiency”
Good direction:
- “Your personal booking page”
- “All your clients and appointments in one place”
- “For masters who want less chaos and more income”
- “Accept bookings without chats, spreadsheets, and confusion”
---
## Landing page structure
Preferred structure:
1. Hero
2. Problem
3. Solution
4. Product preview
5. Benefits
6. How it works
7. Personal page / profile feature
8. Social proof or trust block
9. FAQ
10. Final CTA
11. Footer
---
## Section intent
### 1. Hero
Make the value instantly clear.
Focus on one master, not a team.
### 2. Problem
Show current pain:
- bookings in messengers
- scattered notes
- forgotten appointments
- no clear client history
- no clear income view
### 3. Solution
Monie gives the master one clean place for:
- profile
- services
- booking
- calendar
- clients
- earnings
### 4. Product preview
Show interface as elegant and simple.
The UI should look closer to a polished consumer product than to CRM software.
### 5. Benefits
Explain outcomes, not enterprise functions.
Prefer:
- “clients can book you anytime”
- “all appointments in one calendar”
- “see how much you earned”
- “keep your services and prices in order”
- “look more professional online”
Avoid:
- “automation of business processes”
- “deep operational analytics”
- “staff access rights”
- “warehouse management”
- “franchise scaling”
### 6. How it works
Keep it simple and linear:
- create profile
- add services
- share link
- get bookings
### 7. Personal page feature
This is a key product idea.
The master should get a page like:
- monie.app/anna-nails
- monie.app/david-barber
This page should feel like a major product advantage.
### 8. Trust block
Use trust elements that fit solo specialists:
- looks professional
- simple to start
- saves time
- helps avoid missed bookings
### 9. FAQ
Answer practical concerns:
- do I need a website?
- can I set my own services and prices?
- can clients book online?
- is it good for a solo master?
- can I use it from phone?
### 10. Final CTA
Clear, direct, simple.
Bring the user back to one primary action.
---
## Visual system
### Layout
- Use a strong central container
- Keep generous whitespace
- Prefer large clean sections
- Build obvious visual rhythm
- Make scanning effortless
### Spacing
- Use a consistent spacing system
- Prefer breathing room over density
- Never make sections feel cramped
### Typography
- Strong, short headings
- Short supporting text
- High contrast and clear hierarchy
- No long walls of text
### Cards
- Use cards consistently
- Same radius language across sections
- Same shadow logic across sections
- Same padding logic across sections
Do not invent a new card style in every block.
### Buttons
Primary CTA must be obvious.
Secondary CTA must be quieter.
Prefer CTA labels like:
- Start free
- Create your page
- Get started
- Accept bookings online
Avoid vague labels like:
- Learn more
- Explore platform
- Discover solution
---
## UI tone
The interface should feel like a beautiful assistant for a master.
It should feel:
- feminine or neutral depending on styling direction
- elegant
- clean
- easy
- pleasant to use
- human
Never make it feel:
- bureaucratic
- operationally heavy
- manager-oriented
- back-office first
---
## Image and mockup direction
When creating product visuals or mockups:
- show a personal profile
- show services and prices
- show available booking times
- show simple schedule/calendar
- show compact client info
- show income summary in a lightweight way
Do not center the experience around:
- employees
- branches
- warehouse
- finance admin
- payroll management
- huge analytics dashboards
---
## Copywriting rules
Copy must be:
- short
- clear
- benefit-driven
- emotional but concrete
- easy to understand instantly
Prefer:
- plain language
- direct promises
- practical outcomes
Avoid:
- buzzwords
- abstract innovation language
- B2B corporate phrasing
- words that sound like enterprise software
Bad examples:
- revolutionary service business ecosystem
- end-to-end operational efficiency
- scalable management infrastructure
Good examples:
- all your bookings in one place
- your personal booking page
- simpler scheduling for masters
- clients can book you online anytime
- work with less chaos
---
## Mobile-first rule
This product is very likely to be discovered and used on phone.
All design decisions must work beautifully on mobile first:
- compact hero
- short copy
- clear CTA
- easy card scanning
- elegant stacked sections
- no tiny dense UI
Desktop should feel premium.
Mobile should feel natural.
---
## Conversion rule
This is a landing page, not a documentation page.
Every section must help the user move toward action.
If a section does not improve:
- clarity
- trust
- desire
- conversion
then remove it.
---
## What Codex should prioritize
When improving the landing, always prioritize in this order:
1. clarity
2. positioning for masters
3. emotional appeal
4. trust
5. conversion
6. visual consistency
7. polish
---
## Anti-patterns
Do not create:
- generic SaaS landing pages
- enterprise dashboard visuals
- complex CRM-like layouts
- feature grids with meaningless buzzwords
- too many UI styles in one page
- dark aggressive fintech aesthetics unless explicitly requested
- overloaded hero sections
- giant comparison tables unless specifically needed
- business-owner messaging instead of master messaging
---
## Component guidance
Preferred section/component set:
- HeroSection
- ProblemSection
- SolutionSection
- ProductPreviewSection
- BenefitsSection
- HowItWorksSection
- PersonalPageSection
- TrustSection
- FAQSection
- FinalCTASection
- Footer
Keep components modular and readable.
Prefer explicit names over abstract names.
---
## denjs-ui usage rule
Always check and use components from `denjs-ui` first.
Before creating any custom UI component:
1. Search in `denjs-ui` (`list_components`, `search_components`, `get_component`).
2. If a suitable component exists, use it.
3. Create a custom component only when no suitable `denjs-ui` option exists.
---
## FSD architecture rule
All new frontend work must follow Feature-Sliced Design (FSD).
Required layers:
- `src/app` — app init, providers, global styles, routing setup
- `src/pages` — route-level page composition only
- `src/widgets` — large page blocks/sections (Hero, FAQ, CTA, etc.)
- `src/features` — user scenarios and interactions (forms, actions, flows)
- `src/entities` — business entities (`master`, `booking`, `service`, `client`)
- `src/shared` — reusable UI, lib, config, api, assets
Rules:
- Keep strict dependency direction: upper layers can use lower layers only.
- Do not import across slices directly; use each slice public API (`index.ts`).
- Do not keep business UI logic directly in route files when it can live in `widgets/features/entities`.
- New sections/components for the landing should be created as FSD slices, not as flat files.
---
## Coding guidance
When generating frontend code:
- keep components small and reusable
- keep responsive behavior clean
- avoid unnecessary dependencies
- avoid overengineering
- keep styling tokens consistent
- use one visual language across the whole landing
- prefer simple structure over clever abstractions
---
## Decision filter
Before adding any element, ask:
- Does this make the product clearer?
- Does this make Monie feel more personal for a master?
- Does this increase trust?
- Does this improve conversion?
- Does this still avoid CRM/business-automation aesthetics?
If not, do not add it.
---
## One-sentence product definition
Monie is a simple, beautiful booking and client page for independent masters.