{"owner":"keephq","repo":"keep","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":1026,"categories":["cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":[".cursor/rules/keep-ui-react-typescript.mdc",".cursor/rules/keep-ui-tests.mdc"],"skills":{".cursor/rules/keep-ui-react-typescript.mdc":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules for writing frontend code at Keep (React + Typescript)\nglobs: keep-ui/**/*.tsx, keep-ui/**/*.ts\n---\n\nYou are an expert in TypeScript, React, Next.js, SWR, Tailwind, and UX design.\n\n# Achitecture\nUse Feature-Slice Design Convention with modification: instead of `pages` and `app` we use default Next.js route-based folder structure.\n\nExample:\n- entities/\n  - incidents/\n    - api/\n    - lib/\n    - model/\n    - ui/\n\nTop-level folders, called Layers: \n- widgets\n- features\n- entities\n- shared\n\nEach layer has segments, e.g. \"entities/users\".\n\nEach segment has slices \n- ui — everything related to UI display: UI components, date formatters, styles, etc.\n- api — backend interactions: request functions, data types, mappers, etc.\n- model — the data model: schemas, interfaces, stores, and business logic.\n- lib — library code that other modules on this slice need.\n- config — configuration files and feature flags.\n\n# Code Style and Structure\n- Write TypeScript with proper typing for all new code\n- Use functional programming patterns; avoid classes\n- Prefer iteration and modularization over code duplication.\n- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n- Don't use `useEffect` where you can use ref function for dom-dependent things (e.g. ref={el => ...})\n- Don't use `useState` where you can infer from props\n- Use named exports; avoid default exports\n- If you need to create new base component, first look at existing ones in `@/shared/ui`\n\n# Naming Conventions\n- Always look around the codebase for naming conventions, and follow the best practices of the environment (e.g. use `camelCase` variables in JS).\n- Use clear, yet functional names (`searchResults` vs `data`).\n- React components are PascalCase (`IncidentList`).\n- Props for components and hooks are PascalCase and end with `Props`, e.g. `WorkflowBuilderWidgetProps`, return value for hooks is PascalCase and end with `Value`, e.g. `UseIncidentActionsValue` \n- Name the `.ts` file according to its main export: `IncidentList.ts` or `IncidentList.tsx` or `useIncidents.ts`. Pay attention to the case.\n- Avoid `index.ts`, `styles.css`, and other generic names, even if this is the only file in a directory.\n\n# Data Fetching\n- Use useSWR for fetching data, create or extend hooks in @/entities/<entity>/model/use<Entity>.ts which encapsulates fetching logic\n- Create a dedicated keys file @/entities/<entity>/lib/<entity>Keys.ts to manage SWR cache keys. Structure it as an object with methods for different operations:\n```export const entityKeys = {\n  all: \"entityName\",\n  list: (query: QueryParams) => [...],\n  detail: (id: string) => [...],\n  getListMatcher: () => (key: any) => boolean\n}```\n- For query-based endpoints, construct cache keys by joining parameters with \"::\", filtering out falsy values:\n```list: (query: QueryParams) => [\n  entityKeys.all,\n  \"list\",\n  query.param1,\n  query.param2\n].filter(Boolean).join(\"::\")```\n- For create, update, delete actions:\n  - Create or extend hook in @/entities/<entity>/model/use<Entity>Actions.ts\n  - Create a dedicated revalidation hook (e.g., use<Entity>Revalidation.ts) to handle cache invalidation\n  - Revalidate both specific items and list queries after mutations\n  - Include success/error toast notifications for user feedback\n  - Handle file uploads and other complex operations within the actions hook\n\n# UI and Styling\n- Use Tailwind CSS as primary styling solution\n- For non-Tailwind cases:\n  - Use CSS with component-specific files\n  - Namespace under component class (.DropdownMenu)\n  - Follow BEM for modals (.DropdownMenu__modal)\n  - Import styles directly (import './DropdownMenu.css')\n- Replace custom CSS with Tailwind when possible\n\n",".cursor/rules/keep-ui-tests.mdc":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules and guidelines for writing and running React tests\nglobs: *.spec.tsx, *.test.tsx, *.test.ts, *.spec.ts\n---\n\n# Writing frontend tests\n\nPlace tests in __tests__ folder in the module, e.g. tests for file `/features/workflows/model/useWorkflows.tsx` should be `/features/workflows/models/__tests__/useWorkflows.test.tsx`\n\n# Running frontend tests\n\nPlease run tests with command: npm run test in keep-ui folder\nFor example: cd keep-ui && npm run test"},"files":{".cursor/rules/keep-ui-react-typescript.mdc":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules for writing frontend code at Keep (React + Typescript)\nglobs: keep-ui/**/*.tsx, keep-ui/**/*.ts\n---\n\nYou are an expert in TypeScript, React, Next.js, SWR, Tailwind, and UX design.\n\n# Achitecture\nUse Feature-Slice Design Convention with modification: instead of `pages` and `app` we use default Next.js route-based folder structure.\n\nExample:\n- entities/\n  - incidents/\n    - api/\n    - lib/\n    - model/\n    - ui/\n\nTop-level folders, called Layers: \n- widgets\n- features\n- entities\n- shared\n\nEach layer has segments, e.g. \"entities/users\".\n\nEach segment has slices \n- ui — everything related to UI display: UI components, date formatters, styles, etc.\n- api — backend interactions: request functions, data types, mappers, etc.\n- model — the data model: schemas, interfaces, stores, and business logic.\n- lib — library code that other modules on this slice need.\n- config — configuration files and feature flags.\n\n# Code Style and Structure\n- Write TypeScript with proper typing for all new code\n- Use functional programming patterns; avoid classes\n- Prefer iteration and modularization over code duplication.\n- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n- Don't use `useEffect` where you can use ref function for dom-dependent things (e.g. ref={el => ...})\n- Don't use `useState` where you can infer from props\n- Use named exports; avoid default exports\n- If you need to create new base component, first look at existing ones in `@/shared/ui`\n\n# Naming Conventions\n- Always look around the codebase for naming conventions, and follow the best practices of the environment (e.g. use `camelCase` variables in JS).\n- Use clear, yet functional names (`searchResults` vs `data`).\n- React components are PascalCase (`IncidentList`).\n- Props for components and hooks are PascalCase and end with `Props`, e.g. `WorkflowBuilderWidgetProps`, return value for hooks is PascalCase and end with `Value`, e.g. `UseIncidentActionsValue` \n- Name the `.ts` file according to its main export: `IncidentList.ts` or `IncidentList.tsx` or `useIncidents.ts`. Pay attention to the case.\n- Avoid `index.ts`, `styles.css`, and other generic names, even if this is the only file in a directory.\n\n# Data Fetching\n- Use useSWR for fetching data, create or extend hooks in @/entities/<entity>/model/use<Entity>.ts which encapsulates fetching logic\n- Create a dedicated keys file @/entities/<entity>/lib/<entity>Keys.ts to manage SWR cache keys. Structure it as an object with methods for different operations:\n```export const entityKeys = {\n  all: \"entityName\",\n  list: (query: QueryParams) => [...],\n  detail: (id: string) => [...],\n  getListMatcher: () => (key: any) => boolean\n}```\n- For query-based endpoints, construct cache keys by joining parameters with \"::\", filtering out falsy values:\n```list: (query: QueryParams) => [\n  entityKeys.all,\n  \"list\",\n  query.param1,\n  query.param2\n].filter(Boolean).join(\"::\")```\n- For create, update, delete actions:\n  - Create or extend hook in @/entities/<entity>/model/use<Entity>Actions.ts\n  - Create a dedicated revalidation hook (e.g., use<Entity>Revalidation.ts) to handle cache invalidation\n  - Revalidate both specific items and list queries after mutations\n  - Include success/error toast notifications for user feedback\n  - Handle file uploads and other complex operations within the actions hook\n\n# UI and Styling\n- Use Tailwind CSS as primary styling solution\n- For non-Tailwind cases:\n  - Use CSS with component-specific files\n  - Namespace under component class (.DropdownMenu)\n  - Follow BEM for modals (.DropdownMenu__modal)\n  - Import styles directly (import './DropdownMenu.css')\n- Replace custom CSS with Tailwind when possible\n\n",".cursor/rules/keep-ui-tests.mdc":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules and guidelines for writing and running React tests\nglobs: *.spec.tsx, *.test.tsx, *.test.ts, *.spec.ts\n---\n\n# Writing frontend tests\n\nPlace tests in __tests__ folder in the module, e.g. tests for file `/features/workflows/model/useWorkflows.tsx` should be `/features/workflows/models/__tests__/useWorkflows.test.tsx`\n\n# Running frontend tests\n\nPlease run tests with command: npm run test in keep-ui folder\nFor example: cd keep-ui && npm run test"},"items":[{"name":"keep-ui-react-typescript.mdc","path":".cursor/rules/keep-ui-react-typescript.mdc","rawUrl":"https://raw.githubusercontent.com/keephq/keep/HEAD/.cursor/rules/keep-ui-react-typescript.mdc","title":"Cursor Rule: keep-ui-react-typescript","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules for writing frontend code at Keep (React + Typescript)\nglobs: keep-ui/**/*.tsx, keep-ui/**/*.ts\n---\n\nYou are an expert in TypeScript, React, Next.js, SWR, Tailwind, and UX design.\n\n# Achitecture\nUse Feature-Slice Design Convention with modification: instead of `pages` and `app` we use default Next.js route-based folder structure.\n\nExample:\n- entities/\n  - incidents/\n    - api/\n    - lib/\n    - model/\n    - ui/\n\nTop-level folders, called Layers: \n- widgets\n- features\n- entities\n- shared\n\nEach layer has segments, e.g. \"entities/users\".\n\nEach segment has slices \n- ui — everything related to UI display: UI components, date formatters, styles, etc.\n- api — backend interactions: request functions, data types, mappers, etc.\n- model — the data model: schemas, interfaces, stores, and business logic.\n- lib — library code that other modules on this slice need.\n- config — configuration files and feature flags.\n\n# Code Style and Structure\n- Write TypeScript with proper typing for all new code\n- Use functional programming patterns; avoid classes\n- Prefer iteration and modularization over code duplication.\n- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n- Don't use `useEffect` where you can use ref function for dom-dependent things (e.g. ref={el => ...})\n- Don't use `useState` where you can infer from props\n- Use named exports; avoid default exports\n- If you need to create new base component, first look at existing ones in `@/shared/ui`\n\n# Naming Conventions\n- Always look around the codebase for naming conventions, and follow the best practices of the environment (e.g. use `camelCase` variables in JS).\n- Use clear, yet functional names (`searchResults` vs `data`).\n- React components are PascalCase (`IncidentList`).\n- Props for components and hooks are PascalCase and end with `Props`, e.g. `WorkflowBuilderWidgetProps`, return value for hooks is PascalCase and end with `Value`, e.g. `UseIncidentActionsValue` \n- Name the `.ts` file according to its main export: `IncidentList.ts` or `IncidentList.tsx` or `useIncidents.ts`. Pay attention to the case.\n- Avoid `index.ts`, `styles.css`, and other generic names, even if this is the only file in a directory.\n\n# Data Fetching\n- Use useSWR for fetching data, create or extend hooks in @/entities/<entity>/model/use<Entity>.ts which encapsulates fetching logic\n- Create a dedicated keys file @/entities/<entity>/lib/<entity>Keys.ts to manage SWR cache keys. Structure it as an object with methods for different operations:\n```export const entityKeys = {\n  all: \"entityName\",\n  list: (query: QueryParams) => [...],\n  detail: (id: string) => [...],\n  getListMatcher: () => (key: any) => boolean\n}```\n- For query-based endpoints, construct cache keys by joining parameters with \"::\", filtering out falsy values:\n```list: (query: QueryParams) => [\n  entityKeys.all,\n  \"list\",\n  query.param1,\n  query.param2\n].filter(Boolean).join(\"::\")```\n- For create, update, delete actions:\n  - Create or extend hook in @/entities/<entity>/model/use<Entity>Actions.ts\n  - Create a dedicated revalidation hook (e.g., use<Entity>Revalidation.ts) to handle cache invalidation\n  - Revalidate both specific items and list queries after mutations\n  - Include success/error toast notifications for user feedback\n  - Handle file uploads and other complex operations within the actions hook\n\n# UI and Styling\n- Use Tailwind CSS as primary styling solution\n- For non-Tailwind cases:\n  - Use CSS with component-specific files\n  - Namespace under component class (.DropdownMenu)\n  - Follow BEM for modals (.DropdownMenu__modal)\n  - Import styles directly (import './DropdownMenu.css')\n- Replace custom CSS with Tailwind when possible\n\n","frontmatter":{"description":null,"globs":null,"alwaysApply":true},"isInternal":false,"tokens":898,"sizeBytes":3782},{"name":"keep-ui-tests.mdc","path":".cursor/rules/keep-ui-tests.mdc","rawUrl":"https://raw.githubusercontent.com/keephq/keep/HEAD/.cursor/rules/keep-ui-tests.mdc","title":"Cursor Rule: keep-ui-tests","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules and guidelines for writing and running React tests\nglobs: *.spec.tsx, *.test.tsx, *.test.ts, *.spec.ts\n---\n\n# Writing frontend tests\n\nPlace tests in __tests__ folder in the module, e.g. tests for file `/features/workflows/model/useWorkflows.tsx` should be `/features/workflows/models/__tests__/useWorkflows.test.tsx`\n\n# Running frontend tests\n\nPlease run tests with command: npm run test in keep-ui folder\nFor example: cd keep-ui && npm run test","frontmatter":{"description":null,"globs":null,"alwaysApply":true},"isInternal":false,"tokens":128,"sizeBytes":516}],"systemPromptSnippet":"<yakaai_skills repo=\"keephq/keep\">\n<!-- File: .cursor/rules/keep-ui-react-typescript.mdc (Tokens: ~898 | Category: cursor-rule) -->\n---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules for writing frontend code at Keep (React + Typescript)\nglobs: keep-ui/**/*.tsx, keep-ui/**/*.ts\n---\n\nYou are an expert in TypeScript, React, Next.js, SWR, Tailwind, and UX design.\n\n# Achitecture\nUse Feature-Slice Design Convention with modification: instead of `pages` and `app` we use default Next.js route-based folder structure.\n\nExample:\n- entities/\n  - incidents/\n    - api/\n    - lib/\n    - model/\n    - ui/\n\nTop-level folders, called Layers: \n- widgets\n- features\n- entities\n- shared\n\nEach layer has segments, e.g. \"entities/users\".\n\nEach segment has slices \n- ui — everything related to UI display: UI components, date formatters, styles, etc.\n- api — backend interactions: request functions, data types, mappers, etc.\n- model — the data model: schemas, interfaces, stores, and business logic.\n- lib — library code that other modules on this slice need.\n- config — configuration files and feature flags.\n\n# Code Style and Structure\n- Write TypeScript with proper typing for all new code\n- Use functional programming patterns; avoid classes\n- Prefer iteration and modularization over code duplication.\n- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n- Don't use `useEffect` where you can use ref function for dom-dependent things (e.g. ref={el => ...})\n- Don't use `useState` where you can infer from props\n- Use named exports; avoid default exports\n- If you need to create new base component, first look at existing ones in `@/shared/ui`\n\n# Naming Conventions\n- Always look around the codebase for naming conventions, and follow the best practices of the environment (e.g. use `camelCase` variables in JS).\n- Use clear, yet functional names (`searchResults` vs `data`).\n- React components are PascalCase (`IncidentList`).\n- Props for components and hooks are PascalCase and end with `Props`, e.g. `WorkflowBuilderWidgetProps`, return value for hooks is PascalCase and end with `Value`, e.g. `UseIncidentActionsValue` \n- Name the `.ts` file according to its main export: `IncidentList.ts` or `IncidentList.tsx` or `useIncidents.ts`. Pay attention to the case.\n- Avoid `index.ts`, `styles.css`, and other generic names, even if this is the only file in a directory.\n\n# Data Fetching\n- Use useSWR for fetching data, create or extend hooks in @/entities/<entity>/model/use<Entity>.ts which encapsulates fetching logic\n- Create a dedicated keys file @/entities/<entity>/lib/<entity>Keys.ts to manage SWR cache keys. Structure it as an object with methods for different operations:\n```export const entityKeys = {\n  all: \"entityName\",\n  list: (query: QueryParams) => [...],\n  detail: (id: string) => [...],\n  getListMatcher: () => (key: any) => boolean\n}```\n- For query-based endpoints, construct cache keys by joining parameters with \"::\", filtering out falsy values:\n```list: (query: QueryParams) => [\n  entityKeys.all,\n  \"list\",\n  query.param1,\n  query.param2\n].filter(Boolean).join(\"::\")```\n- For create, update, delete actions:\n  - Create or extend hook in @/entities/<entity>/model/use<Entity>Actions.ts\n  - Create a dedicated revalidation hook (e.g., use<Entity>Revalidation.ts) to handle cache invalidation\n  - Revalidate both specific items and list queries after mutations\n  - Include success/error toast notifications for user feedback\n  - Handle file uploads and other complex operations within the actions hook\n\n# UI and Styling\n- Use Tailwind CSS as primary styling solution\n- For non-Tailwind cases:\n  - Use CSS with component-specific files\n  - Namespace under component class (.DropdownMenu)\n  - Follow BEM for modals (.DropdownMenu__modal)\n  - Import styles directly (import './DropdownMenu.css')\n- Replace custom CSS with Tailwind when possible\n\n<!-- File: .cursor/rules/keep-ui-tests.mdc (Tokens: ~128 | Category: cursor-rule) -->\n---\ndescription: \nglobs: \nalwaysApply: true\n---\n---\ndescription: Rules and guidelines for writing and running React tests\nglobs: *.spec.tsx, *.test.tsx, *.test.ts, *.spec.ts\n---\n\n# Writing frontend tests\n\nPlace tests in __tests__ folder in the module, e.g. tests for file `/features/workflows/model/useWorkflows.tsx` should be `/features/workflows/models/__tests__/useWorkflows.test.tsx`\n\n# Running frontend tests\n\nPlease run tests with command: npm run test in keep-ui folder\nFor example: cd keep-ui && npm run test\n</yakaai_skills>"}