@mallardbay/cursor-rules 1.0.24 → 1.0.26
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.
|
@@ -59,6 +59,7 @@ Avoid e2e tests for UI. Favor unit tests.
|
|
|
59
59
|
- Apollo mocks
|
|
60
60
|
- Provider mocks
|
|
61
61
|
- Keep mocks simple and maintainable
|
|
62
|
+
- **Do not use variable matchers for Apollo mocks**—match exact variables (e.g. avoid `expect.anything()` or `variables: {}`) so tests fail when the component passes incorrect variables to queries or mutations
|
|
62
63
|
|
|
63
64
|
### Test Utilities
|
|
64
65
|
|
|
@@ -62,6 +62,7 @@ Avoid e2e tests for UI. Favor unit tests.
|
|
|
62
62
|
- Apollo mocks
|
|
63
63
|
- Provider mocks
|
|
64
64
|
- Keep mocks simple and maintainable
|
|
65
|
+
- **Do not use variable matchers for Apollo mocks**—match exact variables (e.g. avoid `expect.anything()` or `variables: {}`) so tests fail when the component passes incorrect variables to queries or mutations
|
|
65
66
|
|
|
66
67
|
### Test Utilities
|
|
67
68
|
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: should-we-merge
|
|
3
|
+
description: Performs a thorough PR review and produces a prioritized merge recommendation with issues ranked by severity. Use when deciding whether to merge a PR, gate merge decisions, or need a clear yes/no answer with prioritized findings from best practices and hygiene checks.
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
tags:
|
|
6
|
+
- pr
|
|
7
|
+
- merge
|
|
8
|
+
- review
|
|
9
|
+
- merge-gate
|
|
10
|
+
- prioritization
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Should We Merge?
|
|
14
|
+
|
|
15
|
+
Performs a thorough review of a pull request and produces a **prioritized merge recommendation**. Outputs a clear yes/no answer with issues ranked by severity, grounded in project best practices and general hygiene.
|
|
16
|
+
|
|
17
|
+
## When to Use
|
|
18
|
+
|
|
19
|
+
- User asks "should we merge?", "merge gate", "ready to merge?"
|
|
20
|
+
- Deciding whether a PR is safe to merge
|
|
21
|
+
- Need a prioritized list of issues before merge
|
|
22
|
+
- Pre-merge checklist or gate review
|
|
23
|
+
|
|
24
|
+
## Instructions
|
|
25
|
+
|
|
26
|
+
### Step 1: Get PR Context
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
# By PR number or URL
|
|
30
|
+
gh pr view <pr-number> --json number,title,body,author,headRefName,baseRefName,files,additions,deletions,commits
|
|
31
|
+
|
|
32
|
+
# By branch name
|
|
33
|
+
gh pr list --head <branch-name> --json number,title,url
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Fetch diff and changed files:
|
|
37
|
+
```bash
|
|
38
|
+
gh pr diff <pr-number>
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Step 2: Run Prioritized Review
|
|
42
|
+
|
|
43
|
+
Review the PR against project standards. **Assign every finding to exactly one severity level.**
|
|
44
|
+
|
|
45
|
+
**Reference rules:**
|
|
46
|
+
- [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - DRY, patterns, semantic clarity, cognitive complexity
|
|
47
|
+
- [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) - Structure, naming, reuse
|
|
48
|
+
- [testing.mdc](mdc:.cursor/rules/testing.mdc) - Test coverage and quality
|
|
49
|
+
- [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - PR size, review expectations
|
|
50
|
+
|
|
51
|
+
### Severity Levels
|
|
52
|
+
|
|
53
|
+
| Level | Label | Meaning | Merge? |
|
|
54
|
+
|-------|-------|---------|--------|
|
|
55
|
+
| **P0** | Blocking | Must fix before merge | No |
|
|
56
|
+
| **P1** | Important | Should fix; merge at reviewer discretion | Conditional |
|
|
57
|
+
| **P2** | Suggestion | Nice to have; non-blocking | Yes |
|
|
58
|
+
| **P3** | Hygiene | Minor polish; defer is acceptable | Yes |
|
|
59
|
+
|
|
60
|
+
### P0 (Blocking) — Do Not Merge
|
|
61
|
+
|
|
62
|
+
- Bugs or incorrect logic
|
|
63
|
+
- Security vulnerabilities
|
|
64
|
+
- Breaking changes without versioning/deprecation
|
|
65
|
+
- Missing tests for critical paths
|
|
66
|
+
- PR exceeds 400 lines (per [code-review.mdc](mdc:.cursor/rules/code-review.mdc))
|
|
67
|
+
- eslint-disable without documented justification
|
|
68
|
+
- Sensitive data exposed
|
|
69
|
+
- Tests failing or not run
|
|
70
|
+
|
|
71
|
+
### P1 (Important) — Should Fix
|
|
72
|
+
|
|
73
|
+
- Missing tests for new code
|
|
74
|
+
- Violates DRY or existing patterns
|
|
75
|
+
- Poor error handling or edge cases
|
|
76
|
+
- High cognitive complexity (>3 nesting levels)
|
|
77
|
+
- Unclear naming or semantics
|
|
78
|
+
- Code duplication that should be extracted
|
|
79
|
+
- Commented-out code or debug statements
|
|
80
|
+
- Inconsistent with codebase style
|
|
81
|
+
|
|
82
|
+
### P2 (Suggestion) — Nice to Have
|
|
83
|
+
|
|
84
|
+
- Minor style improvements
|
|
85
|
+
- Documentation gaps
|
|
86
|
+
- Optional refactors
|
|
87
|
+
- Performance improvements that aren't critical
|
|
88
|
+
|
|
89
|
+
### P3 (Hygiene) — Low Priority
|
|
90
|
+
|
|
91
|
+
- Typos, formatting
|
|
92
|
+
- Minor naming tweaks
|
|
93
|
+
- Small test improvements
|
|
94
|
+
- Non-critical lint suggestions
|
|
95
|
+
|
|
96
|
+
### Step 3: Hygiene Checks
|
|
97
|
+
|
|
98
|
+
**General hygiene (reference [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc)):**
|
|
99
|
+
- [ ] No commented-out code or debug statements
|
|
100
|
+
- [ ] No unused imports or variables
|
|
101
|
+
- [ ] No experimental or failed-attempt code left behind
|
|
102
|
+
- [ ] Functions have clear, semantic names
|
|
103
|
+
- [ ] No magic numbers or strings (use constants)
|
|
104
|
+
|
|
105
|
+
**PR hygiene:**
|
|
106
|
+
- [ ] PR description explains purpose
|
|
107
|
+
- [ ] Related issues/tickets referenced
|
|
108
|
+
- [ ] No unrelated changes
|
|
109
|
+
- [ ] Commit messages are descriptive
|
|
110
|
+
|
|
111
|
+
### Step 4: Output Merge Recommendation
|
|
112
|
+
|
|
113
|
+
Use this output format:
|
|
114
|
+
|
|
115
|
+
```markdown
|
|
116
|
+
## Should We Merge? [YES / NO / CONDITIONAL]
|
|
117
|
+
|
|
118
|
+
**Summary:** [1–2 sentence verdict]
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
### P0 — Blocking (must fix)
|
|
123
|
+
- [ ] [Issue]: [file:line] — [Brief description]
|
|
124
|
+
|
|
125
|
+
### P1 — Important (should fix)
|
|
126
|
+
- [ ] [Issue]: [file:line] — [Brief description]
|
|
127
|
+
|
|
128
|
+
### P2 — Suggestion (nice to have)
|
|
129
|
+
- [ ] [Issue]: [file:line] — [Brief description]
|
|
130
|
+
|
|
131
|
+
### P3 — Hygiene (low priority)
|
|
132
|
+
- [ ] [Issue]: [file:line] — [Brief description]
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
### Positive Notes
|
|
137
|
+
- [What was done well]
|
|
138
|
+
|
|
139
|
+
### References
|
|
140
|
+
- [Rules/standards cited]
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
**Merge decision logic:**
|
|
144
|
+
- **YES** — No P0 issues; P1 issues are minimal or acceptable to merge with follow-up
|
|
145
|
+
- **NO** — Any P0 issues
|
|
146
|
+
- **CONDITIONAL** — No P0, but significant P1 issues; merge at reviewer discretion
|
|
147
|
+
|
|
148
|
+
## Notes
|
|
149
|
+
|
|
150
|
+
- **Read every changed line** before rendering verdict
|
|
151
|
+
- **Be specific** — include file paths and line numbers for each issue
|
|
152
|
+
- **Cite standards** — reference rule files when applicable
|
|
153
|
+
- **Prioritize ruthlessly** — avoid inflating P0; reserve for true blockers
|
|
154
|
+
- **Balance thoroughness with pragmatism** — focus on what matters for merge safety
|