{"owner":"gitroomhq","repo":"postiz-app","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"This project is Postiz, a tool to schedule social media and chat posts to 28+ channels.\nYou can add posts to the calendar, they will be added into a workflow and posted at the right time.\nYou can find things like:\n- Schedule posts\n- Calendar view\n- Analytics\n- Team management\n- Media library\n\nThis project is a monorepo with a root only package.json of dependencies.\nMade with PNPM.\nWe have 3 important folders\n\n- apps/backend - this is where the API code is (NESTJS)\n- apps/orchestrator - this is temporal, it's for background jobs (NESTJS) it contains all the workflows and activities\n- apps/frontend - this is the code of the frontend (Vite ReactJS)\n- /libraries contains a lot of services shared between backend and orchestrator and frontend components.\n\nWe are using only pnpm, don't use any other dependency manager.\nNever install frontend components from npmjs, focus on writing native components.\n\nThe project uses tailwind 3, before writing any component look at:\n- /apps/frontend/src/app/colors.scss\n- /apps/frontend/src/app/global.scss\n- /apps/frontend/tailwind.config.js\n\nAll the --color-custom* are deprecated, don't use them.\n\nAnd check other components in the system before to get the right design.\n\nWhen working on the backend we need to pass the 3 layers:\nDTO >> Controller >> Service >> Repository (no shortcuts)\nIn some cases we will have\nDTO >> Controller >> Manager >> Service >> Repository.\n\nMost of the server logic should be inside of libs/server.\nThe backend repository is mostly used to write controller, and import files from libs.server.\n\nFor the frontend follow this:\n- Many of the UI components lives in /apps/frontend/src/components/ui\n- Routing is in /apps/frontend/src/app\n- Components are in /apps/frontend/src/components\n- always use SWR to fetch stuff, and use \"useFetch\" hook from /libraries/helpers/src/utils/custom.fetch.tsx\n\nWhen using SWR, each one have to be in a separate hook and must comply with react-hooks/rules-of-hooks, never put eslint-disable-next-line on it.\n\nIt means that this is valid:\nconst useCommunity = () => {\n   return useSWR....\n}\n\nThis is not valid:\nconst useCommunity = () => {\n  return {\n    communities: () => useSWR<CommunitiesListResponse>(\"communities\", getCommunities),\n    providers: () => useSWR<ProvidersListResponse>(\"providers\", getProviders),\n  };\n}\n\n- Linting of the project can run only from the root.\n- Use only pnpm.\n- Never use RAW SQL queries, always use Prisma.\n- The system is in production with many users, if you want to change something, you need to be sure that you are not breaking anything for existing users and a migration might be needed\n- Whenever you generate a PR, PR description, or similar, **always** follow the PR Template (.github/PULL_REQUEST_TEMPLATE.md)\n- Avoid as much as possible creating new files with pure logic of algorithms, it's usually wrong\n- When you write code, make sure that what you add looks like something similar somewhere else in the code, don't make weird patterns\n- When you finished running, run another agents that matches the new code with the existing system code, to see that it looks similar and is not a weird pattern.\n- Workflows files can never be changed if they are already in origin/main, because changing a workflow will fail all its activities, instead create a new workflow with the version, and everywhere the workflow being called, change it to the new workflow version.\n- Workflows activities parameters cannot be changed, as it will break the workflow, if we need to change the parameters, if we need to change the parameters, we need to create a new activity with the new parameters, and then create a new workflow that uses the new activity.\n- Code must always be generic, there can't be a way that a specific logic, let's say facebook or instagram, appear in a file that use a generic logic, instead, we need to edit the interface of the provider, add another function, and then generically call it from the generic code, and then implement the specific logic in the provider implementation. we can't have something like if(facebookProvider) {} inside a non facebook provider file. "},"files":{"CLAUDE.md":"This project is Postiz, a tool to schedule social media and chat posts to 28+ channels.\nYou can add posts to the calendar, they will be added into a workflow and posted at the right time.\nYou can find things like:\n- Schedule posts\n- Calendar view\n- Analytics\n- Team management\n- Media library\n\nThis project is a monorepo with a root only package.json of dependencies.\nMade with PNPM.\nWe have 3 important folders\n\n- apps/backend - this is where the API code is (NESTJS)\n- apps/orchestrator - this is temporal, it's for background jobs (NESTJS) it contains all the workflows and activities\n- apps/frontend - this is the code of the frontend (Vite ReactJS)\n- /libraries contains a lot of services shared between backend and orchestrator and frontend components.\n\nWe are using only pnpm, don't use any other dependency manager.\nNever install frontend components from npmjs, focus on writing native components.\n\nThe project uses tailwind 3, before writing any component look at:\n- /apps/frontend/src/app/colors.scss\n- /apps/frontend/src/app/global.scss\n- /apps/frontend/tailwind.config.js\n\nAll the --color-custom* are deprecated, don't use them.\n\nAnd check other components in the system before to get the right design.\n\nWhen working on the backend we need to pass the 3 layers:\nDTO >> Controller >> Service >> Repository (no shortcuts)\nIn some cases we will have\nDTO >> Controller >> Manager >> Service >> Repository.\n\nMost of the server logic should be inside of libs/server.\nThe backend repository is mostly used to write controller, and import files from libs.server.\n\nFor the frontend follow this:\n- Many of the UI components lives in /apps/frontend/src/components/ui\n- Routing is in /apps/frontend/src/app\n- Components are in /apps/frontend/src/components\n- always use SWR to fetch stuff, and use \"useFetch\" hook from /libraries/helpers/src/utils/custom.fetch.tsx\n\nWhen using SWR, each one have to be in a separate hook and must comply with react-hooks/rules-of-hooks, never put eslint-disable-next-line on it.\n\nIt means that this is valid:\nconst useCommunity = () => {\n   return useSWR....\n}\n\nThis is not valid:\nconst useCommunity = () => {\n  return {\n    communities: () => useSWR<CommunitiesListResponse>(\"communities\", getCommunities),\n    providers: () => useSWR<ProvidersListResponse>(\"providers\", getProviders),\n  };\n}\n\n- Linting of the project can run only from the root.\n- Use only pnpm.\n- Never use RAW SQL queries, always use Prisma.\n- The system is in production with many users, if you want to change something, you need to be sure that you are not breaking anything for existing users and a migration might be needed\n- Whenever you generate a PR, PR description, or similar, **always** follow the PR Template (.github/PULL_REQUEST_TEMPLATE.md)\n- Avoid as much as possible creating new files with pure logic of algorithms, it's usually wrong\n- When you write code, make sure that what you add looks like something similar somewhere else in the code, don't make weird patterns\n- When you finished running, run another agents that matches the new code with the existing system code, to see that it looks similar and is not a weird pattern.\n- Workflows files can never be changed if they are already in origin/main, because changing a workflow will fail all its activities, instead create a new workflow with the version, and everywhere the workflow being called, change it to the new workflow version.\n- Workflows activities parameters cannot be changed, as it will break the workflow, if we need to change the parameters, if we need to change the parameters, we need to create a new activity with the new parameters, and then create a new workflow that uses the new activity.\n- Code must always be generic, there can't be a way that a specific logic, let's say facebook or instagram, appear in a file that use a generic logic, instead, we need to edit the interface of the provider, add another function, and then generically call it from the generic code, and then implement the specific logic in the provider implementation. we can't have something like if(facebookProvider) {} inside a non facebook provider file. "},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"This project is Postiz, a tool to schedule social media and chat posts to 28+ channels.\nYou can add posts to the calendar, they will be added into a workflow and posted at the right time.\nYou can find things like:\n- Schedule posts\n- Calendar view\n- Analytics\n- Team management\n- Media library\n\nThis project is a monorepo with a root only package.json of dependencies.\nMade with PNPM.\nWe have 3 important folders\n\n- apps/backend - this is where the API code is (NESTJS)\n- apps/orchestrator - this is temporal, it's for background jobs (NESTJS) it contains all the workflows and activities\n- apps/frontend - this is the code of the frontend (Vite ReactJS)\n- /libraries contains a lot of services shared between backend and orchestrator and frontend components.\n\nWe are using only pnpm, don't use any other dependency manager.\nNever install frontend components from npmjs, focus on writing native components.\n\nThe project uses tailwind 3, before writing any component look at:\n- /apps/frontend/src/app/colors.scss\n- /apps/frontend/src/app/global.scss\n- /apps/frontend/tailwind.config.js\n\nAll the --color-custom* are deprecated, don't use them.\n\nAnd check other components in the system before to get the right design.\n\nWhen working on the backend we need to pass the 3 layers:\nDTO >> Controller >> Service >> Repository (no shortcuts)\nIn some cases we will have\nDTO >> Controller >> Manager >> Service >> Repository.\n\nMost of the server logic should be inside of libs/server.\nThe backend repository is mostly used to write controller, and import files from libs.server.\n\nFor the frontend follow this:\n- Many of the UI components lives in /apps/frontend/src/components/ui\n- Routing is in /apps/frontend/src/app\n- Components are in /apps/frontend/src/components\n- always use SWR to fetch stuff, and use \"useFetch\" hook from /libraries/helpers/src/utils/custom.fetch.tsx\n\nWhen using SWR, each one have to be in a separate hook and must comply with react-hooks/rules-of-hooks, never put eslint-disable-next-line on it.\n\nIt means that this is valid:\nconst useCommunity = () => {\n   return useSWR....\n}\n\nThis is not valid:\nconst useCommunity = () => {\n  return {\n    communities: () => useSWR<CommunitiesListResponse>(\"communities\", getCommunities),\n    providers: () => useSWR<ProvidersListResponse>(\"providers\", getProviders),\n  };\n}\n\n- Linting of the project can run only from the root.\n- Use only pnpm.\n- Never use RAW SQL queries, always use Prisma.\n- The system is in production with many users, if you want to change something, you need to be sure that you are not breaking anything for existing users and a migration might be needed\n- Whenever you generate a PR, PR description, or similar, **always** follow the PR Template (.github/PULL_REQUEST_TEMPLATE.md)\n- Avoid as much as possible creating new files with pure logic of algorithms, it's usually wrong\n- When you write code, make sure that what you add looks like something similar somewhere else in the code, don't make weird patterns\n- When you finished running, run another agents that matches the new code with the existing system code, to see that it looks similar and is not a weird pattern.\n- Workflows files can never be changed if they are already in origin/main, because changing a workflow will fail all its activities, instead create a new workflow with the version, and everywhere the workflow being called, change it to the new workflow version.\n- Workflows activities parameters cannot be changed, as it will break the workflow, if we need to change the parameters, if we need to change the parameters, we need to create a new activity with the new parameters, and then create a new workflow that uses the new activity.\n- Code must always be generic, there can't be a way that a specific logic, let's say facebook or instagram, appear in a file that use a generic logic, instead, we need to edit the interface of the provider, add another function, and then generically call it from the generic code, and then implement the specific logic in the provider implementation. we can't have something like if(facebookProvider) {} inside a non facebook provider file. ","category":"root","tokens":1033}]}