Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/PaulJPhilp/EffectPatternsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/pauljphilp/effectpatterns/decouple-fibers-with-queues-and-pubsub)<a href="https://agentmods.dev/rules/pauljphilp/effectpatterns/decouple-fibers-with-queues-and-pubsub"><img src="https://agentmods.dev/badge/rules/pauljphilp/effectpatterns/decouple-fibers-with-queues-and-pubsub/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/pauljphilp/effectpatterns/decouple-fibers-with-queues-and-pubsub"><img src="https://agentmods.dev/badge/rules/pauljphilp/effectpatterns/decouple-fibers-with-queues-and-pubsub.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.01301 | $0.01301 |
| Opus 5 | $0.00651 | $0.00651 |
| Sonnet 5 | $0.00260 | $0.00260 |
| Haiku 4.5 | $0.00130 | $0.00130 |
Grade A, and why
decouple-fibers-with-queues-and-pubsub scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 148 lines — stays where its author put it; the contents beside it link to each section on GitHub.
description: Use Queue for point-to-point work distribution and PubSub for broadcast messaging between fibers. globs: "**/*.ts" alwaysApply: true
Decouple Fibers with Queues and PubSub
Rule: Use Queue for point-to-point work distribution and PubSub for broadcast messaging between fibers.
Example
A producer fiber adds jobs to a Queue, and a worker fiber takes jobs off the queue to process them.
import { Effect, Queue, Fiber } from "effect";
const program = Effect.gen(function* () {
yield* Effect.logInfo("Starting queue demo...");
// Create a bounded queue that can hold a maximum of 10 items.
// This prevents memory issues by applying backpressure when the queue is full.
// If a producer tries to add to a full queue, it will suspend until space is available.
const queue = yield* Queue.bounded<string>(10);
yield* Effect.logInfo("Created bounded queue");
// Producer Fiber: Add a job to the queue every second.
// This fiber runs independently and continuously produces work items.
// The producer-consumer pattern decouples work generation from work processing.
const producer = yield* Effect.gen(function* () {
let i = 0;
while (true) {
const job = `job-${i++}`;
yield* Effect.logInfo(`Producing ${job}...`);
// Queue.offer adds an item to the queue. If the queue is full,
// this operation will suspend the fiber until space becomes available.
// This provides natural backpressure control.
yield* Queue.offer(queue, job);
// Sleep for 500ms between job creation. This controls the production rate.
// Producer is faster than consumer (500ms vs 1000ms) to demonstrate queue buffering.
yield* Effect.sleep("500 millis");
}
}).pipe(Effect.fork); // Fork creates a new fiber that runs concurrently
yield* Effect.logInfo("Started producer fiber");
// Worker Fiber: Take a job from the queue and process it.
// This fiber runs independently and processes work items as they become available.
// Multiple workers could be created to scale processing capacity.
const worker = yield* Effect.gen(function* () {
while (true) {
// Queue.take removes and returns an item from the queue.
// If the queue is empty, this operation will suspend the fiber
// until an item becomes available. This prevents busy-waiting.
const job = yield* Queue.take(queue);
yield* Effect.logInfo(`Processing ${job}...`);
// Simulate work by sleeping for 1 second.
// This makes the worker slower than the producer, causing queue buildup.
yield* Effect.sleep("1 second");
yield* Effect.logInfo(`Completed ${job}`);
}
}).pipe(Effect.fork); // Fork creates another independent fiber
yield* Effect.logInfo("Started worker fiber");
// Let them run for a while...
// The main fiber sleeps while the producer and worker fibers run concurrently.
// During this time, you'll see the queue acting as a buffer between
// the fast producer and slow worker.
yield* Effect.logInfo("Running for 10 seconds...");
yield* Effect.sleep("10 seconds");
yield* Effect.logInfo("Done!");
// Interrupt both fibers to clean up resources.
// Fiber.interrupt sends an interruption signal to the fiber,
// allowing it to perform cleanup operations before terminating.
// This is safer than forcefully killing fibers.
yield* Fiber.interrupt(producer);
yield* Fiber.interrupt(worker);
// Note: In a real application, you might want to:
// 1. Drain the queue before interrupting workers
// 2. Use Fiber.join to wait for graceful shutdown
// 3. Handle interruption signals in the fiber loops
});
// Run the program
// This demonstrates the producer-consumer pattern with Effect fibers:
// - Fibers are lightweight threads that can be created in large numbers
// - Queues provide safe communication between fibers
// - Backpressure prevents resource exhaustion
// - Interruption allows for graceful shutdown
Effect.runPromise(program);
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 148 lines · 1,301 tokens per session scan A fb5fc798b35c
decouple-fibers-with-queues-and-pubsub is a cursor rule published in the GitHub repository PaulJPhilp/EffectPatterns (798 stars, last pushed 2mo ago), licensed MIT. It adds 1,301 tokens to every session, about $0.0065 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other cursor rules, from other repositories
python--typescript-guide-cursorrules-prompt-file
Cursor rules for Python development with TypeScript guide integration.
django-python
Rules for writing Python services at PostHog (Python servers powered by the Django framework).
standard-nestjs-module-hierarchy
Establish a consistent NestJS module structure in the API application where each resource is encapsulated in its own module with proper hierarchical organization to enhance maintainability, scalabilit... .
nestjs
This guide provides opinionated, actionable best practices for building robust, scalable, and maintainable NestJS applications using TypeScript, emphasizing modern patterns and common pitfalls.
nestjs-best-practices
../../.claude/rules/nestjs-best-practices.md.
api-design-typescript
API Design for TypeScript — Express, NestJS, Fastify patterns, middleware, validation, and error handling. Extends core/rules/api-design.mdc with TypeScript-specific guidance.