feat: add scripts to generate rules by skill level, use case, and compact format

Author: PaulJPhilp

content/accumulate-multiple-errors-with-either.mdx

@@ -40,7 +40,7 @@ However, for tasks like validating a user's input, this is poor user experience.
 
 Using `Schema.decode` with the `allErrors: true` option demonstrates this pattern perfectly. The underlying mechanism uses `Either` to collect all parsing errors into an array instead of stopping at the first one.
 
-```typescript
+````typescript
 import { Effect, Schema } from "effect";
 
 const UserSchema = Schema.Struct({
@@ -72,15 +72,15 @@ Validation failed with multiple errors:
 1. name must be a string at least 3 character(s) long
 2. email must be a string matching the pattern /@/
 */
-```
+````
 
 ---
 
 ## Anti-Pattern
 
 Using `Effect`'s error channel for validation that requires multiple error messages. The code below will only ever report the first error it finds, because `Effect.fail` short-circuits the entire `Effect.gen` block.
 
-```typescript
+````typescript
 import { Effect } from "effect";
 
 const validateWithEffect = (input: { name: string; email: string }) =>
@@ -94,4 +94,4 @@ const validateWithEffect = (input: { name: string; email: string }) =>
     }
     return yield* Effect.succeed(input);
   });
-```
+````

content/distinguish-not-found-from-errors.mdx

@@ -43,7 +43,7 @@ By using `Option` inside the success channel of an `Effect`, you keep the error
 
 This function to find a user can fail if the database is down, or it can succeed but find no user. The return type ``Effect.Effect<Option.Option<User>, DatabaseError>`` makes this contract perfectly clear.
 
-```typescript
+````typescript
 import { Effect, Option, Data } from "effect";
 
 interface User {
@@ -79,12 +79,13 @@ const program = (id: number) =>
         }),
     }),
   );
+````
 
 ## Anti-Pattern
 
 A common alternative is to create a specific NotFoundError and put it in the error channel alongside other errors.
 
-```typescript
+````typescript
 class NotFoundError extends Data.TaggedError("NotFoundError") {}
 
 	// ❌ This signature conflates two different kinds of failure.
@@ -94,8 +95,8 @@ class NotFoundError extends Data.TaggedError("NotFoundError") {}
 	  // ...
 	  return Effect.fail(new NotFoundError());
 	};
-```
+````
 
 While this works, it can be less expressive. It treats a "not found" result—which might be a normal part of your application's flow—the same as a catastrophic DatabaseError. 
 
-Using ```Effect<Option<A>>``` often leads to clearer and more precise business logic.
+Using ````Effect<Option<A>>```` often leads to clearer and more precise business logic.

content/provide-config-layer.mdx

@@ -23,7 +23,7 @@ Integrating configuration as a `Layer` plugs it directly into Effect's dependenc
 
 ## Good Example
 
-```typescript
+````typescript
 import { Config, Effect, Layer } from "effect";
 
 const ServerConfig = Config.all({ port: Config.number("PORT") });
@@ -33,7 +33,7 @@ const program = Effect.log("Application starting...");
 const configLayer = Config.layer(ServerConfig);
 
 const runnable = Effect.provide(program, configLayer);
-```
+````
 
 **Explanation:**  
 This approach makes configuration available contextually, supporting better testing and modularity.

content/stream-retry-on-failure.mdx

@@ -42,7 +42,7 @@ The `retry` operator, combined with the `Schedule` module, provides a powerful a
 
 This example simulates an API that fails the first two times it's called. The stream processes a list of IDs, and the `retry` operator ensures that the failing operation for `id: 2` is automatically retried until it succeeds.
 
-```typescript
+````typescript
 import { Effect, Stream, Schedule } from 'effect';
 
 let attempts = 0;
@@ -82,13 +82,13 @@ Output:
 ... level=INFO msg="Attempting to process item 2..."
 ... level=INFO msg="Attempting to process item 3..."
 */
-```
+````
 
 ## Anti-Pattern
 
 The anti-pattern is to either have no retry logic at all, or to write manual, imperative retry loops inside your processing function.
 
-```typescript
+````typescript
 import { Effect, Stream } from 'effect';
 // ... same mock processItem function ...
 
@@ -110,6 +110,6 @@ Output:
 ... level=INFO msg="Item 2 failed, attempt 1."
 Pipeline failed: Error: API is temporarily down
 */
-```
+````
 
 This "fail-fast" approach is brittle. A single, temporary network blip would cause the entire pipeline to terminate, even if subsequent items could have been processed successfully. While manual retry logic inside `processItem` is possible, it pollutes the core logic with concerns about timing and attempt counting, and is far less composable and reusable than a `Schedule`.

package.json

@@ -11,7 +11,8 @@
 		"rules": "bun scripts/generate_rules.ts"
 	},
 	"dependencies": {
-		"effect": "^3.16.8"
+		"effect": "^3.16.8",
+		"process": "^0.11.10"
 	},
 	"devDependencies": {
 		"@types/node": "^24.0.3",