{"name":"Neexo AI Hub","url":"https://awesome.neexo.dk","generatedAt":"2026-05-16T12:01:25.534Z","categories":[{"category":"agents","entries":[{"slug":"code-reviewer","category":"agents","data":{"name":"Neexo Code Reviewer","description":"A focused reviewer agent for Neexo projects that prioritizes bugs, security issues, tenant isolation, production risk, and missing validation over style feedback.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","tags":["code-review","security","neexo"],"featured":true},"content":"\n## Overview\n\nUse this agent when a change needs a high-signal review before merge. It should inspect only the diff or explicitly scoped files, then report issues that matter in production.\n\n## Review Focus\n\n- Logic bugs and edge cases\n- Security and privacy risks\n- Tenant or organization isolation\n- Data loss and migration risk\n- Missing validation or tests\n- Deployment and runtime failures\n\n## Cost Discipline\n\nFor routine reviews, use scoped diffs or selected files. Avoid broad repository scans unless the task is explicitly a repository-wide audit.\n","lastUpdated":"2026-05-16T11:43:58+02:00"},{"slug":"consensus-review","category":"agents","data":{"name":"Neexo Consensus Review","description":"A multi-perspective review pattern for high-risk changes where architecture, security, performance, and UX concerns need separate review passes.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","tags":["code-review","architecture","high-risk"],"featured":false},"content":"\n## Overview\n\nUse consensus review sparingly for high-risk changes such as auth, billing, database schema, tenant isolation, production deployment, or large cross-domain refactors.\n\n## When to Use\n\n- Auth or billing logic changes\n- Database schema migrations affecting production data\n- Tenant isolation boundary changes\n- Large refactors spanning 5+ files across domains\n- Security-sensitive changes (CORS, CSP, secrets handling)\n\n## Cost Warning\n\nMulti-perspective review can be expensive under AI Credit billing. Prefer a single reviewer for normal PRs. Use consensus review only when the risk justifies the cost.\n\n## Review Perspectives\n\nEach pass focuses on one concern:\n\n| Pass | Focus | Key Questions |\n|------|-------|---------------|\n| **Architecture** | Structure, boundaries, coupling | Does this change respect module boundaries? Will it cause cascading changes? |\n| **Security** | Auth, secrets, injection, OWASP | Are role checks preserved? Is user input validated? |\n| **Performance** | Queries, caching, bundle size | Are there N+1 queries? Does this affect page load? |\n| **UX** | User flow, error states, accessibility | Does the happy path work? Are error states handled? |\n\n## How to Invoke\n\n```markdown\nReview this PR from four perspectives: architecture, security, performance, and UX.\nFor each perspective, list findings with severity (critical/high/medium/low),\nthe affected file, and a specific recommendation. Dismiss style-only findings.\n```\n\n## Output\n\nEach reviewer should provide concrete findings with:\n- **Severity**: critical / high / medium / low\n- **Evidence**: specific code reference or line\n- **Affected file**: path to the file\n- **Recommendation**: specific fix, not vague advice\n\nDismiss style-only or subjective findings that do not affect correctness, security, or performance.\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"studio-editor","category":"agents","data":{"name":"Neexo Studio Editor Agent","description":"A specialized agent pattern for 3D configurator studio work, including editor flows, machine configuration, asset metadata, and viewer handoff.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","tags":["configurator","3d","studio"],"featured":false},"content":"\n## Overview\n\nUse this agent pattern for studio-facing configurator work where UI state, 3D metadata, asset references, and publishing workflows meet.\n\nThe agent should behave like an editor engineer, not a generic UI helper. It needs to understand the split between a mutable studio workspace and a stable published viewer state, and it should preserve that boundary whenever it changes data models, editor panels, preview rendering, or publish behavior.\n\n## Responsibilities\n\n- Inspect shared schemas, editor state stores, asset metadata types, and viewer read models before changing behavior\n- Keep draft, preview, and published configuration states distinct\n- Prefer deterministic serialization for machine, variant, material, and scene settings\n- Preserve undo/redo and dirty-state semantics when editing studio controls\n- Treat asset paths, thumbnails, CAD/GLB metadata, and generated previews as references unless the task explicitly requires binary asset work\n- Validate that published viewer payloads remain backward compatible\n\n## Editor State Pattern\n\n1. Identify the canonical source of truth: schema, store, URL state, database row, or generated artifact\n2. Update derived editor state through existing actions or reducers\n3. Keep transient UI state local to the panel or tool surface\n4. Ensure publish/export code receives validated data, not raw form state\n5. Add focused tests or smoke checks around serialization, preview loading, and publish handoff\n\n## Asset Workflow\n\n- Read metadata and manifests before opening large geometry, texture, or render files\n- Do not duplicate assets to solve reference bugs; fix the reference or manifest mapping\n- Preserve units, coordinate systems, orientation, pivot assumptions, and material names\n- Keep generated thumbnails and previews reproducible from the source asset pipeline\n- Call out when a change requires re-exporting assets from Blender, Unity, or an external configurator tool\n\n## Publishing Handoff\n\nBefore changing publish behavior, verify:\n\n- which fields are draft-only and which fields are viewer-facing\n- whether the viewer supports older published payloads\n- whether generated bundles include asset fingerprints or version metadata\n- how errors are surfaced to studio users during validation or upload\n- how rollback works when a publish partially succeeds\n\n## Guardrails\n\n- Read schemas and shared types before changing editor behavior\n- Prefer asset metadata over loading binary files\n- Keep studio write paths separate from published viewer read paths\n- Validate changes with focused type checks and browser smoke tests\n- Do not silently change published payload shape without migration or compatibility notes\n","lastUpdated":"2026-05-16T13:53:13+02:00"},{"slug":"worker","category":"agents","data":{"name":"Neexo Worker Agent","description":"A background-job agent pattern for queue processing, render jobs, asset pipelines, and other asynchronous workflows in Neexo projects.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","tags":["worker","jobs","automation"],"featured":false},"content":"\n## Overview\n\nUse this agent pattern for changes to background jobs, workers, queue handlers, render pipelines, or other asynchronous task processors.\n\n## When to Use\n\n- Editing queue consumer/producer code\n- Adding or modifying scheduled jobs (cron, intervals)\n- Changing render pipeline steps or asset post-processing\n- Reviewing retry logic, dead-letter queues, or failure recovery\n\n## Guardrails\n\n- **Idempotency** — verify that reprocessing the same job produces the same result without side effects\n- **Retry behavior** — check retry limits, exponential backoff, and dead-letter handling\n- **Failure paths** — ensure failed jobs log actionable context (job ID, attempt count, error) without leaking secrets or customer data\n- **Payload schemas** — keep job payloads versioned and narrow; avoid passing entire database rows\n- **Timeouts** — set explicit timeouts on job execution to prevent zombie workers\n\n## Validation\n\n- Run the smallest available worker or queue test before broader integration tests\n- For render jobs, validate with a single lightweight asset before triggering full batch renders\n- Check that failed jobs appear in monitoring/alerting and are not silently dropped\n\n## Example Agent Instruction\n\n```markdown\nYou are a worker-agent. Before modifying any job handler:\n1. Read the job schema and check recent processing logs\n2. Verify idempotency — would rerunning this job cause duplicate side effects?\n3. Confirm retry/failure behavior is tested\n4. Keep the change scoped — do not refactor unrelated worker code\n```\n","lastUpdated":"2026-05-16T12:39:57+02:00"}]},{"category":"instructions","entries":[{"slug":"cost-awareness","category":"instructions","data":{"name":"Cost-Aware AI Instructions","description":"Always-on guidance for keeping AI context small, avoiding expensive agent sessions, and classifying tasks before broad edits.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*"],"tags":["cost","ai-credits","guardrails"],"featured":true},"content":"\n## Overview\n\nThese instructions are the baseline for AI-assisted work in Neexo repositories. They help agents keep context small, avoid broad scans, and treat high-risk changes as planning tasks before implementation.\n\n## Core Rule\n\nNever combine an expensive model, large repository context, and a vague task. That pattern is the fastest route to unnecessary AI Credit usage.\n\n## Task Classes\n\n- LOW: 1-3 files, clear local change\n- MEDIUM: 3-7 files or uncertain scope\n- HIGH: auth, security, billing, database schema, tenant isolation, deployment, AI/model usage, or broad architecture changes\n\nLOW tasks can be edited directly. MEDIUM tasks should start with a short plan. HIGH tasks should stop after analysis unless explicitly approved.\n\n## Tooling Rule\n\nPrefer local CLI tools over MCP servers when a suitable CLI exists. CLIs are often cheaper for context because the agent can ask for `--help`, inspect only the relevant command, and receive compact output.\n\nUse MCP when the task needs interactive remote capabilities, richer API context, or cross-system access that the CLI does not provide.\n\nIf an approved Neexo Windows AI toolbelt CLI is missing and the task benefits from it, install it with `winget`, verify it with `--version`, and continue. Ask before installing other tools or modifying PowerShell profile files.\n\nExample: prefer GitHub CLI (`gh`) for routine issue, PR, repo, and workflow queries. Use GitHub MCP when the work benefits from persistent API tooling or agent-managed GitHub operations.\n","lastUpdated":"2026-05-16T11:43:58+02:00"},{"slug":"clerk-auth","category":"instructions","data":{"name":"Clerk Authentication","description":"Authentication patterns for Next.js apps using Clerk, including middleware setup, role-based access, organization scoping, and dev-mode fallbacks.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ts,tsx}","**/proxy.ts","**/middleware.ts"],"tags":["auth","clerk","nextjs"],"featured":false},"content":"\n## Overview\n\nClerk provides authentication, user management, and organization-based RBAC for Next.js apps. In Neexo projects, Clerk handles sign-in, sign-up, organization switching, and role enforcement.\n\n## Next.js 16 Middleware\n\nNext.js 16 uses `proxy.ts` (named `proxy` export) instead of `middleware.ts`:\n\n```tsx\n// src/proxy.ts\nimport { clerkMiddleware, createRouteMatcher } from \"@clerk/nextjs/server\";\n\nconst isPublicRoute = createRouteMatcher([\"/\", \"/sign-in(.*)\", \"/sign-up(.*)\", \"/api/public(.*)\"]);\n\nexport const proxy = clerkMiddleware(async (auth, request) => {\n if (!isPublicRoute(request)) {\n await auth.protect();\n }\n});\n\nexport const config = {\n matcher: [\"/((?!_next|[^?]*\\\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)\"],\n};\n```\n\n## Auth Context Helper\n\n```tsx\nimport { auth } from \"@clerk/nextjs/server\";\n\nexport async function getAuthContext() {\n const { userId, orgId, orgRole } = await auth();\n \n if (!userId || !orgId) {\n throw new Error(\"Unauthorized\");\n }\n \n return { userId, orgId, orgRole };\n}\n```\n\n## Role-Based Access\n\n```tsx\nconst STUDIO_ROLES = new Set([\"org:admin\", \"org:editor\"]);\n\nexport function hasStudioAccess(orgRole: string | undefined) {\n return orgRole ? STUDIO_ROLES.has(orgRole) : false;\n}\n\n// In an API route or server action:\nconst { orgRole } = await getAuthContext();\nif (!hasStudioAccess(orgRole)) {\n return new Response(\"Forbidden\", { status: 403 });\n}\n```\n\n## Organization Scoping\n\nEvery database query must filter by organization:\n\n```tsx\n// ✅ Correct — always scope by orgId\nconst items = await db.select().from(machines).where(eq(machines.orgId, orgId));\n\n// ❌ Wrong — returns data across all organizations\nconst items = await db.select().from(machines);\n```\n\n## Dev Mode Fallback\n\nFor local development without Clerk keys:\n\n```tsx\nconst DEV_USER_ID = \"dev-user\";\nconst DEV_ORG_ID = \"dev-org\";\nconst DEV_ORG_ROLE = \"org:admin\";\n\nexport async function getAuthContext() {\n if (process.env.NODE_ENV === \"development\" && !process.env.CLERK_SECRET_KEY) {\n return { userId: DEV_USER_ID, orgId: DEV_ORG_ID, orgRole: DEV_ORG_ROLE };\n }\n // ... real auth\n}\n```\n\n## Common Pitfalls\n\n- Do not call `auth()` in client components — it's server-only\n- Use `useUser()` and `useOrganization()` for client-side auth state\n- Wrap Clerk components (UserButton, OrganizationSwitcher) in safe client wrappers\n- Never expose `CLERK_SECRET_KEY` to the client — only `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`\n","lastUpdated":"2026-05-16T12:55:32+02:00"},{"slug":"cli-first-tooling","category":"instructions","data":{"name":"CLI-First Tooling Instructions","description":"Guidance for preferring compact local CLI tools over MCP servers when they provide the same capability with less context and lower AI cost.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ps1,sh,bash,zsh,fish,bat,cmd,json,yml,yaml,md}"],"tags":["cli","mcp","cost"],"featured":false},"content":"\n## Overview\n\nAgents should prefer local CLI tools when they are available and suitable for the task. A CLI can usually explain itself through `--help`, expose focused subcommands, and return compact output.\n\n## Rule\n\nUse a CLI first when:\n\n- the task is narrow and command-based\n- the CLI is already installed\n- `--help` or `help ` gives enough guidance\n- the output can be filtered or scoped\n\nUse MCP when:\n\n- the task needs richer remote API access\n- the agent benefits from structured tool calls\n- the task spans several resources or systems\n- the CLI is missing important capabilities\n\n## Installation\n\nIf an approved Neexo Windows AI toolbelt CLI is missing, install it with `winget`, verify it with `--version`, and continue. Ask before installing other tools or modifying PowerShell profile files.\n\nExample: use GitHub CLI (`gh`) for routine issue, PR, repository, and workflow operations. Use GitHub MCP when persistent GitHub API tooling or richer agent-managed operations are needed.\n\n## Preferred Commands\n\n| Need | Prefer | Example |\n|---|---|---|\n| Find files | `rg --files` or `fd` | `rg --files content plugins` |\n| Search text | `rg` | `rg \"copilot plugin\" docs content` |\n| Inspect JSON | `jq` | `jq '.plugins[].name' .github/plugin/marketplace.json` |\n| Inspect YAML | `yq` | `yq '.includes.instructions' content/plugins/neexo-guardrails.md` |\n| GitHub routine work | `gh` | `gh pr view --json title,files,reviews` |\n| AST-aware code search | `sg` | `sg -p 'useEffect($$$)' website/src` |\n| Repo size overview | `tokei` | `tokei website/src content` |\n\n## Output Rules\n\n- Scope commands to the smallest folder or file set that can answer the question.\n- Filter large output with `--json`, `--fields`, `Select-Object`, `jq`, or `rg -n`.\n- Prefer read-only commands before commands that write files, open browser sessions, or call remote APIs.\n- For interactive commands, answer one prompt at a time and never route secrets through chat.\n","lastUpdated":"2026-05-16T13:53:13+02:00"},{"slug":"figma-hmi-standards","category":"instructions","data":{"name":"Figma HMI Design Standards","description":"Design-to-code standards for Figma-based HMI (Human-Machine Interface) projects — Figma plugin architecture, monorepo conventions, OPC-UA integration, and runtime rendering patterns.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.ts","**/*.tsx"],"tags":["figma","hmi","monorepo","typescript"],"featured":false},"content":"\n## Monorepo Structure\n\nHMI compiler projects use a pnpm monorepo with `@figma-hmi/*` aliases:\n\n| Package | Purpose |\n|---|---|\n| `schema` | Domain types + Zod validation (base dependency) |\n| `design` | Design document structure + CSS rendering |\n| `protocol` | WebSocket message schemas |\n| `runtime-core` | Pure business logic — no React |\n| `runtime-web` | React UI + connectors (mock, WebSocket) |\n| `compiler` | CLI to package into deployable artifact |\n| `figma-plugin` | Figma plugin UI |\n| `opcua-gateway` | OPC-UA server bridge |\n\nCross-package imports use `@figma-hmi/*` aliases. Internal deps use `workspace:*` protocol.\n\n## TypeScript Rules\n\n- Target ES2022, strict mode, ESM (`\"type\": \"module\"`)\n- Explicit `type` imports: `import type { Foo } from '...'`\n- `node:` prefix for Node.js built-ins: `import { resolve } from 'node:path'`\n- Define explicit return types on functions\n- Discriminated unions + Zod schemas for domain types; infer via `z.infer`\n\n## React (Runtime Web)\n\n- React 19, functional components only\n- Wrap presentational components in `memo()` with callback props\n- State: local `useState` only — no global state manager\n- Async effects with cancellation: `let cancelled = false` + cleanup return\n- Inline styles via `CSSProperties` — no Tailwind, no CSS modules\n- Props: explicit interface (`interface FooProps { ... }`)\n\n## Figma Plugin Architecture\n\nThe Figma plugin bridges the design tool with the HMI compiler:\n\n1. **Read**: Extract component hierarchy, styles, variables, and interactive states from Figma\n2. **Transform**: Convert to the `@figma-hmi/schema` format (Zod-validated)\n3. **Bundle**: `_generated-project-bundle.ts` is auto-generated from the Figma design\n4. **Deploy**: Compiler packages into Docker container with OPC-UA gateway\n\nRebuild runtime-web before regenerating the bundle:\n```bash\ncorepack pnpm build\nnode apps/figma-plugin/scripts/build.mjs\n```\n\n## OPC-UA Integration\n\n- The `opcua-gateway` bridges HMI runtime to industrial OPC-UA servers\n- WebSocket protocol defined in `@figma-hmi/protocol` with Zod schemas\n- All message types are discriminated unions for type safety\n- Gateway runs as Docker container alongside the compiled HMI frontend\n\n## Testing\n\n- Vitest with `describe`/`it` syntax\n- Test files in `test/` folder per package, named `*.test.ts`\n- React tests: `createRoot` + `act()`, DOM queries via `querySelector`\n- Run per-package: `corepack pnpm --filter test`\n\n## Code Style\n\n- PascalCase: components, types, schemas\n- camelCase: functions, variables, properties\n- `as const` arrays for enum-like values\n- Section headers: `// ─── Section Name ───────────────`\n- Pure functions, immutable patterns — return new objects, don't mutate\n","lastUpdated":"2026-05-16T13:04:56+02:00"},{"slug":"blender-python","category":"instructions","data":{"name":"Neexo Blender Python Instructions","description":"Guidance for Blender Python scripts, add-ons, subprocess rendering, generated assets, and 3D pipeline automation.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.py"],"tags":["blender","python","3d"],"featured":false},"content":"\n## Overview\n\nUse these instructions for Blender add-ons, render-studio automation, and configurator asset pipelines.\n\n## API and Scripting Rules\n\n- Use `bpy.data`, `bpy.context`, and `bpy.ops` through the stable API — avoid internal/undocumented modules\n- Register operators and panels with proper `bl_idname`, `bl_label`, and `bl_options`\n- Always provide `poll()` methods on operators to prevent invalid context execution\n- Use `bpy.app.handlers` for persistent callbacks; clean up handlers on add-on unregister\n\n## Asset Pipeline Rules\n\n- Treat large GLB, EXR, HDR, and render files as assets, not chat context — summarize metadata instead\n- Prefer metadata summaries and small config files before reading generated output\n- Use relative paths in `.blend` files for portability across machines\n\n## Subprocess and Rendering\n\n- Keep subprocess execution deterministic and logged without exposing secrets\n- Use `--background` and `--python` flags for headless Blender rendering:\n ```bash\n blender --background scene.blend --python render_script.py -- --output /tmp/render\n ```\n- Parse arguments after `--` using `sys.argv[sys.argv.index(\"--\") + 1:]`\n- Validate with focused scripts or tests before broad render runs\n\n## Common Pitfalls\n\n- Do not call `bpy.ops` outside the correct context — use context overrides or `temp_override()`\n- Do not block the UI thread with long operations — use modal operators or background threads for heavy work\n- Always check `bpy.app.version` when targeting multiple Blender versions\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"drizzle-database","category":"instructions","data":{"name":"Neexo Drizzle Database Instructions","description":"Database and migration guidance for Drizzle ORM, Drizzle Kit, Neon, tenant-scoped queries, atomic schema changes, and production-safe data access.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*{schema,migration,db,sql,drizzle,neon}*"],"tags":["database","drizzle","neon"],"featured":false},"content":"\n## Overview\n\nDatabase work is high-risk in Neexo projects because schema changes often combine tenant scoping, production data, and generated migrations.\n\n## Schema and Migration Rules\n\n- Inspect the relevant schema, migration, query, or action before changing database logic\n- Keep schema changes, generated SQL, and dependent code in the **same commit** — never split across commits\n- Avoid destructive migrations by default — prefer additive changes (new columns, new tables)\n- Use `drizzle-kit generate` to create migration SQL after schema edits\n- Use `drizzle-kit push` for local development against throwaway databases\n- Use `drizzle-kit migrate` for production deployments with migration tracking\n\n## Drizzle Kit Workflow\n\n```bash\n# 1. Edit schema file (e.g. src/db/schema.ts)\n# 2. Push to local dev database\nnpx drizzle-kit push\n\n# 3. Generate migration SQL for production\nnpx drizzle-kit generate\n\n# 4. Commit schema + migration + code together\ngit add -A && git commit -m \"feat(db): add user preferences table\"\n```\n\n## Query Patterns\n\n- Preserve organization, customer, and tenant filters on every query — never return unscoped data\n- Use Drizzle's type-safe query builder; avoid raw SQL unless performance requires it\n- Use `drizzle-kit studio` to inspect data during development — never query production directly\n- Prefer soft delete (`deletedAt` timestamp) for financial, audit, and compliance data\n\n## Common Pitfalls\n\n- Do not run `drizzle-kit push` against production — it applies changes without migration tracking\n- Do not rename columns in production without a two-step migration (add new → migrate data → drop old)\n- Do not use `drizzle-kit drop` without explicit team approval\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"nextjs-conventions","category":"instructions","data":{"name":"Neexo Next.js Conventions","description":"Shared App Router, React 19, TypeScript, UI, and validation conventions for Neexo's Next.js 16 projects.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ts,tsx}","**/app/**/*.tsx"],"tags":["nextjs","react","typescript"],"featured":false},"content":"\n## Overview\n\nNeexo projects default to Next.js 16 App Router patterns, server components, narrow TypeScript boundaries, and existing local UI conventions.\n\n## Server vs Client Components\n\n- Prefer server components unless hooks, browser APIs, or event handlers require client components\n- Keep server/client boundaries explicit — mark client components with `\"use client\"` at the top\n- Use server actions for mutations; do not create API routes for simple form submissions\n\n## Next.js 16 Specifics\n\n- `params` and `searchParams` are now async in route components — always `await` them:\n ```tsx\n export default async function Page({ params }: { params: Promise<{ slug: string }> }) {\n const { slug } = await params\n }\n ```\n- `cookies()` and `headers()` from `next/headers` are async — `await` before reading\n- Turbopack is the default bundler in development — do not add Webpack-specific config unless required for production\n- Use the `use` hook from React 19 to unwrap promises in client components\n- Use `\"use cache\"` for fine-grained caching instead of relying solely on route segment config\n\n## TypeScript and Code Style\n\n- Avoid `any` unless justified at an integration boundary\n- Reuse existing components, hooks, utilities, and design tokens\n- Add dependencies only when the existing stack cannot reasonably solve the problem\n- Prefer `satisfies` for type narrowing of config objects\n\n## Patterns to Avoid\n\n- Do not use `getServerSideProps` or `getStaticProps` — these are Pages Router patterns\n- Do not wrap server components in unnecessary client wrappers\n- Do not use `useEffect` for data fetching — fetch in server components or use server actions\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"playwright-testing","category":"instructions","data":{"name":"Neexo Playwright Testing Instructions","description":"Focused E2E testing guidance for Playwright specs, browser smoke tests, selectors, screenshots, and validation commands.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*{test,spec,e2e,playwright}*.{ts,tsx,js,jsx}"],"tags":["testing","playwright","e2e"],"featured":false},"content":"\n## Overview\n\nUse these instructions when adding or reviewing browser tests. Prefer focused tests over full-suite runs for local logic.\n\n## Locator Strategy\n\nUse stable, user-visible locators in priority order:\n\n1. `getByRole('button', { name: 'Submit' })` — best for accessibility\n2. `getByText('Welcome')` — for visible text content\n3. `getByTestId('checkout-form')` — when role/text is ambiguous\n4. `locator('[data-testid=\"...\"]')` — fallback for complex selectors\n\nAvoid fragile selectors: `nth-child`, deep CSS paths, auto-generated class names.\n\n## Test Structure\n\n- One assertion per logical check — avoid mega-tests that assert 10 things\n- Use `test.describe` to group related scenarios\n- Use `test.beforeEach` for shared navigation, not repeated `goto()` calls\n- Name tests by user behavior: `\"user can add item to cart\"`, not `\"test button click\"`\n\n## Reliability Rules\n\n- Never use `page.waitForTimeout()` — use `expect(locator).toBeVisible()` or `waitForResponse()`\n- Check console errors for UI changes: `page.on('console', ...)`\n- Use `expect(page).toHaveURL()` instead of checking raw URL strings\n- Run the smallest relevant test first — `npx playwright test path/to/file.spec.ts`\n\n## Screenshots and Visual Testing\n\n- Use `await expect(page).toHaveScreenshot()` for visual regression\n- Avoid `whileInView` animations and lazy-loaded images in screenshot tests — they produce flaky baselines\n- Use `page.setViewportSize()` for consistent screenshot dimensions\n\n## Patterns to Avoid\n\n- Timing-based waits (`setTimeout`, `waitForTimeout`)\n- Selectors coupled to CSS framework class names (`.css-1a2b3c`)\n- Tests that depend on external API state without mocking\n- Full test suite runs for single-file logic changes\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"security-owasp","category":"instructions","data":{"name":"Neexo Security and OWASP Instructions","description":"Security review guidance covering OWASP Top 10 risks, auth boundaries, secrets handling, tenant isolation, and production-safe configuration.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ts,tsx,js,jsx,json,yml,yaml,env,md}"],"tags":["security","owasp","privacy"],"featured":false},"content":"\n## Overview\n\nUse these instructions when editing code or configuration that can affect authentication, authorization, tenant boundaries, storage permissions, secrets, billing, or production deployment.\n\n## OWASP Top 10 Awareness\n\nWatch for these categories in every code change:\n\n1. **Broken Access Control** — verify role checks and tenant scoping on every endpoint and server action\n2. **Cryptographic Failures** — never hardcode secrets, use environment variables and proper key management\n3. **Injection** — parameterize all database queries; never interpolate user input into SQL, shell commands, or templates\n4. **Insecure Design** — validate business logic constraints server-side, not only in the UI\n5. **Security Misconfiguration** — review CORS, CSP, exposed headers, verbose error messages, and default credentials\n6. **Vulnerable Components** — audit dependencies regularly; keep frameworks and libraries updated\n7. **Authentication Failures** — enforce strong session management, rate limiting, and MFA where available\n8. **Data Integrity Failures** — verify signatures, checksums, and pipeline integrity for CI/CD and software updates\n9. **Logging and Monitoring Gaps** — log security events but never log secrets, tokens, or PII\n10. **Server-Side Request Forgery (SSRF)** — validate and restrict outbound URLs; do not allow user input to control fetch targets\n\n## Required Checks\n\n- Do not expose secrets, tokens, keys, signed URLs, or private customer data\n- Preserve role checks and organization/customer scoping on every mutation\n- Keep server-side validation in place — never rely solely on client-side checks\n- Avoid logging sensitive values (tokens, passwords, PII)\n- Call out any weakening of security controls explicitly in PR descriptions\n\n## Patterns to Reject\n\n- `dangerouslySetInnerHTML` with unsanitized user input\n- String concatenation in SQL queries instead of parameterized statements\n- Disabled CSRF protection without documented justification\n- Broad CORS origins (`*`) in production\n- Secrets committed to version control, even in \"test\" files\n","lastUpdated":"2026-05-16T12:39:57+02:00"},{"slug":"next-intl","category":"instructions","data":{"name":"next-intl Internationalization","description":"Conventions for multi-language Next.js apps using next-intl, including translation patterns, locale detection, and common pitfalls.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ts,tsx}","**/messages/**"],"tags":["i18n","nextjs","next-intl"],"featured":false},"content":"\n## Overview\n\nnext-intl provides type-safe internationalization for Next.js App Router apps. Neexo projects typically use Danish as the primary language with English and optionally German as secondaries.\n\n## Setup\n\nTranslation files live in `messages/` as JSON:\n\n```\nmessages/\n da.json # Danish (primary source)\n en.json # English\n de.json # German (optional)\n```\n\n## Translation Pattern\n\n```tsx\n\"use client\";\n\nimport { useTranslations } from \"next-intl\";\n\nexport default function HeroSection() {\n const t = useTranslations(\"hero\");\n return (\n
\n

{t(\"title\")}

\n

{t(\"description\")}

\n
\n );\n}\n```\n\n## Rules\n\n- **Danish is the source language** — always write Danish text first, then translate to other languages\n- Use `useTranslations()` hook in client components — never inline text strings\n- Namespace translations by feature/page: `hero.title`, `contact.submit`, `nav.home`\n- Keep translation keys in kebab-case or camelCase — be consistent within the project\n\n## Message File Structure\n\n```json\n{\n \"nav\": {\n \"home\": \"Forside\",\n \"about\": \"Om os\",\n \"contact\": \"Kontakt\"\n },\n \"hero\": {\n \"title\": \"Industriel 3D-visualisering\",\n \"description\": \"Vi omdanner tekniske CAD-data til visuelle oplevelser\"\n }\n}\n```\n\n## Language Switching\n\nFor apps without locale in the URL (single-domain approach):\n\n```tsx\n\"use client\";\n\nimport { useLocale } from \"next-intl\";\n\nfunction LanguageSwitcher() {\n const locale = useLocale();\n // Switch by updating cookie or context\n}\n```\n\n## Danish Text Rules\n\n- Use proper Danish characters: æ, ø, å — never ae, oe, aa\n- Do not use em-dashes (—) in translations — rephrase with commas or \"herunder\"\n- Avoid AI/corporate buzzwords: \"transformér\", \"unik\", \"robust\", \"gnidningsfrit\"\n- Write naturally as a Dane would speak\n\n## Common Pitfalls\n\n- Do not use `useTranslations()` in Server Components — use `getTranslations()` instead\n- Keep `defaultLocale` set to `\"da\"` in the i18n config\n- Ensure all three language files have the same keys — missing keys cause runtime fallback warnings\n- Do not create inline translation objects — always use the message files\n","lastUpdated":"2026-05-16T12:55:32+02:00"},{"slug":"react-three-fiber","category":"instructions","data":{"name":"React Three Fiber 3D","description":"Conventions for React Three Fiber (R3F) components including dynamic imports, SSR avoidance, camera patterns, and postprocessing in Next.js apps.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*{canvas,scene,viewer,3d,three,r3f}*.{ts,tsx}"],"tags":["react-three-fiber","threejs","3d","nextjs"],"featured":false},"content":"\n## Overview\n\nReact Three Fiber (R3F) renders Three.js scenes as React components. In Next.js, all 3D code must be client-only to avoid SSR hydration errors.\n\n## Critical: No SSR for 3D\n\nThree.js requires browser APIs (WebGL, canvas). Always use dynamic import with `ssr: false`:\n\n```tsx\n// In a Server Component or page\nimport dynamic from \"next/dynamic\";\n\nconst Scene3D = dynamic(() => import(\"./Scene3D\"), { ssr: false });\n\nexport default function Page() {\n return ;\n}\n```\n\nThe Scene3D component itself must have `\"use client\"` at the top.\n\n## Canvas Setup Pattern\n\n```tsx\n\"use client\";\n\nimport { Canvas } from \"@react-three/fiber\";\nimport { Environment, OrbitControls } from \"@react-three/drei\";\n\nexport default function Scene3D() {\n return (\n \n \n \n \n \n {/* Your 3D content */}\n \n );\n}\n```\n\n## GLB Model Loading\n\n```tsx\nimport { useGLTF } from \"@react-three/drei\";\n\nfunction MachineModel({ url }: { url: string }) {\n const { scene } = useGLTF(url);\n return ;\n}\n\n// Preload for instant display\nuseGLTF.preload(\"/models/machine.glb\");\n```\n\n## Module Visibility Toggle\n\nFor configurators where modules can be toggled on/off:\n\n```tsx\nimport { useEffect, useRef } from \"react\";\nimport { useGLTF } from \"@react-three/drei\";\nimport * as THREE from \"three\";\n\nfunction ConfigurableModel({ url, visibleModules }: { url: string; visibleModules: Set }) {\n const { scene } = useGLTF(url);\n \n useEffect(() => {\n scene.traverse((node: THREE.Object3D) => {\n if (node.name && visibleModules !== undefined) {\n node.visible = visibleModules.has(node.name);\n }\n });\n }, [scene, visibleModules]);\n \n return ;\n}\n```\n\n## Postprocessing\n\n```tsx\nimport { EffectComposer, N8AO, Bloom, ToneMapping } from \"@react-three/postprocessing\";\n\n\n \n \n \n\n```\n\n## Common Pitfalls\n\n- **Never** import Three.js at the top level of a Server Component — use dynamic imports\n- **Never** use `useEffect` for animations — use R3F's `useFrame` hook instead\n- Avoid creating new `THREE.Vector3()` or `THREE.Color()` inside render — allocate once and reuse\n- Use `` around heavy models for loading states\n- Set `reactStrictMode: false` in `next.config.ts` — R3F is not compatible with strict mode double-rendering\n- For WebGPU detection, check `navigator.gpu` before attempting WebGPU renderer\n","lastUpdated":"2026-05-16T12:55:32+02:00"},{"slug":"shadcn-ui-v4","category":"instructions","data":{"name":"shadcn/ui v4 (Base UI)","description":"Instructions for shadcn/ui v4 which uses Base UI primitives — use the render prop for composition, not Radix asChild.","author":"NeexoCore","source":"https://github.com/NeexoCore/awesome-neexo","applyTo":["**/*.{ts,tsx}","**/components/**"],"tags":["shadcn","ui","base-ui","react"],"featured":false},"content":"\n## Overview\n\nshadcn/ui v4 switched from Radix UI to Base UI (`@base-ui/react`) under the hood. The most important change is how composition works.\n\n## Critical: render Prop, Not asChild\n\n```tsx\n// ✅ Correct — shadcn/ui v4 (Base UI)\n\n\n// ❌ Wrong — this is Radix UI / shadcn v3 syntax\n\n```\n\nThis is the most common mistake when moving to shadcn/ui v4. `asChild` does not exist in Base UI components.\n\n## Component Installation\n\n```bash\nnpx shadcn@latest add button dialog select\n```\n\nComponents are installed to `components/ui/`. Do not barrel-export them — import directly:\n\n```tsx\nimport { Button } from \"@/components/ui/button\";\nimport { Dialog, DialogContent, DialogTrigger } from \"@/components/ui/dialog\";\n```\n\n## Styling Conventions\n\n- Use `cn()` from `@/lib/utils` for conditional classes:\n ```tsx\n import { cn } from \"@/lib/utils\";\n
\n ```\n- Use Tailwind utility classes — do not create custom CSS for component styling\n- Respect existing design tokens in `globals.css`\n- Generated `components/ui/` files are exempt from file-size limits\n\n## Patterns\n\n### Dialog with Form\n\n```tsx\n\n }>Open\n \n
\n {/* form fields */}\n
\n \n\n```\n\n### Select with Controlled Value\n\n```tsx\n\n```\n\n## Do Not\n\n- Use `asChild` — it does not exist in Base UI\n- Create new button styles — use `variant` prop on `