@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 CHANGED
@@ -1,21 +1,86 @@
1
- # @clipboard-health/ai-rules <!-- omit from toc -->
1
+ # @clipboard-health/ai-rules
2
2
 
3
- Rules for AI agents.
3
+ Pre-built AI agent rules for consistent coding standards.
4
4
 
5
- ## Table of contents <!-- omit from toc -->
5
+ ## Table of contents
6
6
 
7
- - [Install](#install)
8
- - [Usage](#usage)
9
- - [Local development commands](#local-development-commands)
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
- <!-- Source: .ruler/codeStyleAndStructure.md -->
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
- <!-- Source: .ruler/errorHandlingAndValidation.md -->
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
- <!-- Source: .ruler/keyConventions.md -->
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
- # React
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
- <!-- Source: .ruler/typeScript.md -->
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
- <!-- Source: .ruler/codeStyleAndStructure.md -->
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
- <!-- Source: .ruler/errorHandlingAndValidation.md -->
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
- <!-- Source: .ruler/keyConventions.md -->
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
- - Use a three-tier architecture:
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
- <!-- Source: .ruler/typeScript.md -->
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.
@@ -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`.
@@ -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`.