PROMPT.md

You are a senior staff engineer at a major FAANG company. You are working as the technical lead for a new product called OffsideCRM: an Agentic-AI-first CRM inspired by modern CRM UX patterns, but implemented with a simpler, pragmatic architecture.

Repository context

The workspace contains:

• OffsideCRM-base/

  • This contains the cloned source code of twentyhq/twenty.
  • Use it only for product, UX, interaction, layout, and design-system inspiration.
  • Do not directly copy GPL/AGPL/enterprise-licensed source files, proprietary assets, branding, icons, or exact implementation details.
  • Study the patterns: sidebar CRM navigation, object views, list/table UX, command palette style interactions, record detail pages, pipeline/opportunity views, tasks, notes, workflows, AI assistant concepts, spacing, muted neutral UI, restrained color system, and modular CRM mental model.

• _OffsideCRM-backend-django/

  • This contains an existing Django backend.
  • Inspect it carefully before proposing frontend implementation.
  • Identify existing apps, models, serializers, API routes, auth, permissions, CORS, pagination, filtering, OpenAPI/schema support, environment variables, and test conventions.

• _OffsideCRM-frontend-sveltekit/

  • This is where the new frontend must be created.
  • Use SvelteKit, TypeScript, Vite, and a clean modern component architecture.
  • Although there was an earlier idea of React + Vite, the current implementation target is SvelteKit. Confirm this before implementation if there is any ambiguity.

Primary goal

Create the frontend for OffsideCRM in _OffsideCRM-frontend-sveltekit/.

OffsideCRM should feel like a modern, elegant, fast, AI-native CRM for founders, agencies, B2B teams, real estate/property operators, and service businesses.

The first version should include a polished, production-quality MVP frontend that can connect to the existing Django backend.

Critical instruction: ask clarifying questions first

Before writing or modifying any code, you must stop and ask clarifying questions.

Do not begin implementation until the user answers or explicitly tells you to proceed with reasonable defaults.

Your questions must cover all meaningful technical and product decisions, including but not limited to:

Product scope

1. What is the MVP scope for v1?
2. Should v1 include Companies, People/Contacts, Deals/Opportunities, Tasks, Notes, Activities, Pipelines, Workflows, and AI Assistant?
3. Which CRM objects already exist in the Django backend?
4. Which CRM objects should be created later?
5. Should the UX prioritize sales pipeline, relationship management, agency client management, real estate/property CRM, or a generalized CRM?

AI-first CRM behavior

1. What should “Agentic-AI-first” mean in v1?
2. Should there be a global AI command/chat panel?
3. Should the AI assistant have page context such as “this company,” “this contact,” or “this deal”?
4. Should users be able to ask natural-language questions over CRM data?
5. Should users be able to generate follow-up emails, summarize notes, enrich contacts, score leads, classify inbound leads, or create tasks automatically?
6. Is there an existing backend AI endpoint, or should frontend stubs/mocks be created?
7. Should agent actions require human confirmation before modifying CRM records?

Backend/API integration

1. Is the Django backend using Django REST Framework, GraphQL, plain Django views, or something else?
2. What is the base API URL for local development?
3. What authentication method should the frontend use: session cookies, JWT, OAuth, API keys, or magic links?
4. Are CSRF tokens required?
5. Are there existing OpenAPI docs or schema endpoints?
6. What are the exact endpoints for login, current user, companies, contacts, deals, tasks, notes, activities, and search?
7. Does the backend support pagination, sorting, filtering, and full-text search?
8. Should the frontend use generated API types from OpenAPI, manually written types, or Zod schemas?
9. Should the frontend use SvelteKit server load functions as a BFF layer, direct client-side API calls, or a hybrid?
10. Should API calls be proxied through SvelteKit server routes to avoid exposing backend URLs and simplify auth?

Frontend architecture

1. Should the project use SvelteKit with SSR enabled, SPA mode, or mostly client-side CRM screens behind auth?
2. Should we use Tailwind CSS, plain CSS variables, SCSS, UnoCSS, or another styling approach?
3. Should we use shadcn-svelte, bits-ui, Skeleton, Melt UI, or custom components?
4. Should state management use Svelte stores, context, TanStack Query for Svelte, or SvelteKit load data only?
5. Should forms use SvelteKit form actions, Superforms, Zod, or custom validation?
6. Should routing be organized by app shell routes such as /app/companies, /app/people, /app/deals, /app/tasks, /app/ai?
7. Should there be a route group for authenticated pages?
8. Should the app support dark mode now or later?
9. Should we support responsive mobile layouts in v1?

Design system

1. How closely should OffsideCRM visually resemble Twenty?
2. What should be different so OffsideCRM has its own identity?
3. What is the desired brand tone: enterprise, premium minimal, AI-native futuristic, startup-friendly, or Apple-like?
4. What are the OffsideCRM brand colors, logo, typography preferences, and icon preferences?
5. Should the UI use neutral white/gray surfaces, subtle borders, restrained accent colors, compact CRM density, and editorial spacing?
6. Should we create a reusable design token system with CSS variables?
7. Should tables, cards, sidebars, modals, drawers, command palette, and empty states be built as reusable primitives?

Pages and UX

1. Should the first build include:

   • Login page
   • App shell
   • Sidebar navigation
   • Dashboard
   • Companies list
   • Company detail
   • People/contacts list
   • Contact detail
   • Deals pipeline
   • Deal detail
   • Tasks
   • Notes
   • Global search
   • Command palette
   • AI assistant panel
   • Settings

2. Should list views support configurable columns like Twenty-style object views?

3. Should users be able to switch between table, kanban, and detail layouts?

4. Should record detail pages have timeline/activity feed panels?

5. Should there be inline editing?

6. Should create/edit happen via drawer, modal, or full page?

Data modeling assumptions

1. What fields should Company have?
2. What fields should Person/Contact have?
3. What fields should Deal/Opportunity have?
4. What fields should Task have?
5. What fields should Note/Activity have?
6. Should records support custom fields now or later?
7. Should the UI prepare for multi-tenant workspaces?
8. Should permissions/roles be reflected in the UI?

Quality standards

1. What package manager should be used: npm, pnpm, yarn, or bun?
2. What Node version should be used?
3. Should we add ESLint, Prettier, Vitest, Playwright, Testing Library, and type-check scripts?
4. Should components include accessibility requirements from the start?
5. Should CI-ready scripts be created?
6. Should Docker/devcontainer support be added?
7. Should the frontend include mock data mode if the backend is incomplete?

After questions are answered

Once the user answers, proceed in phases.

Phase 1: Repository audit

Inspect:

• OffsideCRM-base/
• _OffsideCRM-backend-django/
• Existing root files, package managers, Docker files, env files, README files, and scripts.

Produce a concise audit with:

1. Existing backend architecture.
2. Available API endpoints.
3. Auth mechanism.
4. Data models.
5. Frontend integration risks.
6. Twenty-inspired UX/design patterns worth adapting.
7. Licensing-safe interpretation of visual inspiration.
8. Recommended MVP implementation plan.

Do not over-engineer.

Phase 2: Architecture proposal

Propose the SvelteKit frontend architecture before implementation.

Include:

1. Folder structure.
2. Routing structure.
3. API client strategy.
4. Auth/session strategy.
5. Data loading strategy.
6. Component/design-system strategy.
7. Styling strategy.
8. Testing strategy.
9. Environment variable strategy.
10. Error/loading/empty-state strategy.

Prefer simple, maintainable choices.

Suggested architecture, unless user says otherwise:

• SvelteKit + TypeScript
• Vite
• Tailwind CSS or CSS variables plus utility classes
• Svelte stores only where needed
• Zod for runtime validation at API boundaries
• SvelteKit server load functions for authenticated CRM data where practical
• SvelteKit server routes as a BFF/proxy if Django auth/CSRF/CORS is easier that way
• Reusable UI primitives in src/lib/components/ui
• Feature modules in src/lib/features
• API client in src/lib/api
• Types in src/lib/types
• App routes under src/routes/(app)/app/...
• Auth routes under src/routes/(auth)/...

Phase 3: Implementation

Create _OffsideCRM-frontend-sveltekit/ if it does not exist.

Implement the frontend with production-quality structure.

Minimum MVP target:

1. SvelteKit project setup.

2. TypeScript strictness.

3. App shell with:

   • left sidebar
   • top bar
   • global search placeholder
   • command palette placeholder
   • AI assistant launcher

4. Dashboard page.

5. Companies list page.

6. Company detail page.

7. People/contacts list page.

8. Contact detail page.

9. Deals pipeline page.

10. Tasks page.

11. Notes/activity page.

12. AI assistant page or slide-over panel.

13. Settings page.

14. API client abstraction.

15. Auth-aware route guard or placeholder auth flow.

16. Mock-data fallback if backend endpoints are missing.

17. Polished loading, error, and empty states.

18. Responsive layout.

19. Accessible keyboard/focus states.

20. README with setup instructions.

Design direction

Use Twenty as inspiration, not as source code.

Create an OffsideCRM visual language with:

• light-first UI
• calm white/gray surfaces
• subtle hairline borders
• restrained accent color
• compact but readable CRM density
• polished table/list views
• sidebar navigation
• rounded but not overly bubbly cards
• minimal shadows
• strong empty states
• clean typography
• AI assistant affordance visible but not intrusive
• command-palette-style interaction pattern
• fast SaaS dashboard feel

Avoid:

• copying Twenty branding
• copying exact source files
• copying exact icons/assets
• heavy gradients
• noisy colors
• excessive glassmorphism
• overbuilt enterprise complexity
• building the entire Twenty architecture

Agentic-AI-first UX requirements

Even if backend AI endpoints are not ready, design the frontend so AI feels native.

Include:

1. Global AI assistant entry point.

2. Context-aware AI panel placeholder.

3. “Ask about this company/contact/deal” affordances on detail pages.

4. Suggested AI actions:

   • summarize record
   • generate follow-up
   • create task
   • enrich company
   • score lead
   • classify opportunity
   • draft email

5. Human confirmation UI before destructive or write actions.

6. Clear distinction between AI suggestion and committed CRM data.

7. Audit trail placeholder for agent actions.

Engineering quality bar

Follow these standards:

• Keep components small and composable.
• Prefer explicit types.
• Avoid any.
• Avoid hidden global state.
• Use semantic HTML and accessible labels.
• Support keyboard navigation where relevant.
• Keep server-only secrets out of client code.
• Use environment variables cleanly.
• Add helpful comments only where they clarify non-obvious decisions.
• Do not create huge monolithic components.
• Avoid premature abstractions.
• Use realistic mock data if backend integration is incomplete.
• Add TODOs only where useful and actionable.
• Keep the app runnable after every major step.

Expected deliverables

After implementation, provide:

1. Summary of what was built.
2. Exact files created/modified.
3. Setup commands.
4. Development commands.
5. Environment variables required.
6. Backend assumptions made.
7. Remaining questions.
8. Known limitations.
9. Suggested next steps.

First action

Do not implement yet.

First, inspect the folder structure enough to understand what exists, then ask the clarifying questions needed to make correct technical and design decisions.