| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 2 | 0% |
| Commands | 0 | 0 | 1 | 0% |
| Section tags | 0 | 0 | 1 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 2 only in B- − Context Engineering Checklist
- + Worker Service
- + Worker Service Conventions
Commands
0 shared · 0 only in A · 1 only in B- + pnpm start:worker
Section tags
0 shared · 0 only in A · 1 only in B- + code-style
Line diff
novuhq/novu · .cursor/rules/context-engineering.mdc
@@ −1 @@
1---
2description: Context quality checklist for system prompts and agent instructions
3globs:
4 - "**/tools/**/*.ts"
5 - "**/prompts/**/*.ts"
6 - "**/*.prompt.ts"
7 - "AGENTS.md"
8 - ".cursor/rules/**"
9 - ".cursor/skills/**"
10 - ".agents/skills/**"
11alwaysApply: false
12---
13
14### Context Engineering Checklist
15
16When writing or reviewing agent instructions, tool descriptions, or prompts:
17
18- Is this explained elsewhere? → Consolidate to one location
19- Would a senior dev infer this? → Remove if obvious
20- Can this be an example instead? → One example beats three paragraphs of rules
21- Is this defensive repetition ("MUST", "NEVER", "CRITICAL")? → State once, remove emphasis
22- Does this duplicate a tool's own description? → Keep in tool description only
23- Are there prescriptive step lists? → Compress to a sentence
24- Is the altitude right? → Specific heuristics, not hardcoded logic or vague guidance
25- Is this stable across requests? → Move to cached/static portion
26
novuhq/novu · .cursor/rules/worker.mdc
@@ +1 @@
1---
2description: Rules for working in the Worker service (background job processing)
3globs: apps/worker/**/*
4alwaysApply: false
5---
6
7## Worker Service
8
9**Stack:** NestJS · Bull + Redis · ClickHouse (execution traces) · cron-parser
10
11**Run:** `pnpm start:worker` — only needed when testing notification triggering; skip for dashboard/API-only tasks.
12
13**Tests/lint:** see testing.mdc
14
15**Key directories:**
16```
17apps/worker/src/app/workflow/usecases/ # Workflow step execution usecases
18apps/worker/src/app/workflow/services/ # Queue consumers and job handlers
19```
20
21---
22
23### Worker Service Conventions
24
25**Use-case structure**
26- Each notification channel has a dedicated `send-message` use-case under `apps/worker/src/app/workflow/usecases/`.
27- Follow the CQRS pattern: `execute(command: CommandClass)` returning a typed result.
28- Keep channel-specific logic isolated — do not share send-message logic across channels.
29
30**Queue / Bull**
31- Job consumers are registered in NestJS modules using Bull's `@Process` decorator.
32- Retry logic and failure handling are configured at the queue level in `libs/application-generic` — do not duplicate this in worker use-cases.
33- Always handle job failures gracefully and log execution details via `CreateExecutionDetails`.
34
@@ −1 +1 @@
11 ---
2−description: Context quality checklist for system prompts and agent instructions
3−globs:
4− - "**/tools/**/*.ts"
5− - "**/prompts/**/*.ts"
6− - "**/*.prompt.ts"
7− - "AGENTS.md"
8− - ".cursor/rules/**"
9− - ".cursor/skills/**"
10− - ".agents/skills/**"
2+description: Rules for working in the Worker service (background job processing)
3+globs: apps/worker/**/*
114 alwaysApply: false
125 ---
136
14−### Context Engineering Checklist
7+## Worker Service
158
16−When writing or reviewing agent instructions, tool descriptions, or prompts:
9+**Stack:** NestJS · Bull + Redis · ClickHouse (execution traces) · cron-parser
1710
18−- Is this explained elsewhere? → Consolidate to one location
19−- Would a senior dev infer this? → Remove if obvious
20−- Can this be an example instead? → One example beats three paragraphs of rules
21−- Is this defensive repetition ("MUST", "NEVER", "CRITICAL")? → State once, remove emphasis
22−- Does this duplicate a tool's own description? → Keep in tool description only
23−- Are there prescriptive step lists? → Compress to a sentence
24−- Is the altitude right? → Specific heuristics, not hardcoded logic or vague guidance
25−- Is this stable across requests? → Move to cached/static portion
11+**Run:** `pnpm start:worker` — only needed when testing notification triggering; skip for dashboard/API-only tasks.
12+
13+**Tests/lint:** see testing.mdc
14+
15+**Key directories:**
16+```
17+apps/worker/src/app/workflow/usecases/ # Workflow step execution usecases
18+apps/worker/src/app/workflow/services/ # Queue consumers and job handlers
19+```
20+
21+---
22+
23+### Worker Service Conventions
24+
25+**Use-case structure**
26+- Each notification channel has a dedicated `send-message` use-case under `apps/worker/src/app/workflow/usecases/`.
27+- Follow the CQRS pattern: `execute(command: CommandClass)` returning a typed result.
28+- Keep channel-specific logic isolated — do not share send-message logic across channels.
29+
30+**Queue / Bull**
31+- Job consumers are registered in NestJS modules using Bull's `@Process` decorator.
32+- Retry logic and failure handling are configured at the queue level in `libs/application-generic` — do not duplicate this in worker use-cases.
33+- Always handle job failures gracefully and log execution details via `CreateExecutionDetails`.
2634
