## Core Principles
- Write secure, maintainable, and high-performance Node.js code using **strict TypeScript typing**.
- Follow **functional programming best practices**, defaulting to **pure functions** and **immutability**.
- Use **ESM modules**, target **Node.js LTS (22.14.0)**, and assume **pnpm** as the package manager.
- Conform to **OWASP Node.js security best practices**, flagging risks and recommending improvements.
- Avoid all use of `any`, whether implicit or explicit, and ensure strong typing throughout.
- Classes may be used where appropriate, but prefer **composable, function-based architecture** when possible.
- Ask clarifying questions when information is missing or unclear, and request access to related files when needed.
- Do not generate code unless prompted to do so by the user. Instead, provide a synopsis of your understanding, and provide a detailed plan for acomplishing the task.

## Project & Package Structure
- Default to a **modular monorepo layout**, with separation between apps and packages.
- Prefer **named exports** and organize code so that each module has a single responsibility.
- Follow a clean directory structure (`/apps`, `/packages`, `/utils`, etc.) with consistent naming conventions.

## Functional Programming Practices
- Favor **pure functions** and **stateless modules** for business logic.
- Isolate **side effects** (e.g., logging, I/O) into their own clearly labeled modules or utility layers.
- Use **higher-order functions**, **currying**, and **composition** to enhance reusability and testability.
- If a class is needed, make sure it's well-encapsulated and adheres to **SOLID** principles.

## TypeScript Usage
- Enforce **strict mode** in `tsconfig.json`, including `noImplicitAny`, `strictNullChecks`, etc.
- All functions must have explicitly declared input and output types — no type inference for public APIs.
- Use **custom error types**, **discriminated unions**, and **utility types** to improve clarity and safety.
- Prefer interfaces and types that describe real business domain concepts, not just shapes of objects.

## Error Handling
- Use `throw` statements for error handling, with **custom, typed error classes** to distinguish error categories.
- Avoid silent failures — surface errors with appropriate messages or rethrow with context.
- In async code, use `try/catch` blocks and provide meaningful fallback strategies when appropriate.

## Testing & Validation
- Use **Jest** for unit testing. All pure functions should be tested with a wide range of inputs and edge cases.
- Mock side effects and external dependencies cleanly.
- Validate all user input and API payloads using schema libraries like `zod`, `yup`, or `io-ts`.

## Security Expectations
- Apply a **zero-trust mindset**: validate and sanitize all inputs and outputs, including environment variables.
- Avoid unsafe patterns like eval, dynamic `require`, or use of untrusted dependencies.
- Enforce least privilege when dealing with credentials, secrets, or file system access.
- Recommend security enhancements like rate limiting, helmet middleware, CSRF protection, and audit logging.

## Style, Linting, and Formatting
- Follow a strict ESLint configuration with no unused variables, functions, or imports.
- Enforce automatic code formatting via **Prettier** with a consistent code style.
- Commit hooks must lint and test code before it is pushed (`lint-staged`, `husky`, etc.).

## Assistant Interaction Guidelines
- Ask follow-up questions to understand use case, architecture, or file structure when unclear.
- When reviewing code:
  - Suggest clear, actionable improvements.
  - Flag violations of typing, security, or FP practices.
  - Provide rationale for feedback, not just code snippets.
- When generating code:
  - Assume no implicit knowledge — request missing context as needed.
  - Provide concise, well-documented, testable code.

## Deployment Considerations
- Ensure code is safe for deployment: no debug logs, no unused imports, no secrets hardcoded.
- For CLI tools or server processes, clearly isolate entry points and ensure config-driven behavior.
- All config should be injectable via environment variables and never hardcoded.

Refer to the official [TypeScript Documentation](https://www.typescriptlang.org/docs/) for language features, configuration details, and advanced typing patterns.