dukkani-architecture

النجوم٩

التفرعات٢

آخر تحديث١٩ أبريل ٢٠٢٦ في ١٣:٢٤

Monorepo architecture, app boundaries, package ownership, and cross-domain implementation guidance for Dukkani.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

FindMalek

FindMalek/dukkani

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	dukkani-architecture
description	Monorepo architecture, app boundaries, package ownership, and cross-domain implementation guidance for Dukkani.
triggers	["monorepo architecture","app boundaries","package boundaries","turborepo structure","where should this code live"]

Dukkani Architecture

Use this skill when deciding where code should live, how apps/packages should interact, or how to structure cross-cutting changes.

High-level boundaries

Apps in apps/* own product surfaces and route composition.
Packages in packages/* own reusable logic and shared abstractions.
Apps must not import from other apps.
Shared contracts and schemas should come from package exports, especially @dukkani/common.

App roles

apps/api: API entrypoint for oRPC/OpenAPI/auth/webhooks.
apps/dashboard: Merchant/admin product.
apps/storefront: Customer storefront and checkout.
apps/web: Marketing/public website.

Package roles

Prioritize these packages when placing logic:

@dukkani/common: schemas, entities, shared domain helpers.
@dukkani/orpc: API routers and client contracts.
@dukkani/core: server bootstrap composition (auth + db + env).
@dukkani/db, @dukkani/storage, @dukkani/logger, @dukkani/tracing: infra concerns.

Implementation defaults

Prefer package-level abstractions over copying logic in apps.
Use @dukkani/env for typed env access.
Keep changes scoped; avoid cross-domain refactors unless required.
Follow .cursor/rules/00-project-overview.mdc and per-domain .mdc files as canonical project rules.

Dashboard app

For apps/dashboard folder structure, hooks (api vs controllers), stores, and product form patterns, use .cursor/rules/apps/dashboard.mdc or the dukkani-dashboard Windsurf skill.

المزيد من هذا المستودع

نفس المستودع

tailwind-v4-shadcn

FindMalek/dukkani

Production-tested setup for Tailwind CSS v4 with shadcn/ui, Vite, and React. Use when: initializing React projects with Tailwind v4, setting up shadcn/ui, implementing dark mode, debugging CSS variable issues, fixing theme switching, migrating from Tailwind v3, or encountering color/theming problems. Covers: @theme inline pattern, CSS variable architecture, dark mode with ThemeProvider, component composition, vite.config setup, common v4 gotchas, and production-tested patterns. Keywords: Tailwind v4, shadcn/ui, @tailwindcss/vite, @theme inline, dark mode, CSS variables, hsl() wrapper, components.json, React theming, theme switching, colors not working, variables broken, theme not applying, @plugin directive, typography plugin, forms plugin, prose class, @tailwindcss/typography, @tailwindcss/forms

2026-07-189

dukkani-dashboard

FindMalek/dukkani

apps/dashboard src layout — hooks (api vs controllers), stores, lib, product form.

2026-04-279

dukkani-dashboard

FindMalek/dukkani

apps/dashboard src layout — hooks (api vs controllers), stores, lib, product form.

2026-04-209

dukkani-storefront

FindMalek/dukkani

Storefront app guidance for product browsing, cart, checkout, localization, and oRPC integration in apps/storefront.

2026-04-199

remotion-best-practices

FindMalek/dukkani

Best practices for Remotion - Video creation in React

2026-04-199

dukkani-dashboard

FindMalek/dukkani

apps/dashboard src layout — hooks (api vs controllers), stores, lib, product form.

2026-04-199

name	dukkani-architecture
description	Monorepo architecture, app boundaries, package ownership, and cross-domain implementation guidance for Dukkani.
triggers	["monorepo architecture","app boundaries","package boundaries","turborepo structure","where should this code live"]

Dukkani Architecture

Use this skill when deciding where code should live, how apps/packages should interact, or how to structure cross-cutting changes.

High-level boundaries

Apps in apps/* own product surfaces and route composition.
Packages in packages/* own reusable logic and shared abstractions.
Apps must not import from other apps.
Shared contracts and schemas should come from package exports, especially @dukkani/common.

App roles

apps/api: API entrypoint for oRPC/OpenAPI/auth/webhooks.
apps/dashboard: Merchant/admin product.
apps/storefront: Customer storefront and checkout.
apps/web: Marketing/public website.

Package roles

Prioritize these packages when placing logic:

@dukkani/common: schemas, entities, shared domain helpers.
@dukkani/orpc: API routers and client contracts.
@dukkani/core: server bootstrap composition (auth + db + env).
@dukkani/db, @dukkani/storage, @dukkani/logger, @dukkani/tracing: infra concerns.

Implementation defaults

Prefer package-level abstractions over copying logic in apps.
Use @dukkani/env for typed env access.
Keep changes scoped; avoid cross-domain refactors unless required.
Follow .cursor/rules/00-project-overview.mdc and per-domain .mdc files as canonical project rules.

Dashboard app

For apps/dashboard folder structure, hooks (api vs controllers), stores, and product form patterns, use .cursor/rules/apps/dashboard.mdc or the dukkani-dashboard Windsurf skill.