@mallardbay/cursor-rules 1.0.25 → 1.0.27
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.
|
@@ -12,7 +12,7 @@ We aim for high-impact test coverage, focused on adding value and improving deve
|
|
|
12
12
|
|
|
13
13
|
We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully reduce risk or help developers move faster, it’s not worth writing. The goal is smart coverage, not maximum coverage—optimize for reliability, clarity, and development speed without overengineering.
|
|
14
14
|
|
|
15
|
-
Avoid e2e tests for UI. Favor unit tests.
|
|
15
|
+
**Frontend (React, React Native):** Avoid e2e tests for UI. Favor unit tests. **Backend (Node.js):** Prioritize e2e tests.
|
|
16
16
|
|
|
17
17
|
### Coverage Requirements
|
|
18
18
|
|
|
@@ -12,7 +12,7 @@ We aim for high-impact test coverage, focused on adding value and improving deve
|
|
|
12
12
|
|
|
13
13
|
We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully reduce risk or help developers move faster, it’s not worth writing. The goal is smart coverage, not maximum coverage—optimize for reliability, clarity, and development speed without overengineering.
|
|
14
14
|
|
|
15
|
-
Avoid e2e tests for UI. Favor unit tests.
|
|
15
|
+
**Frontend (React, React Native):** Avoid e2e tests for UI. Favor unit tests. **Backend (Node.js):** Prioritize e2e tests.
|
|
16
16
|
|
|
17
17
|
### Coverage Requirements
|
|
18
18
|
|
|
@@ -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
|