| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 1 | 0% |
| Commands | 0 | 0 | 2 | 0% |
| Section tags | 0 | 0 | 3 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 1 only in B- − Context Engineering Checklist
- + Testing Conventions
Commands
0 shared · 0 only in A · 2 only in B- + npm run lint:openapi
- + pnpm start:worker
Section tags
0 shared · 0 only in A · 3 only in B- + test
- + code-style
- + testing-strategy
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/testing.mdc
@@ +1 @@
1---
2description: Rules for writing and running tests
3globs:
4 - "**/*.spec.ts"
5 - "**/*.test.ts"
6 - "**/e2e/**"
7alwaysApply: false
8---
9
10### Testing Conventions
11
12**General**
13- Match the test style and tooling already used in the same app (Mocha for API/worker, Playwright for dashboard).
14- Shared test utilities and setup helpers live in `libs/testing` — use them instead of rolling custom harnesses.
15- Never mock MongoDB models directly; use the test harness in `libs/testing` which manages real database state.
16
17**API (`apps/api`)**
18- Unit tests: `cd apps/api && pnpm test` (Mocha + ts-node, matches `src/**/*.spec.ts`)
19- Lint: `cd apps/api && pnpm check`
20- OpenAPI validation: `npm run lint:openapi` (requires API running)
21- E2E tests: see `.cursor/skills/run-api-e2e-tests/SKILL.md`
22- Bootstrap a NestJS testing module for integration-style unit tests rather than mocking the entire DI container.
23
24**Dashboard (`apps/dashboard`)**
25- E2E tests: `cd apps/dashboard && pnpm test:e2e` (Playwright — start dashboard first)
26- Lint: `cd apps/dashboard && pnpm check`
27- Tests live in `apps/dashboard/tests/` (or `e2e/`).
28
29**Worker (`apps/worker`)**
30- Unit tests: `cd apps/worker && pnpm test` (Mocha + ts-node, matches `src/**/**/*.spec.ts`)
31- Lint: `cd apps/worker && pnpm check`
32- The worker must be running (`pnpm start:worker`) when testing end-to-end notification flows.
33
@@ −1 +1 @@
11 ---
2−description: Context quality checklist for system prompts and agent instructions
2+description: Rules for writing and running tests
33 globs:
4− - "**/tools/**/*.ts"
5− - "**/prompts/**/*.ts"
6− - "**/*.prompt.ts"
7− - "AGENTS.md"
8− - ".cursor/rules/**"
9− - ".cursor/skills/**"
10− - ".agents/skills/**"
4+ - "**/*.spec.ts"
5+ - "**/*.test.ts"
6+ - "**/e2e/**"
117 alwaysApply: false
128 ---
139
14−### Context Engineering Checklist
10+### Testing Conventions
1511
16−When writing or reviewing agent instructions, tool descriptions, or prompts:
12+**General**
13+- Match the test style and tooling already used in the same app (Mocha for API/worker, Playwright for dashboard).
14+- Shared test utilities and setup helpers live in `libs/testing` — use them instead of rolling custom harnesses.
15+- Never mock MongoDB models directly; use the test harness in `libs/testing` which manages real database state.
1716
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
17+**API (`apps/api`)**
18+- Unit tests: `cd apps/api && pnpm test` (Mocha + ts-node, matches `src/**/*.spec.ts`)
19+- Lint: `cd apps/api && pnpm check`
20+- OpenAPI validation: `npm run lint:openapi` (requires API running)
21+- E2E tests: see `.cursor/skills/run-api-e2e-tests/SKILL.md`
22+- Bootstrap a NestJS testing module for integration-style unit tests rather than mocking the entire DI container.
23+
24+**Dashboard (`apps/dashboard`)**
25+- E2E tests: `cd apps/dashboard && pnpm test:e2e` (Playwright — start dashboard first)
26+- Lint: `cd apps/dashboard && pnpm check`
27+- Tests live in `apps/dashboard/tests/` (or `e2e/`).
28+
29+**Worker (`apps/worker`)**
30+- Unit tests: `cd apps/worker && pnpm test` (Mocha + ts-node, matches `src/**/**/*.spec.ts`)
31+- Lint: `cd apps/worker && pnpm check`
32+- The worker must be running (`pnpm start:worker`) when testing end-to-end notification flows.
2633
