@clipboard-health/ai-rules 0.1.2 → 0.2.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +72 -7
- package/{AGENTS.md → backend/AGENTS.md} +28 -44
- package/{CLAUDE.md → backend/CLAUDE.md} +28 -41
- package/common/AGENTS.md +76 -0
- package/common/CLAUDE.md +75 -0
- package/frontend/AGENTS.md +4223 -0
- package/frontend/CLAUDE.md +4222 -0
- package/fullstack/AGENTS.md +4238 -0
- package/fullstack/CLAUDE.md +4237 -0
- package/package.json +20 -12
package/README.md
CHANGED
|
@@ -1,21 +1,86 @@
|
|
|
1
|
-
# @clipboard-health/ai-rules
|
|
1
|
+
# @clipboard-health/ai-rules
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Pre-built AI agent rules for consistent coding standards.
|
|
4
4
|
|
|
5
|
-
## Table of contents
|
|
5
|
+
## Table of contents
|
|
6
6
|
|
|
7
|
-
- [
|
|
8
|
-
- [
|
|
9
|
-
- [
|
|
7
|
+
- [@clipboard-health/ai-rules](#clipboard-healthai-rules)
|
|
8
|
+
- [Table of contents](#table-of-contents)
|
|
9
|
+
- [Install](#install)
|
|
10
|
+
- [Usage](#usage)
|
|
11
|
+
- [Quick Start](#quick-start)
|
|
12
|
+
- [Updating Rules](#updating-rules)
|
|
13
|
+
- [Local development commands](#local-development-commands)
|
|
10
14
|
|
|
11
15
|
## Install
|
|
12
16
|
|
|
13
17
|
```bash
|
|
14
|
-
npm install @clipboard-health/ai-rules
|
|
18
|
+
npm install --save-dev @clipboard-health/ai-rules
|
|
15
19
|
```
|
|
16
20
|
|
|
17
21
|
## Usage
|
|
18
22
|
|
|
23
|
+
### Quick Start
|
|
24
|
+
|
|
25
|
+
1. Choose the profile that matches your project type:
|
|
26
|
+
|
|
27
|
+
| Profile | Includes | Use For |
|
|
28
|
+
| ----------- | --------------------------- | -------------------------------------- |
|
|
29
|
+
| `common` | common | TypeScript libraries, generic projects |
|
|
30
|
+
| `frontend` | common + frontend | React apps, web apps |
|
|
31
|
+
| `backend` | common + backend | NestJS services, APIs |
|
|
32
|
+
| `fullstack` | common + frontend + backend | Monorepos, fullstack apps |
|
|
33
|
+
|
|
34
|
+
**Rule categories:**
|
|
35
|
+
- **common**: TypeScript, testing, code style, error handling, key conventions
|
|
36
|
+
- **frontend**: React patterns, hooks, performance, styling, data fetching, custom hooks
|
|
37
|
+
- **backend**: NestJS APIs, three-tier architecture, controllers, services
|
|
38
|
+
|
|
39
|
+
2. Add it to your `package.json`:
|
|
40
|
+
|
|
41
|
+
```json
|
|
42
|
+
{
|
|
43
|
+
"scripts": {
|
|
44
|
+
"sync-ai-rules": "cp -r ./node_modules/@clipboard-health/ai-rules/[CHOSEN_PROFILE_NAME]/. ./",
|
|
45
|
+
"postinstall": "npm run sync-ai-rules"
|
|
46
|
+
}
|
|
47
|
+
}
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
3. Run:
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
npm install # Runs postinstall automatically
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
4. Commit the generated files:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
git add AGENTS.md CLAUDE.md
|
|
60
|
+
git commit -m "feat: add AI coding rules"
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
5. That's it! Your AI assistants will automatically use these files.
|
|
64
|
+
|
|
65
|
+
### Updating Rules
|
|
66
|
+
|
|
67
|
+
When we release new rules or improvements:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
# Update the package
|
|
71
|
+
npm update @clipboard-health/ai-rules
|
|
72
|
+
|
|
73
|
+
# The postinstall script automatically copies the latest files
|
|
74
|
+
npm install
|
|
75
|
+
|
|
76
|
+
# Review the changes
|
|
77
|
+
git diff AGENTS.md CLAUDE.md
|
|
78
|
+
|
|
79
|
+
# Commit the updates
|
|
80
|
+
git add AGENTS.md CLAUDE.md
|
|
81
|
+
git commit -m "chore: update AI coding rules"
|
|
82
|
+
```
|
|
83
|
+
|
|
19
84
|
## Local development commands
|
|
20
85
|
|
|
21
86
|
See [`package.json`](./package.json) `scripts` for a list of commands.
|
|
@@ -1,8 +1,22 @@
|
|
|
1
|
-
|
|
2
|
-
alwaysApply: true
|
|
3
|
-
---
|
|
1
|
+
<!-- Generated by Ruler -->
|
|
4
2
|
|
|
5
|
-
|
|
3
|
+
|
|
4
|
+
<!-- Source: .ruler/backend/nestJsApis.md -->
|
|
5
|
+
|
|
6
|
+
# NestJS APIs
|
|
7
|
+
|
|
8
|
+
- Use a three-tier architecture:
|
|
9
|
+
- Controllers in the entrypoints tier translate from data transfer objects (DTOs) to domain objects (DOs) and call the logic tier.
|
|
10
|
+
- Logic tier services call other services in the logic tier and repos and gateways at the data tier. The logic tier operates only on DOs.
|
|
11
|
+
- Data tier repos translate from DOs to data access objects (DAOs), call the database using either Prisma for Postgres or Mongoose for MongoDB, and then translate from DAOs to DOs before returning to the logic tier.
|
|
12
|
+
- Use ts-rest to define contracts using Zod schemas, one contract per resource.
|
|
13
|
+
- A controller implements each ts-rest contract.
|
|
14
|
+
- Requests and responses follow the JSON:API specification, including pagination for listings.
|
|
15
|
+
- Use TypeDoc to document public functions, classes, methods, and complex code blocks.
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
<!-- Source: .ruler/common/codeStyleAndStructure.md -->
|
|
6
20
|
|
|
7
21
|
# Code style and structure
|
|
8
22
|
|
|
@@ -16,7 +30,9 @@ alwaysApply: true
|
|
|
16
30
|
- When declaring functions, use the `function` keyword, not `const`.
|
|
17
31
|
- Prefer data immutability.
|
|
18
32
|
|
|
19
|
-
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
<!-- Source: .ruler/common/errorHandlingAndValidation.md -->
|
|
20
36
|
|
|
21
37
|
# Error handling and validation
|
|
22
38
|
|
|
@@ -29,7 +45,9 @@ alwaysApply: true
|
|
|
29
45
|
- Implement proper error logging and user-friendly error messages.
|
|
30
46
|
- Favor `@clipboard-health/util-ts`'s `Either` type for expected errors instead of `try`/`catch`.
|
|
31
47
|
|
|
32
|
-
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
<!-- Source: .ruler/common/keyConventions.md -->
|
|
33
51
|
|
|
34
52
|
# Key conventions
|
|
35
53
|
|
|
@@ -38,32 +56,9 @@ alwaysApply: true
|
|
|
38
56
|
- You always write correct, up-to-date, bug-free, fully functional, working, secure, easy-to-read, and efficient code.
|
|
39
57
|
- If there might not be a correct answer or do not know the answer, say so instead of guessing.
|
|
40
58
|
|
|
41
|
-
<!-- Source: .ruler/nestJsApis.md -->
|
|
42
|
-
|
|
43
|
-
# NestJS APIs
|
|
44
|
-
|
|
45
|
-
- Use a three-tier architecture:
|
|
46
|
-
- Controllers in the entrypoints tier translate from data transfer objects (DTOs) to domain objects (DOs) and call the logic tier.
|
|
47
|
-
- Logic tier services call other services in the logic tier and repos and gateways at the data tier. The logic tier operates only on DOs.
|
|
48
|
-
- Data tier repos translate from DOs to data access objects (DAOs), call the database using either Prisma for Postgres or Mongoose for MongoDB, and then translate from DAOs to DOs before returning to the logic tier.
|
|
49
|
-
- Use ts-rest to define contracts using Zod schemas, one contract per resource.
|
|
50
|
-
- A controller implements each ts-rest contract.
|
|
51
|
-
- Requests and responses follow the JSON:API specification, including pagination for listings.
|
|
52
|
-
- Use TypeDoc to document public functions, classes, methods, and complex code blocks.
|
|
53
59
|
|
|
54
|
-
<!-- Source: .ruler/react.md -->
|
|
55
60
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
- Destructure props in function body rather than in function signature
|
|
59
|
-
- Prefer inline JSX rather than extracting variables and functions as variables outside of JSX
|
|
60
|
-
- Use useModalState for any showing/hiding functionality like dialogs
|
|
61
|
-
- Utilize custom hooks to encapsulate and reuse stateful logic
|
|
62
|
-
- When performing data-fetching in a custom hook, always use Zod to define any request and response schemas
|
|
63
|
-
- Use react-hook-form for all form UIs and use zod resolver for form schema validation
|
|
64
|
-
- Use date-fns for any Date based operations like formatting
|
|
65
|
-
|
|
66
|
-
<!-- Source: .ruler/testing.md -->
|
|
61
|
+
<!-- Source: .ruler/common/testing.md -->
|
|
67
62
|
|
|
68
63
|
# Testing
|
|
69
64
|
|
|
@@ -73,7 +68,9 @@ alwaysApply: true
|
|
|
73
68
|
- Prefer `it.each` for multiple test cases.
|
|
74
69
|
- Avoid conditional logic in tests.
|
|
75
70
|
|
|
76
|
-
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
<!-- Source: .ruler/common/typeScript.md -->
|
|
77
74
|
|
|
78
75
|
# TypeScript usage
|
|
79
76
|
|
|
@@ -92,16 +89,3 @@ alwaysApply: true
|
|
|
92
89
|
- Leverage `readonly` properties for function parameter immutability.
|
|
93
90
|
- Prefer narrow types whenever possible with `as const` assertions, `typeof`, `instanceof`, `satisfies`, and custom type guards.
|
|
94
91
|
- Implement exhaustiveness checking using `never`.
|
|
95
|
-
|
|
96
|
-
<!-- Source: .ruler/uiAndStyling.md -->
|
|
97
|
-
|
|
98
|
-
# UI and Styling
|
|
99
|
-
|
|
100
|
-
- Use Material UI for components and styling and a mobile-first approach.
|
|
101
|
-
- Favor TanStack Query over "useEffect".
|
|
102
|
-
|
|
103
|
-
<!-- Source: .ruler/zOverlay.md -->
|
|
104
|
-
|
|
105
|
-
# Overlay
|
|
106
|
-
|
|
107
|
-
- If an ./OVERLAY.md file exists, read it for additional rules.
|
|
@@ -1,4 +1,21 @@
|
|
|
1
|
-
|
|
1
|
+
|
|
2
|
+
|
|
3
|
+
<!-- Source: .ruler/backend/nestJsApis.md -->
|
|
4
|
+
|
|
5
|
+
# NestJS APIs
|
|
6
|
+
|
|
7
|
+
- Use a three-tier architecture:
|
|
8
|
+
- Controllers in the entrypoints tier translate from data transfer objects (DTOs) to domain objects (DOs) and call the logic tier.
|
|
9
|
+
- Logic tier services call other services in the logic tier and repos and gateways at the data tier. The logic tier operates only on DOs.
|
|
10
|
+
- Data tier repos translate from DOs to data access objects (DAOs), call the database using either Prisma for Postgres or Mongoose for MongoDB, and then translate from DAOs to DOs before returning to the logic tier.
|
|
11
|
+
- Use ts-rest to define contracts using Zod schemas, one contract per resource.
|
|
12
|
+
- A controller implements each ts-rest contract.
|
|
13
|
+
- Requests and responses follow the JSON:API specification, including pagination for listings.
|
|
14
|
+
- Use TypeDoc to document public functions, classes, methods, and complex code blocks.
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
<!-- Source: .ruler/common/codeStyleAndStructure.md -->
|
|
2
19
|
|
|
3
20
|
# Code style and structure
|
|
4
21
|
|
|
@@ -12,7 +29,9 @@
|
|
|
12
29
|
- When declaring functions, use the `function` keyword, not `const`.
|
|
13
30
|
- Prefer data immutability.
|
|
14
31
|
|
|
15
|
-
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
<!-- Source: .ruler/common/errorHandlingAndValidation.md -->
|
|
16
35
|
|
|
17
36
|
# Error handling and validation
|
|
18
37
|
|
|
@@ -25,7 +44,9 @@
|
|
|
25
44
|
- Implement proper error logging and user-friendly error messages.
|
|
26
45
|
- Favor `@clipboard-health/util-ts`'s `Either` type for expected errors instead of `try`/`catch`.
|
|
27
46
|
|
|
28
|
-
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
<!-- Source: .ruler/common/keyConventions.md -->
|
|
29
50
|
|
|
30
51
|
# Key conventions
|
|
31
52
|
|
|
@@ -34,32 +55,9 @@
|
|
|
34
55
|
- You always write correct, up-to-date, bug-free, fully functional, working, secure, easy-to-read, and efficient code.
|
|
35
56
|
- If there might not be a correct answer or do not know the answer, say so instead of guessing.
|
|
36
57
|
|
|
37
|
-
<!-- Source: .ruler/nestJsApis.md -->
|
|
38
58
|
|
|
39
|
-
# NestJS APIs
|
|
40
59
|
|
|
41
|
-
|
|
42
|
-
- Controllers in the entrypoints tier translate from data transfer objects (DTOs) to domain objects (DOs) and call the logic tier.
|
|
43
|
-
- Logic tier services call other services in the logic tier and repos and gateways at the data tier. The logic tier operates only on DOs.
|
|
44
|
-
- Data tier repos translate from DOs to data access objects (DAOs), call the database using either Prisma for Postgres or Mongoose for MongoDB, and then translate from DAOs to DOs before returning to the logic tier.
|
|
45
|
-
- Use ts-rest to define contracts using Zod schemas, one contract per resource.
|
|
46
|
-
- A controller implements each ts-rest contract.
|
|
47
|
-
- Requests and responses follow the JSON:API specification, including pagination for listings.
|
|
48
|
-
- Use TypeDoc to document public functions, classes, methods, and complex code blocks.
|
|
49
|
-
|
|
50
|
-
<!-- Source: .ruler/react.md -->
|
|
51
|
-
|
|
52
|
-
# React
|
|
53
|
-
|
|
54
|
-
- Destructure props in function body rather than in function signature
|
|
55
|
-
- Prefer inline JSX rather than extracting variables and functions as variables outside of JSX
|
|
56
|
-
- Use useModalState for any showing/hiding functionality like dialogs
|
|
57
|
-
- Utilize custom hooks to encapsulate and reuse stateful logic
|
|
58
|
-
- When performing data-fetching in a custom hook, always use Zod to define any request and response schemas
|
|
59
|
-
- Use react-hook-form for all form UIs and use zod resolver for form schema validation
|
|
60
|
-
- Use date-fns for any Date based operations like formatting
|
|
61
|
-
|
|
62
|
-
<!-- Source: .ruler/testing.md -->
|
|
60
|
+
<!-- Source: .ruler/common/testing.md -->
|
|
63
61
|
|
|
64
62
|
# Testing
|
|
65
63
|
|
|
@@ -69,7 +67,9 @@
|
|
|
69
67
|
- Prefer `it.each` for multiple test cases.
|
|
70
68
|
- Avoid conditional logic in tests.
|
|
71
69
|
|
|
72
|
-
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
<!-- Source: .ruler/common/typeScript.md -->
|
|
73
73
|
|
|
74
74
|
# TypeScript usage
|
|
75
75
|
|
|
@@ -88,16 +88,3 @@
|
|
|
88
88
|
- Leverage `readonly` properties for function parameter immutability.
|
|
89
89
|
- Prefer narrow types whenever possible with `as const` assertions, `typeof`, `instanceof`, `satisfies`, and custom type guards.
|
|
90
90
|
- Implement exhaustiveness checking using `never`.
|
|
91
|
-
|
|
92
|
-
<!-- Source: .ruler/uiAndStyling.md -->
|
|
93
|
-
|
|
94
|
-
# UI and Styling
|
|
95
|
-
|
|
96
|
-
- Use Material UI for components and styling and a mobile-first approach.
|
|
97
|
-
- Favor TanStack Query over "useEffect".
|
|
98
|
-
|
|
99
|
-
<!-- Source: .ruler/zOverlay.md -->
|
|
100
|
-
|
|
101
|
-
# Overlay
|
|
102
|
-
|
|
103
|
-
- If an ./OVERLAY.md file exists, read it for additional rules.
|
package/common/AGENTS.md
ADDED
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
<!-- Generated by Ruler -->
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
<!-- Source: .ruler/common/codeStyleAndStructure.md -->
|
|
5
|
+
|
|
6
|
+
# Code style and structure
|
|
7
|
+
|
|
8
|
+
- Write concise, technical TypeScript code with accurate examples.
|
|
9
|
+
- Use functional and declarative programming patterns.
|
|
10
|
+
- Prefer iteration and modularization over code duplication.
|
|
11
|
+
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
|
|
12
|
+
- Structure files: constants, types, exported functions, non-exported functions.
|
|
13
|
+
- Avoid magic strings and numbers; define constants.
|
|
14
|
+
- Use camelCase for files and directories (e.g., modules/shiftOffers.ts).
|
|
15
|
+
- When declaring functions, use the `function` keyword, not `const`.
|
|
16
|
+
- Prefer data immutability.
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
<!-- Source: .ruler/common/errorHandlingAndValidation.md -->
|
|
21
|
+
|
|
22
|
+
# Error handling and validation
|
|
23
|
+
|
|
24
|
+
- Sanitize user input.
|
|
25
|
+
- Handle errors and edge cases at the beginning of functions.
|
|
26
|
+
- Use early returns for error conditions to avoid deeply nested if statements.
|
|
27
|
+
- Place the happy path last in the function for improved readability.
|
|
28
|
+
- Avoid unnecessary else statements; use the if-return pattern instead.
|
|
29
|
+
- Use guard clauses to handle preconditions and invalid states early.
|
|
30
|
+
- Implement proper error logging and user-friendly error messages.
|
|
31
|
+
- Favor `@clipboard-health/util-ts`'s `Either` type for expected errors instead of `try`/`catch`.
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
<!-- Source: .ruler/common/keyConventions.md -->
|
|
36
|
+
|
|
37
|
+
# Key conventions
|
|
38
|
+
|
|
39
|
+
- You are familiar with the latest features and best practices.
|
|
40
|
+
- You carefully provide accurate, factual, thoughtful answers and are a genius at reasoning.
|
|
41
|
+
- You always write correct, up-to-date, bug-free, fully functional, working, secure, easy-to-read, and efficient code.
|
|
42
|
+
- If there might not be a correct answer or do not know the answer, say so instead of guessing.
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
<!-- Source: .ruler/common/testing.md -->
|
|
47
|
+
|
|
48
|
+
# Testing
|
|
49
|
+
|
|
50
|
+
- Follow the Arrange-Act-Assert convention for tests with newlines between each section.
|
|
51
|
+
- Name test variables using the `mockX`, `input`, `expected`, `actual` convention.
|
|
52
|
+
- Aim for high test coverage, writing both positive and negative test cases.
|
|
53
|
+
- Prefer `it.each` for multiple test cases.
|
|
54
|
+
- Avoid conditional logic in tests.
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
<!-- Source: .ruler/common/typeScript.md -->
|
|
59
|
+
|
|
60
|
+
# TypeScript usage
|
|
61
|
+
|
|
62
|
+
- Use strict-mode TypeScript for all code; prefer interfaces over types.
|
|
63
|
+
- Avoid enums; use const maps instead.
|
|
64
|
+
- Strive for precise types. Look for type definitions in the codebase and create your own if none exist.
|
|
65
|
+
- Avoid using type assertions like `as` or `!` unless absolutely necessary.
|
|
66
|
+
- Use the `unknown` type instead of `any` when the type is truly unknown.
|
|
67
|
+
- Use an object to pass multiple function params and to return results.
|
|
68
|
+
- Leverage union types, intersection types, and conditional types for complex type definitions.
|
|
69
|
+
- Use mapped types and utility types (e.g., `Partial<T>`, `Pick<T>`, `Omit<T>`) to transform existing types.
|
|
70
|
+
- Implement generic types to create reusable, flexible type definitions.
|
|
71
|
+
- Utilize the `keyof` operator and index access types for dynamic property access.
|
|
72
|
+
- Implement discriminated unions for type-safe handling of different object shapes where appropriate.
|
|
73
|
+
- Use the `infer` keyword in conditional types for type inference.
|
|
74
|
+
- Leverage `readonly` properties for function parameter immutability.
|
|
75
|
+
- Prefer narrow types whenever possible with `as const` assertions, `typeof`, `instanceof`, `satisfies`, and custom type guards.
|
|
76
|
+
- Implement exhaustiveness checking using `never`.
|
package/common/CLAUDE.md
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
|
|
2
|
+
|
|
3
|
+
<!-- Source: .ruler/common/codeStyleAndStructure.md -->
|
|
4
|
+
|
|
5
|
+
# Code style and structure
|
|
6
|
+
|
|
7
|
+
- Write concise, technical TypeScript code with accurate examples.
|
|
8
|
+
- Use functional and declarative programming patterns.
|
|
9
|
+
- Prefer iteration and modularization over code duplication.
|
|
10
|
+
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
|
|
11
|
+
- Structure files: constants, types, exported functions, non-exported functions.
|
|
12
|
+
- Avoid magic strings and numbers; define constants.
|
|
13
|
+
- Use camelCase for files and directories (e.g., modules/shiftOffers.ts).
|
|
14
|
+
- When declaring functions, use the `function` keyword, not `const`.
|
|
15
|
+
- Prefer data immutability.
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
<!-- Source: .ruler/common/errorHandlingAndValidation.md -->
|
|
20
|
+
|
|
21
|
+
# Error handling and validation
|
|
22
|
+
|
|
23
|
+
- Sanitize user input.
|
|
24
|
+
- Handle errors and edge cases at the beginning of functions.
|
|
25
|
+
- Use early returns for error conditions to avoid deeply nested if statements.
|
|
26
|
+
- Place the happy path last in the function for improved readability.
|
|
27
|
+
- Avoid unnecessary else statements; use the if-return pattern instead.
|
|
28
|
+
- Use guard clauses to handle preconditions and invalid states early.
|
|
29
|
+
- Implement proper error logging and user-friendly error messages.
|
|
30
|
+
- Favor `@clipboard-health/util-ts`'s `Either` type for expected errors instead of `try`/`catch`.
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
<!-- Source: .ruler/common/keyConventions.md -->
|
|
35
|
+
|
|
36
|
+
# Key conventions
|
|
37
|
+
|
|
38
|
+
- You are familiar with the latest features and best practices.
|
|
39
|
+
- You carefully provide accurate, factual, thoughtful answers and are a genius at reasoning.
|
|
40
|
+
- You always write correct, up-to-date, bug-free, fully functional, working, secure, easy-to-read, and efficient code.
|
|
41
|
+
- If there might not be a correct answer or do not know the answer, say so instead of guessing.
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
<!-- Source: .ruler/common/testing.md -->
|
|
46
|
+
|
|
47
|
+
# Testing
|
|
48
|
+
|
|
49
|
+
- Follow the Arrange-Act-Assert convention for tests with newlines between each section.
|
|
50
|
+
- Name test variables using the `mockX`, `input`, `expected`, `actual` convention.
|
|
51
|
+
- Aim for high test coverage, writing both positive and negative test cases.
|
|
52
|
+
- Prefer `it.each` for multiple test cases.
|
|
53
|
+
- Avoid conditional logic in tests.
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
<!-- Source: .ruler/common/typeScript.md -->
|
|
58
|
+
|
|
59
|
+
# TypeScript usage
|
|
60
|
+
|
|
61
|
+
- Use strict-mode TypeScript for all code; prefer interfaces over types.
|
|
62
|
+
- Avoid enums; use const maps instead.
|
|
63
|
+
- Strive for precise types. Look for type definitions in the codebase and create your own if none exist.
|
|
64
|
+
- Avoid using type assertions like `as` or `!` unless absolutely necessary.
|
|
65
|
+
- Use the `unknown` type instead of `any` when the type is truly unknown.
|
|
66
|
+
- Use an object to pass multiple function params and to return results.
|
|
67
|
+
- Leverage union types, intersection types, and conditional types for complex type definitions.
|
|
68
|
+
- Use mapped types and utility types (e.g., `Partial<T>`, `Pick<T>`, `Omit<T>`) to transform existing types.
|
|
69
|
+
- Implement generic types to create reusable, flexible type definitions.
|
|
70
|
+
- Utilize the `keyof` operator and index access types for dynamic property access.
|
|
71
|
+
- Implement discriminated unions for type-safe handling of different object shapes where appropriate.
|
|
72
|
+
- Use the `infer` keyword in conditional types for type inference.
|
|
73
|
+
- Leverage `readonly` properties for function parameter immutability.
|
|
74
|
+
- Prefer narrow types whenever possible with `as const` assertions, `typeof`, `instanceof`, `satisfies`, and custom type guards.
|
|
75
|
+
- Implement exhaustiveness checking using `never`.
|