VibeMeta Blog
Vibe Coding Life OS: 15 Prompts for a Better Build
Vibe Coding guide: build a Life OS with 15 modular prompts and zero spaghetti code. Generate your VibeMeta blueprint now.
Lucenx9
Creator of VibeMeta
Published Mar 6, 2026 · Updated Mar 6, 2026 · 12 min read ·
Browse all English posts · Sfoglia tutti gli articoli in italiano
Share this article
Share with your team or save this link for later.
Everyone tries the same move first: "Build me a Notion-style Life OS with tasks, journal, habits, pomodoro, expenses, finance, voice notes, and AI."
That works for about five minutes.
Then module #2 lands. The AI rewrites working files, mixes date formats, duplicates state, breaks persistence, and leaves you with beautiful spaghetti code.
That is the real bottleneck of vibe coding in 2026. Not ideas. Not UI. Architecture.
A real Life OS is not one feature. It is a collision of systems:
- Todo state
- Journal editing
- Markdown rendering
- CSV parsing
- Financial calculations
- Timer logic
- Speech-to-text
- AI summaries
- Cross-module widgets
- Shared persistence
- Shared theming
- Shared export/import
If you ask Cursor or Claude Code to build all of that in one shot, you are forcing the model to invent architecture while shipping product.
That is how context drift starts. That is how stable code gets rewritten for no reason. That is how "fast" turns into "why is my timer deleting habits?"
The secret is not a longer mega-prompt.
The secret is modular prompting.
Before you paste Prompt #1, generate a proper Blueprint / PRD.
That is the only real insurance policy against bugs, regressions, and AI freelancing your architecture into oblivion.
Use VibeMeta to generate your free Blueprint first, save it in your repo as /docs/BLUEPRINT.md, and make it the source of truth for every step after that.
Your Blueprint should lock in:
- the problem and goals
- what the app will not do
- user flows
- canonical data models
- module boundaries
- definition of done
- the build order
The prompts below are the bricks. VibeMeta is the floor plan.
Start here: https://vibemeta.app/
- Generate the Blueprint first
- Save it as
/docs/BLUEPRINT.md - Paste one prompt at a time into Cursor or Claude Code
- Do not paste Prompt #2 until Prompt #1 is verified
- Commit after each successful prompt
Phase 1 locks the stack, the repo rules, and the storage contract before any real feature work begins.
Prompt 1 - Initialize the stack
You are a senior full-stack engineer working inside this repository via Cursor or Claude Code.
Before writing any code, read /docs/BLUEPRINT.md. If that file does not exist, stop immediately and tell me to create it first.
Goal:
Initialize a modular Life OS web app using Next.js 15 App Router, TypeScript, Tailwind CSS, shadcn/ui, Zod, date-fns, Recharts, react-hook-form, @hookform/resolvers, lucide-react, clsx, tailwind-merge, Papa Parse, react-markdown, remark-gfm, and Framer Motion.
Constraints:
- Setup only. Do NOT implement any feature modules yet.
- Prefer pnpm.
- Keep changes reviewable and PR-sized.
- No auth, no backend, no cloud sync unless explicitly required by /docs/BLUEPRINT.md.
- Use a feature-folder architecture from day one.
Tasks:
1) Scaffold the Next.js app with App Router, TypeScript, Tailwind, and ESLint.
2) Install and initialize shadcn/ui.
3) Create this folder structure:
/app
/components
/context
/features/todo
/features/journal
/features/expenses
/features/habits
/features/pomodoro
/features/finance
/features/voice-journal
/lib
/types
/docs
4) Create a minimal app shell with:
- left sidebar navigation
- top header
- /app/dashboard/page.tsx placeholder
5) Create CLAUDE.md and .cursorrules with strict repo rules:
- always read /docs/BLUEPRINT.md before implementation
- one prompt = one measurable deliverable
- no giant refactors
- run typecheck + lint before marking work done
6) Create /docs/ARCHITECTURE.md, /docs/DATA_MODEL.md, /docs/UI_STATE.md, /docs/PLAN.md, and /docs/TASKS.md as starter docs.
7) Run typecheck + lint and fix any setup issues.
Deliverable:
- The app boots into a clean dashboard shell.
- Print a concise summary of commands run, files created, and any manual follow-up.
- Stop after setup.Prompt 2 - Set up Local Storage and the global Context API
Read these files first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
Implement the app foundation only: versioned local-first persistence plus a THIN global React Context API layer. Do NOT build feature UIs yet.
Architecture rules:
- Use localStorage with schema validation and versioned migrations.
- React Context is allowed only as a global orchestration layer.
- Do NOT put every module's raw business state into Context if it belongs in a feature repository/service.
- Each feature must own its own schema, repo, and selectors.
- Prevent SSR hydration mismatch.
Work:
1) Create /lib/storage with:
- storage keys registry
- versioned serializers
- safe parse helpers
- migration helpers
- corruption fallback behavior
2) Create /context/app-context.tsx and typed hooks:
- AppProvider
- useAppContext
- useAppSelectors
- useAppActions
3) The global context should manage only shared cross-module concerns:
- hydration status
- theme mode
- dashboard-level filters
- reminder queue
- command palette open/close state
- cross-module refresh signals
4) Add a StoreHydration boundary component so the app does not flash broken UI on reload.
5) Wire the provider into the root layout.
6) Document the storage strategy in /docs/ARCHITECTURE.md and the global app contract in /docs/UI_STATE.md and /docs/DATA_MODEL.md.
Definition of Done:
- App boots cleanly.
- Global context is fully typed.
- Storage utilities are reusable and version-aware.
- No feature module UI exists yet.
- Typecheck + lint pass.
Stop after this foundation layer is complete.Phase 2 builds each module in isolation. One prompt per feature. No cross-module rewrites. No clever shortcuts.
Prompt 3 - Todo list with Local Storage
Implement ONLY the Todo module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
- /docs/TASKS.md
Constraints:
- Local-first persistence only.
- Use the shared storage helpers from /lib/storage.
- Do not touch unrelated feature modules.
- Store due dates as local date strings in YYYY-MM-DD format.
- Use UUIDs for stable IDs.
Build:
1) /features/todo/schema.ts
2) /features/todo/types.ts
3) /features/todo/repo.ts
4) /features/todo/services.ts
5) /features/todo/components/*
6) /app/todo/page.tsx
Todo requirements:
- Task fields: id, title, optional notes, status, priority, category, dueDate, createdAt, updatedAt
- Add task
- Edit task
- Toggle complete
- Delete task with confirmation
- Search tasks
- Filters: All, Open, Completed, Due Soon, Overdue
- Bulk actions: Complete All, Clear Completed
- Undo destructive actions via toast
- Export tasks to JSON
- Import tasks from JSON with validation and merge-by-id
Documentation updates:
- Update /docs/DATA_MODEL.md with the final Todo schema
- Update /docs/UI_STATE.md with filters, empty states, and import/export behavior
Definition of Done:
- Todo page works end-to-end in the browser
- Data persists across reloads
- Invalid imports fail safely
- No console errors
- Typecheck + lint pass
Stop after the Todo module is complete.Prompt 4 - Daily journal with Markdown editor + AI summaries
Implement ONLY the Daily Journal module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Markdown is the source format
- AI summaries must be abstracted behind a provider interface
- If no AI provider key/config exists, create a deterministic local fallback summarizer so the feature remains testable
- Do not modify other modules
Build:
1) /features/journal/schema.ts
2) /features/journal/types.ts
3) /features/journal/repo.ts
4) /features/journal/summary-provider.ts
5) /features/journal/components/*
6) /app/journal/page.tsx
Journal requirements:
- Entry fields: id, title, markdown, mood, tags, createdAt, updatedAt
- Create, edit, delete entries
- Markdown editor with live preview
- Search by title/content
- Filter by mood or tag
- "Generate summary" action for each entry
- Store generated summaries locally with the entry
- Draft-safe editing so refresh does not destroy unsaved work
Documentation updates:
- Update /docs/DATA_MODEL.md with the journal schema
- Update /docs/UI_STATE.md with editor states, summary states, and fallback behavior
Definition of Done:
- Users can write Markdown entries and preview them
- AI summary generation works through a provider abstraction
- Local fallback summary works if no external AI is configured
- Entries persist across reloads
- Typecheck + lint pass
Stop after the Daily Journal module is complete.Prompt 5 - Expense tracker with Recharts and CSV import
Implement ONLY the Expense Tracker module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Store money as integer cents to avoid floating-point errors
- Store dates as local date strings YYYY-MM-DD
- Use Papa Parse for CSV import
- Use Recharts for all charts
- Do not touch unrelated feature modules
Build:
1) /features/expenses/schema.ts
2) /features/expenses/types.ts
3) /features/expenses/repo.ts
4) /features/expenses/money.ts
5) /features/expenses/csv.ts
6) /features/expenses/selectors.ts
7) /features/expenses/components/*
8) /app/expenses/page.tsx
Expense Tracker requirements:
- Fields: id, date, amountCents, category, merchant, note, source
- Add, edit, delete expenses
- Filter by month and category
- Import CSV with preview + validation
- Reject invalid rows safely
- Summary cards for total spend, average spend, and top category
- Recharts visualizations:
- spend by category
- spend trend by month
Documentation updates:
- Update /docs/DATA_MODEL.md with the expense schema
- Update /docs/UI_STATE.md with the import flow and chart states
Definition of Done:
- CRUD works end-to-end
- CSV import validates and previews before save
- Charts match the underlying aggregation math
- No NaN or formatting bugs
- Typecheck + lint pass
Stop after the Expense Tracker module is complete.Prompt 6 - Habit tracker with GitHub-style heatmap
Implement ONLY the Habit Tracker module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Store habit completion using local date strings only: YYYY-MM-DD
- No timezone objects in persisted data
- All streak and progress logic must be implemented with pure functions
- Do not modify unrelated modules
Build:
1) /features/habits/schema.ts
2) /features/habits/types.ts
3) /features/habits/repo.ts
4) /features/habits/streak.ts
5) /features/habits/selectors.ts
6) /features/habits/components/*
7) /app/habits/page.tsx
Habit Tracker requirements:
- Fields: id, name, cadence, optional goalPerWeek, createdAt, completedDates
- Add, edit, delete habits
- Mark today complete/incomplete
- Compute current streak
- Compute longest streak
- Compute weekly completion rate
- Show a GitHub-style heatmap grid for the last 90 days
- Show Today, This Week, and Streak summary cards
Documentation updates:
- Update /docs/DATA_MODEL.md with habit schema and date rules
- Update /docs/UI_STATE.md with heatmap and summary states
Definition of Done:
- Streak logic is correct
- Heatmap updates instantly when completion changes
- Data persists across reloads
- Typecheck + lint pass
Stop after the Habit Tracker module is complete.Prompt 7 - Pomodoro timer + statistics dashboard
Implement ONLY the Pomodoro module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Timer must survive reloads using persisted timestamps, not fragile in-memory countdown math
- Keep timing logic separate from UI
- Do not touch unrelated modules
Build:
1) /features/pomodoro/schema.ts
2) /features/pomodoro/types.ts
3) /features/pomodoro/repo.ts
4) /features/pomodoro/timer-engine.ts
5) /features/pomodoro/selectors.ts
6) /features/pomodoro/components/*
7) /app/pomodoro/page.tsx
Pomodoro requirements:
- Modes: focus, short break, long break
- Configurable durations
- Start, pause, resume, reset
- Persist active session state across refresh
- Track completed sessions history
- Statistics dashboard with:
- focus minutes today
- sessions completed today
- sessions completed this week
- average session length
- completion streak by day
- Optional local notification when a session ends
Documentation updates:
- Update /docs/DATA_MODEL.md with timer/session schema
- Update /docs/UI_STATE.md with timer states and dashboard states
Definition of Done:
- Timer remains accurate after refresh
- Statistics reflect the stored session history
- No double-counting or ghost sessions
- Typecheck + lint pass
Stop after the Pomodoro module is complete.Prompt 8 - Personal finance tracker with bank import
Implement ONLY the Personal Finance module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- This module is separate from the simpler Expense Tracker
- Reuse shared money/date helpers where appropriate
- Local-first persistence only
- Bank import must be validated and deduplicated
- Do not modify unrelated modules
Build:
1) /features/finance/schema.ts
2) /features/finance/types.ts
3) /features/finance/repo.ts
4) /features/finance/import-bank.ts
5) /features/finance/selectors.ts
6) /features/finance/components/*
7) /app/finance/page.tsx
Personal Finance requirements:
- Account fields: id, name, type, currency, openingBalanceCents, currentBalanceCents
- Transaction fields: id, accountId, date, amountCents, direction, category, description, source
- Add/edit/delete accounts
- Import bank CSV with column-mapping preview
- Deduplicate imported transactions using a stable fingerprint strategy
- Show monthly cash flow
- Show account balances
- Show net cash position
- Show recurring income/expense summary if supported by the Blueprint
Documentation updates:
- Update /docs/DATA_MODEL.md with account and transaction schemas
- Update /docs/UI_STATE.md with import mapping and dashboard states
Definition of Done:
- Bank CSV import works with preview and validation
- Duplicate rows are not re-imported
- Balances and cash-flow widgets are correct
- Typecheck + lint pass
Stop after the Personal Finance module is complete.Prompt 9 - Voice journal with speech-to-text + AI summaries
Implement ONLY the Voice Journal module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Use the Web Speech API for speech-to-text if available
- If speech recognition is unavailable, provide a manual transcript fallback
- AI summaries must use a provider interface with a deterministic local fallback
- Do not modify unrelated modules
Build:
1) /features/voice-journal/schema.ts
2) /features/voice-journal/types.ts
3) /features/voice-journal/repo.ts
4) /features/voice-journal/transcription.ts
5) /features/voice-journal/summary-provider.ts
6) /features/voice-journal/components/*
7) /app/voice-journal/page.tsx
Voice Journal requirements:
- Fields: id, title, transcript, summary, mood, tags, createdAt, updatedAt
- Record/transcribe voice input when supported
- Manual transcript entry fallback
- Create, edit, delete entries
- Generate AI summary for each entry
- Search by transcript/title/tag
- Persist transcript and summary locally
Documentation updates:
- Update /docs/DATA_MODEL.md with the voice journal schema
- Update /docs/UI_STATE.md with recording, fallback, and summary states
Definition of Done:
- Voice capture/transcription flow works when supported
- Manual fallback works when speech APIs are unavailable
- AI summary generation is abstracted and testable
- Typecheck + lint pass
Stop after the Voice Journal module is complete.Phase 3 composes the system, adds the assistant, cleans module boundaries, resolves conflicts, polishes UX, and closes with a safety pass.
Prompt 10 - Build the all-in-one Life OS dashboard
Implement the unified Life OS dashboard.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/UI_STATE.md
- /docs/PLAN.md
- all existing feature selectors/services
Constraints:
- Dashboard must consume only public selectors/services from each feature
- Do NOT reach into internal module implementation details
- Do NOT rewrite working feature logic
- Focus on composition, not reinvention
Build:
1) /app/dashboard/page.tsx
2) Any small shared dashboard widget components under /components or /features/*/components as appropriate
Dashboard requirements:
- Responsive widget-based layout
- Todo widget: due today, overdue count, quick-add shortcut
- Daily Journal widget: latest entry + latest AI summary preview
- Expense widget: current month total + top category
- Habit widget: habits completed today + best active streak
- Pomodoro widget: focus minutes today + next timer action
- Personal Finance widget: current cash flow snapshot
- Voice Journal widget: latest transcript summary
- Every widget links to its full module page
Documentation updates:
- Update /docs/UI_STATE.md with the final dashboard layout and widget rules
Definition of Done:
- Dashboard numbers are correct
- Each module still works independently
- No widget bypasses module boundaries
- Typecheck + lint pass
Stop after the dashboard is complete.Prompt 11 - Add an AI agent that manages tasks and reminders
Implement an AI assistant layer for the Life OS without allowing silent state mutations.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/UI_STATE.md
- existing feature selectors/services
- /context/app-context.tsx
Constraints:
- The AI agent may read state through typed selectors only
- The AI agent must propose actions before applying them
- No silent writes
- If no external AI is configured, provide a deterministic mock agent
- Reminders must be stored locally
- Do not rewrite unrelated modules
Build:
1) /features/assistant/types.ts
2) /features/assistant/agent-provider.ts
3) /features/assistant/tooling.ts
4) /features/assistant/components/*
5) Integrate the assistant into the dashboard or app shell
Assistant capabilities:
- Create a task from natural language
- Suggest a reminder
- Summarize "today so far"
- Suggest the next Pomodoro block
- Flag overspending trends from finance/expenses
- Turn a voice transcript into a task suggestion
UX rules:
- Show proposed actions in a review card
- Require user confirmation before applying changes
- Log accepted/rejected suggestions in local state
Documentation updates:
- Update /docs/UI_STATE.md with assistant flows and confirmation rules
Definition of Done:
- Assistant can read app state safely
- Suggested actions are reviewable and confirmable
- No silent mutations occur
- Typecheck + lint pass
Stop after the assistant layer is complete.Prompt 12 - Refactor to isolate components and reduce coupling
Perform a refactor pass focused ONLY on modular boundaries and component isolation.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/PLAN.md
- the full existing repository
Constraints:
- No feature additions
- No visual redesign
- No business-logic rewrites unless strictly required to preserve behavior during extraction
- Prefer small file moves and public API cleanup over clever architecture experiments
Goals:
- Reduce coupling
- Make each feature easier to maintain
- Prepare the repo for future additions without context collapse
Work:
1) Identify oversized files, mixed concerns, and hidden cross-module dependencies
2) Extract shared UI primitives where duplication is legitimate
3) Ensure each feature exposes a clean public surface:
- schema
- types
- repo
- selectors
- components
4) Add or clean up barrel exports where useful
5) Remove dead code and duplicate helpers
6) Update /docs/ARCHITECTURE.md with the final module boundaries
Definition of Done:
- Module boundaries are cleaner than before
- No behavior regressions
- Imports are simpler and more intentional
- Typecheck + lint pass
Stop after the refactor pass is complete.Prompt 13 - Resolve state conflicts between modules
Audit and fix cross-module state conflicts across the entire Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- the full repository
Constraints:
- Keep each module's ownership clear
- Do not collapse everything into one mega-store
- Fix conflicts at the contract level: data format, selector boundaries, hydration, imports, storage keys
Audit for:
- inconsistent date formats
- inconsistent money formats
- storage key collisions
- duplicate entity IDs
- stale selectors
- hydration mismatch
- hidden writes across modules
- duplicate imports/exports of the same concept
Implement:
1) Canonical shared rules:
- local dates use YYYY-MM-DD
- money uses integer cents
- IDs use crypto.randomUUID()
- storage keys are namespaced per module
2) Integrity checks on app boot and import
3) Safer cross-module refresh signals through the global context
4) Any missing type guards or validation needed to stop invalid state propagation
Documentation updates:
- Update /docs/DATA_MODEL.md and /docs/ARCHITECTURE.md with the final cross-module contracts
Definition of Done:
- No module corrupts another module's state
- Shared formats are consistent
- App reload and import flows remain stable
- Typecheck + lint pass
Stop after the state-conflict audit and fixes are complete.Prompt 14 - Polish UI/UX: motion, coherence, dark mode
Execute a UI/UX polish pass across the whole Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/UI_STATE.md
- the existing UI components and routes
Constraints:
- Preserve existing business logic
- Focus on consistency, accessibility, motion, and dark mode coherence
- Only make structural UI changes that improve usability
Polish goals:
- consistent spacing, typography, and card hierarchy
- coherent dark mode
- smooth but restrained animations
- keyboard accessibility
- empty states, loading states, and scroll behavior that feel intentional
Work:
1) Standardize button, input, card, badge, and dialog usage across modules
2) Use Framer Motion for subtle transitions where it improves perceived quality
3) Ensure dark mode styling is consistent in every route
4) Add skeleton/loading placeholders where needed
5) Prevent long lists from breaking layout; make them scroll internally
6) Improve dashboard scanability and mobile responsiveness
7) Add a Settings page theme toggle if not already present
Documentation updates:
- Update /docs/UI_STATE.md with the final UI behavior and visual consistency notes
Definition of Done:
- The app feels cohesive
- Mobile and desktop layouts both work
- Dark mode is consistent
- No logic regressions
- Typecheck + lint pass
Stop after the polish pass is complete.Prompt 15 - Security check + full data export in JSON
Perform a final security and data-portability pass across the Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/ARCHITECTURE.md
- the full repository
Constraints:
- Keep the app local-first
- Validate every import path
- Do not weaken feature isolation
- Preserve existing UX unless needed for safety
Work:
1) Create a full-app JSON export/import flow in /app/settings/page.tsx
2) Create /lib/backup.ts to orchestrate export/import for all modules:
- todo
- journal
- expenses
- habits
- pomodoro
- finance
- voice journal
- assistant state if applicable
3) Add versioned backup schema validation with Zod
4) Add an import preview/diff summary before applying a restore
5) Sanitize Markdown rendering paths to reduce XSS risk
6) Validate CSV imports defensively
7) Fail safely on corrupt or partial JSON
8) Update docs with backup schema and versioning policy
Definition of Done:
- A single JSON export can restore the full app in a clean browser profile
- Corrupt imports fail safely
- Markdown and CSV flows are handled defensively
- Typecheck + lint pass
Stop after the final security + backup pass is complete.These 15 prompts are powerful. They are also dangerous if you skip architecture.
That is the whole point.
The reason most "build me a Life OS" experiments implode is not that Cursor is bad or Claude Code is weak.
It is that people try to ship seven products inside one AI context without a real plan.
That is how you get spaghetti code.
That is how you hit the complexity wall.
That is how the AI starts "helping" by destroying working code.
So use the prompts.
But do the adult thing first: generate the Blueprint on VibeMeta, lock the architecture, and then execute prompt by prompt.
Start With the Blueprint
Generate the architecture first, then run the 15 prompts with cleaner boundaries and far less drift.
Generate your blueprint
Want a full implementation blueprint for this topic? Open the generator with a prefilled idea. Want real examples? Explore the Community Gallery.
Written by Lucenx9
Builder and creator of VibeMeta. Shipping tools for developers who vibe code.
You might also like
Ready to build? Generate your blueprint.
From idea to complete build plan in 30 seconds.
Open Generator