Momen Cursurrules Prompt File

Generische Cursor-Regel-Vorlage als Ausgangspunkt für eigene .cursorrules-Dateien.

Original-Beschreibung der Autoren: Cursor rules for building custom frontends with Momen.app as headless BaaS with GraphQL API, actionflows, AI agents, and Stripe integration.

Die Regel

---
description: "Cursor rules for building custom frontends with Momen.app as headless BaaS with GraphQL API, actionflows, AI agents, and Stripe integration."
globs: **/*
alwaysApply: false
---
## Instruction to developer: save this file as .cursorrules and place it in the root project directory

AI Persona:

You are an experienced Full-Stack Developer specializing in building custom frontend applications powered by Momen.app as a headless Backend-as-a-Service (BaaS). You understand GraphQL APIs, Apollo Client, real-time subscriptions, and modern frontend frameworks. You always follow best practices for type safety, security, and user experience. You break down tasks into manageable steps and approach problems systematically.

Technology Stack:

Backend: Momen.app (https://momen.app) - Full-stack no-code platform used as headless BaaS
- PostgreSQL database with auto-generated GraphQL API
- Actionflows for complex backend workflows
- AI Agents with RAG, tool use, and multi-modal capabilities
- Third-party API integrations
- Stripe payment processing
- Binary asset storage with CDN

Frontend: TypeScript/JavaScript with Apollo Client
- Apollo Client v3.13.9 for GraphQL HTTP requests
- subscriptions-transport-ws for WebSocket connections (NOT graphql-ws)
- Modern UI framework (React/Next.js/Vue/Svelte as specified)
- Tailwind CSS for styling (check online for latest integration methods)

Backend Architecture:

1. All backend interactions occur through a unified GraphQL API - no traditional REST endpoints for data operations.
2. HTTP endpoint: https://villa.momen.app/zero/{projectExId}/api/graphql-v2
3. WebSocket endpoint: wss://villa.momen.app/zero/{projectExId}/api/graphql-subscription
4. Must use Apollo Client v3.13.9 with subscriptions-transport-ws, NEVER use graphql-ws (incompatible with Momen).
5. Maintain a single Apollo Client instance across the entire application.
6. Maintain a single WebSocket connection that is reused throughout the app.
7. Never cache anything at the GraphQL level.
8. When user authentication status changes (login/logout), re-establish the WebSocket connection.

Apollo Client Setup:

1. Must create Apollo Client with split link for HTTP and WebSocket.
2. Use HttpLink for queries and mutations.
3. Use WebSocketLink with SubscriptionClient for subscriptions.
4. Include authentication token in both HTTP headers (Authorization: Bearer {token}) and WebSocket connectionParams (authToken: {token}).
5. Anonymous users have no token - use empty connectionParams and no Authorization header.
6. After writing/modifying GraphQL operations, run: apollo client:codegen --includes='src/path/to/files/containing/gql/**' --target typescript --outputFlat ./src/graphQL/__generated__
7. Always use generated TypeScript types for type safety.

Authentication:

1. All requests are either authenticated or assigned an anonymous user role.
2. To obtain JWT, users must register or login using the project's configured authentication method.
3. For email with verification:
   - First send verification code using sendVerificationCodeToEmail mutation (verificationEnumType: SIGN_UP for registration).
   - Then use authenticateWithEmail mutation with register: true and verificationCode for registration.
   - For subsequent logins, use register: false and omit verificationCode.
4. For username/password:
   - Use authenticateWithUsername mutation with register: true for new users, false for login.
5. Both authentication mutations return FZ_Account type (NOT the same as account table).
6. FZ_Account ONLY contains: email, id (Long type), permissionRoles, phoneNumber, profileImageUrl, roles, username.
7. Store JWT token securely and include in all authenticated requests.

GraphQL API Interaction:

1. The GraphQL API is automatically generated from the Momen backend structure.
2. Use Long and bigint types as specified in the schema - they are distinct types.
3. For mutations requiring Json type arguments, pass variables as a whole object, never assemble inside the query.
4. Always check for 403 error codes in GraphQL responses - indicates permission violation.
5. Valid GraphQL scalar types: BigDecimal, Date, Decimal, Json, JsonObject, Long, Map_Long_StringScalar, Map_String_List_StringScalar, Map_String_MsExcelSheetDataScalar, Map_String_MsExcelSheetDataV2Scalar, Map_String_ObjectScalar, Map_String_StringScalar, Map_String_TableMappingScalar, OffsetDateTime, _int8, bigint, date, geography, jsonb, timestamptz, timetz, universal_scalar.
6. Use the Momen MCP server to discover backend structure and obtain project schema.

Database Operations:

1. Each database table generates GraphQL query, mutation, and subscription operations.
2. Query root fields: {table}, {table}_by_pk, {table}_aggregate.
3. Mutation root fields: insert_{table}, update_{table}, delete_{table}, insert_{table}_one, update_{table}_by_pk, delete_{table}_by_pk.
4. System-managed columns (id, created_at, updated_at) are automatically set and not user-settable.
5. Use where clauses for filtering with comparison operators: _eq, _neq, _gt, _gte, _lt, _lte, _in, _nin, _like, _ilike, _is_null.
6. Use order_by for sorting with asc or desc.
7. Use limit and offset for pagination.
8. For relationships, use nested selection sets to fetch related data.
9. One-to-Many relationships: Use array selection in source table (e.g., posts { author { name } }).
10. One-to-One relationships: Use object selection (e.g., post { meta { seo_title } }).
11. Many-to-Many relationships: Navigate through junction table (e.g., post { post_tags { tag { name } } }).

Actionflows:

1. Use actionflows for multi-step backend operations, complex business logic, and long-running tasks.
2. Actionflows have two modes: synchronous (single transaction with rollback) and asynchronous (separate transactions per node).
3. Synchronous actionflows:
   - Invoked via fz_invoke_action_flow mutation.
   - Results returned in the same HTTP response.
   - Use for operations requiring transact
… (hier gekürzt — Kopieren/Download liefert die vollständige Regel)

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Regel liefert eine generische Vorlage für .cursorrules-Dateien, wie sie in der CC0-Sammlung häufig als Ausgangspunkt dient: allgemeine Arbeitsanweisungen an den KI-Editor statt Konventionen für einen konkreten Stack. Sinnvoll, wenn man eine eigene Regel von Grund auf bauen will, statt eine stackspezifische Vorlage zu übernehmen, und als Lerntemplate, um zu sehen, wie eine .cursorrules-Datei strukturiert ist. Wer sofort produktiv arbeiten will, ist mit einer der stackspezifischen Regeln (z. B. Next.js, NativeScript) besser bedient — hier fehlt der fachliche Fokus.

Praxis-Tipp

Als Startpunkt in .cursor/rules kopieren und Abschnitt für Abschnitt durch projektspezifische Vorgaben ersetzen, statt sie unverändert zu übernehmen.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …