@mallardbay/cursor-rules 1.0.11 → 1.0.12
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.
- package/.cursor/shared/rules/general-best-practices.mdc +163 -0
- package/.cursor/shared/skills/address-pr-feedback/SKILL.md +156 -0
- package/.cursor/shared/skills/prep-for-pr/SKILL.md +160 -0
- package/.cursor/shared/skills/review-pr/SKILL.md +267 -0
- package/README.md +56 -9
- package/bin/setup-cursor.sh +33 -1
- package/package.json +1 -1
|
@@ -0,0 +1,163 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Core development principles and best practices that always apply—optimized for AI agents to produce clean, maintainable, reviewable code with low cognitive complexity, clear semantics, and incremental changes.
|
|
3
|
+
alwaysApply: true
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# General Best Practices
|
|
7
|
+
|
|
8
|
+
These principles apply to all code changes and should guide every implementation decision.
|
|
9
|
+
|
|
10
|
+
## Core Principles
|
|
11
|
+
|
|
12
|
+
### DRY (Don't Repeat Yourself)
|
|
13
|
+
- Extract common logic into reusable functions, utilities, or shared modules
|
|
14
|
+
- Leverage existing patterns and utilities before creating new ones
|
|
15
|
+
- When duplicating code, ask: "Can this be abstracted?"
|
|
16
|
+
- Prefer composition and shared utilities over copy-paste solutions
|
|
17
|
+
|
|
18
|
+
### Leverage Existing Patterns
|
|
19
|
+
- **Always** search the codebase for similar implementations before creating new code
|
|
20
|
+
- Follow established patterns, conventions, and architectural decisions
|
|
21
|
+
- Use existing utilities, helpers, and shared libraries
|
|
22
|
+
- Match the style and structure of related files
|
|
23
|
+
- When patterns exist, use them consistently—don't invent new approaches without justification
|
|
24
|
+
|
|
25
|
+
### Incremental Changes
|
|
26
|
+
- **Minimize large changes in a single PR or commit**
|
|
27
|
+
- Break large features into smaller, testable increments
|
|
28
|
+
- Make changes that are easy to review and understand
|
|
29
|
+
- Prefer multiple small PRs over one massive change
|
|
30
|
+
- Each change should be independently testable and reviewable
|
|
31
|
+
- If a change touches many files, consider splitting it into logical phases
|
|
32
|
+
|
|
33
|
+
### Semantic Clarity
|
|
34
|
+
- Use **semantic, self-documenting names** for functions, variables, and types
|
|
35
|
+
- Function names should clearly describe what they do (e.g., `calculateTotalPrice` not `calc`)
|
|
36
|
+
- Variable names should express intent (e.g., `userAccountBalance` not `bal`)
|
|
37
|
+
- Terminology should be consistent across the codebase
|
|
38
|
+
- Avoid abbreviations unless they're widely understood in the domain
|
|
39
|
+
- Names should make code readable without comments
|
|
40
|
+
|
|
41
|
+
### Cognitive Complexity
|
|
42
|
+
- **Keep cognitive complexity low**—code should be easy to understand at a glance
|
|
43
|
+
- Prefer early returns and guard clauses over deep nesting
|
|
44
|
+
- Break complex logic into smaller, well-named functions
|
|
45
|
+
- Maximum nesting depth: 3 levels
|
|
46
|
+
- Use intermediate variables to clarify intent
|
|
47
|
+
- Extract complex conditionals into named boolean functions
|
|
48
|
+
- Avoid deeply nested ternaries—use if/else or extract to function
|
|
49
|
+
|
|
50
|
+
### Separation of Concerns
|
|
51
|
+
- **Files**: Each file should have a single, clear responsibility
|
|
52
|
+
- **Functions**: Each function should do one thing well
|
|
53
|
+
- Separate business logic from presentation, data access, and side effects
|
|
54
|
+
- Keep UI components focused on rendering and user interaction
|
|
55
|
+
- Extract business logic into pure functions or services
|
|
56
|
+
- Avoid god objects or functions that do too much
|
|
57
|
+
|
|
58
|
+
## Code Quality Standards
|
|
59
|
+
|
|
60
|
+
### Avoid "AI Slop"
|
|
61
|
+
- **Write code that's easy for humans to review**
|
|
62
|
+
- Avoid generating large amounts of code without understanding context
|
|
63
|
+
- Don't create unnecessary abstractions or over-engineered solutions
|
|
64
|
+
- Remove unused code, imports, and dead branches
|
|
65
|
+
- Clean up commented-out code and debugging statements
|
|
66
|
+
- If an approach doesn't work, **clean up failed attempts** before trying another
|
|
67
|
+
- Keep only relevant, working code—remove experimental code that didn't pan out
|
|
68
|
+
|
|
69
|
+
### Testing and Linting
|
|
70
|
+
- **Lint and test files related to your changes** before completing work
|
|
71
|
+
- Run linters on modified files and fix issues
|
|
72
|
+
- Run tests for affected modules, not the entire test suite unnecessarily
|
|
73
|
+
- For large changes: **use test sharding**—split tests across multiple runs
|
|
74
|
+
- **Do not run all tests in parallel** when dealing with many changes
|
|
75
|
+
- Tests should be **clear, fast, and minimize setup duplication**
|
|
76
|
+
- Use shared test utilities and fixtures to reduce boilerplate
|
|
77
|
+
- Each test should be independent and runnable in isolation
|
|
78
|
+
|
|
79
|
+
### Code Organization
|
|
80
|
+
- Group related functionality together
|
|
81
|
+
- Keep related code close (cohesion)
|
|
82
|
+
- Minimize dependencies between modules (loose coupling)
|
|
83
|
+
- Use appropriate data structures for the problem
|
|
84
|
+
- Prefer composition over inheritance
|
|
85
|
+
- Make functions pure when possible (no side effects)
|
|
86
|
+
- Handle edge cases explicitly—don't rely on implicit behavior
|
|
87
|
+
|
|
88
|
+
### Type Safety and Clarity
|
|
89
|
+
- Use TypeScript types effectively—avoid `any` unless necessary
|
|
90
|
+
- Make types explicit and meaningful
|
|
91
|
+
- Use const assertions and readonly where appropriate
|
|
92
|
+
- Prefer `const` over `let`, avoid `var`
|
|
93
|
+
- Use type guards and discriminated unions for type narrowing
|
|
94
|
+
|
|
95
|
+
### Performance Considerations
|
|
96
|
+
- Consider performance implications, but **avoid premature optimization**
|
|
97
|
+
- Profile before optimizing—optimize bottlenecks, not everything
|
|
98
|
+
- Use appropriate algorithms and data structures
|
|
99
|
+
- Avoid unnecessary re-renders, re-computations, or API calls
|
|
100
|
+
- Cache expensive computations when appropriate
|
|
101
|
+
|
|
102
|
+
## AI Agent Workflow
|
|
103
|
+
|
|
104
|
+
### Before Making Changes
|
|
105
|
+
1. **Create a plan** before making changes directly—outline the approach, identify affected files, and break down the work into steps
|
|
106
|
+
2. **Read existing code** to understand patterns and context
|
|
107
|
+
3. **Search the codebase** for similar implementations
|
|
108
|
+
4. **Check git history** to understand why code exists as it does
|
|
109
|
+
5. **Identify related files** that might be affected
|
|
110
|
+
6. **Ask clarifying questions** if requirements are unclear
|
|
111
|
+
|
|
112
|
+
### During Implementation
|
|
113
|
+
1. Make **small, incremental changes**
|
|
114
|
+
2. **Test as you go**—verify each change works before moving on
|
|
115
|
+
3. **Lint frequently**—don't accumulate lint errors
|
|
116
|
+
4. **Follow existing patterns**—don't reinvent the wheel
|
|
117
|
+
5. **Use semantic names**—code should be self-documenting
|
|
118
|
+
6. **Keep functions focused**—one responsibility per function
|
|
119
|
+
7. **Extract common logic**—don't duplicate code
|
|
120
|
+
|
|
121
|
+
### After Making Changes
|
|
122
|
+
1. **Clean up failed attempts**—remove experimental code
|
|
123
|
+
2. **Remove unused code**—imports, variables, functions
|
|
124
|
+
3. **Run linters** on modified files
|
|
125
|
+
4. **Run relevant tests**—not the entire suite unless necessary
|
|
126
|
+
5. **Verify the change works** end-to-end
|
|
127
|
+
6. **Check for side effects**—ensure changes don't break unrelated code
|
|
128
|
+
|
|
129
|
+
### When Changes Are Large
|
|
130
|
+
1. **Consider splitting** into multiple smaller PRs
|
|
131
|
+
2. **Use test sharding**—run tests in batches, not all at once
|
|
132
|
+
3. **Review incrementally**—make sure each part works before moving on
|
|
133
|
+
4. **Document the approach**—explain why changes are structured this way
|
|
134
|
+
5. **Check impact** on related systems and files
|
|
135
|
+
|
|
136
|
+
## Anti-Patterns to Avoid
|
|
137
|
+
|
|
138
|
+
- ❌ Copy-pasting code instead of extracting to a function
|
|
139
|
+
- ❌ Creating new patterns when existing ones work
|
|
140
|
+
- ❌ Making massive changes in one go
|
|
141
|
+
- ❌ Using vague names like `data`, `temp`, `value`, `thing`
|
|
142
|
+
- ❌ Deeply nested conditionals and loops
|
|
143
|
+
- ❌ Functions that do multiple unrelated things
|
|
144
|
+
- ❌ Leaving commented-out code or debugging statements
|
|
145
|
+
- ❌ Skipping tests or linting "to save time"
|
|
146
|
+
- ❌ Running entire test suite for small changes
|
|
147
|
+
- ❌ Leaving experimental code after failed attempts
|
|
148
|
+
- ❌ Premature optimization without profiling
|
|
149
|
+
- ❌ Using `any` types to avoid type errors
|
|
150
|
+
- ❌ Magic numbers or strings without constants
|
|
151
|
+
|
|
152
|
+
## Remember
|
|
153
|
+
|
|
154
|
+
**Code is read far more often than it's written.** Write code that:
|
|
155
|
+
- Is easy to understand
|
|
156
|
+
- Is easy to review
|
|
157
|
+
- Is easy to test
|
|
158
|
+
- Is easy to modify
|
|
159
|
+
- Follows established patterns
|
|
160
|
+
- Has clear semantics
|
|
161
|
+
- Minimizes cognitive load
|
|
162
|
+
|
|
163
|
+
When in doubt, prefer clarity and simplicity over cleverness.
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: address-pr-feedback
|
|
3
|
+
description: Address pull request feedback by finding the PR, reviewing comments, creating an implementation plan, and resolving GitHub conversations after fixes are applied. Use when responding to PR reviews, addressing feedback, or resolving review comments.
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
tags:
|
|
6
|
+
- pr
|
|
7
|
+
- review
|
|
8
|
+
- github
|
|
9
|
+
- workflow
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Address PR Feedback
|
|
13
|
+
|
|
14
|
+
Find a pull request by branch name, review all feedback, create a plan to address it, assess validity and priority, implement fixes, and resolve GitHub conversations.
|
|
15
|
+
|
|
16
|
+
## When to Use
|
|
17
|
+
|
|
18
|
+
- User wants to address PR feedback or review comments
|
|
19
|
+
- User mentions responding to PR reviews
|
|
20
|
+
- User wants to resolve GitHub conversations
|
|
21
|
+
- After receiving feedback on a pull request
|
|
22
|
+
- When preparing to address reviewer comments
|
|
23
|
+
|
|
24
|
+
## Instructions
|
|
25
|
+
|
|
26
|
+
### Step 1: Find the Pull Request
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
# Get branch name
|
|
30
|
+
BRANCH=$(git branch --show-current)
|
|
31
|
+
|
|
32
|
+
# Find PR (prefer GitHub CLI)
|
|
33
|
+
gh pr list --head $BRANCH --json number,title,url
|
|
34
|
+
|
|
35
|
+
# Or use API: GET /repos/{owner}/{repo}/pulls?head={owner}:{branch-name}&state=open
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
### Step 2: Check Merge Conflicts & CI Status
|
|
39
|
+
|
|
40
|
+
**Check conflicts:**
|
|
41
|
+
```bash
|
|
42
|
+
gh pr view <pr-number> --json mergeable,mergeableState
|
|
43
|
+
# mergeable_state: clean = no conflicts, dirty = conflicts exist, behind = needs update
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
**If conflicts exist:** Resolve before addressing feedback
|
|
47
|
+
```bash
|
|
48
|
+
git fetch origin <base-branch>
|
|
49
|
+
git rebase origin/<base-branch> # or merge
|
|
50
|
+
# Resolve conflicts, test, then push
|
|
51
|
+
git push origin <branch-name> # or --force-with-lease if rebased
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
**Check CI/CD status:**
|
|
55
|
+
```bash
|
|
56
|
+
gh pr checks <pr-number>
|
|
57
|
+
# Or: gh pr view <pr-number> --json statusCheckRollup
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
**API endpoints:**
|
|
61
|
+
- Conflicts: `GET /repos/{owner}/{repo}/pulls/{pull_number}` → check `mergeable_state`
|
|
62
|
+
- Checks: `GET /repos/{owner}/{repo}/commits/{sha}/check-runs` or `/status`
|
|
63
|
+
|
|
64
|
+
**If checks failing:** Fix issues, push, wait for re-run. Only resolve conversations when checks pass.
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
# Get all review comments (includes threads)
|
|
68
|
+
gh pr view <pr-number> --json comments,reviews
|
|
69
|
+
|
|
70
|
+
# API endpoints:
|
|
71
|
+
# GET /repos/{owner}/{repo}/pulls/{pull_number}/comments - Review comments
|
|
72
|
+
# GET /repos/{owner}/{repo}/issues/{pr_number}/comments - General PR comments
|
|
73
|
+
# GET /repos/{owner}/{repo}/pulls/{pull_number}/reviews - Review summaries (APPROVED, CHANGES_REQUESTED, etc.)
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
### Step 4: Analyze Feedback
|
|
77
|
+
|
|
78
|
+
Categorize by:
|
|
79
|
+
- **Type**: Blocking (must fix), Suggestions, Questions, Praise (no action)
|
|
80
|
+
- **Priority**: High (bugs/security), Medium (quality), Low (style)
|
|
81
|
+
- **Category**: Bugs, Code Quality, Tests, Documentation, Performance, Style
|
|
82
|
+
|
|
83
|
+
Assess validity against [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc). Group related feedback and identify contradictions.
|
|
84
|
+
|
|
85
|
+
### Step 5: Create Implementation Plan
|
|
86
|
+
|
|
87
|
+
List all feedback with: comment ID, thread ID, file:line, reviewer, priority, and proposed solution. Organize by file, order by priority, note dependencies.
|
|
88
|
+
|
|
89
|
+
**Format:**
|
|
90
|
+
```markdown
|
|
91
|
+
### High Priority
|
|
92
|
+
- [ ] Comment #123 (thread:456) - `src/utils.ts:45` - @reviewer
|
|
93
|
+
Issue: Missing null check → Solution: Add guard clause
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### Step 6: Implement Fixes
|
|
97
|
+
|
|
98
|
+
Work through plan systematically. Reference feedback in commits:
|
|
99
|
+
```bash
|
|
100
|
+
git commit -m "fix: add null check
|
|
101
|
+
|
|
102
|
+
Addresses review comment #123"
|
|
103
|
+
git push origin <branch-name>
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
### Step 7: Resolve GitHub Conversations
|
|
107
|
+
|
|
108
|
+
Reply to comments acknowledging fixes:
|
|
109
|
+
```bash
|
|
110
|
+
gh pr comment <pr-number> --body "Fixed in commit abc123. Thanks!"
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**API endpoints:**
|
|
114
|
+
- Reply: `POST /repos/{owner}/{repo}/pulls/{pull_number}/comments` with `{"body":"...", "in_reply_to": <comment_id>}`
|
|
115
|
+
- Resolve thread: `PUT /repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/resolved`
|
|
116
|
+
|
|
117
|
+
Reference commit hash and thank reviewers.
|
|
118
|
+
|
|
119
|
+
### Authentication
|
|
120
|
+
|
|
121
|
+
**Preferred: GitHub CLI**
|
|
122
|
+
```bash
|
|
123
|
+
gh auth login # Handles auth automatically
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
**Alternative: Personal Access Token**
|
|
127
|
+
- Create PAT with scopes: `repo`, `pull_requests:write`, `issues:write`
|
|
128
|
+
- Set: `export GITHUB_TOKEN=your_token_here`
|
|
129
|
+
- Never commit tokens. Use GitHub Secrets in CI/CD.
|
|
130
|
+
|
|
131
|
+
### Step 8: Verify and Follow Up
|
|
132
|
+
|
|
133
|
+
Re-check conflicts and CI status. Verify conversations resolved. Request re-review if needed:
|
|
134
|
+
```bash
|
|
135
|
+
gh pr comment <number> --body "@reviewer Ready for another look! ✅"
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
**Final checklist:** No conflicts ✅ | Checks passing ✅ | Feedback addressed ✅ | Conversations resolved ✅
|
|
139
|
+
|
|
140
|
+
## Output Format
|
|
141
|
+
|
|
142
|
+
Provide: PR status (conflicts & checks), summary of feedback addressed, changes made, conversations resolved, remaining items, next steps.
|
|
143
|
+
|
|
144
|
+
## Notes
|
|
145
|
+
|
|
146
|
+
- Be respectful in responses. Reference commits. Explain if not implementing a suggestion.
|
|
147
|
+
- Group related fixes. Test before resolving conversations. Ask questions if feedback is unclear.
|
|
148
|
+
|
|
149
|
+
## References
|
|
150
|
+
|
|
151
|
+
- [GitHub REST API - Pull Requests](https://docs.github.com/en/rest/pulls)
|
|
152
|
+
- [GitHub REST API - Pull Request Comments](https://docs.github.com/en/rest/pulls/comments)
|
|
153
|
+
- [GitHub REST API - Checks](https://docs.github.com/en/rest/checks)
|
|
154
|
+
- [GitHub REST API - Statuses](https://docs.github.com/en/rest/commits/statuses)
|
|
155
|
+
- [GitHub CLI Documentation](https://cli.github.com/manual/)
|
|
156
|
+
- [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - PR review standards
|
|
@@ -0,0 +1,160 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: prep-for-pr
|
|
3
|
+
description: Prepare the current branch for a pull request by checking code quality, completeness, and adherence to best practices. Use when preparing to create a PR, tidying up a branch, or ensuring code is ready for review.
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
tags:
|
|
6
|
+
- pr
|
|
7
|
+
- preparation
|
|
8
|
+
- code-quality
|
|
9
|
+
- workflow
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Prep for PR
|
|
13
|
+
|
|
14
|
+
Prepare the current branch for a pull request by systematically checking code quality, completeness, and adherence to best practices. This skill helps ensure your branch is ready before creating a PR.
|
|
15
|
+
|
|
16
|
+
## When to Use
|
|
17
|
+
|
|
18
|
+
- Preparing to create a pull request
|
|
19
|
+
- Tidying up a branch before submitting
|
|
20
|
+
- User mentions preparing for PR, getting ready for review, or checking branch quality
|
|
21
|
+
- Before pushing changes for review
|
|
22
|
+
- When you want to ensure code meets quality standards
|
|
23
|
+
|
|
24
|
+
## Instructions
|
|
25
|
+
|
|
26
|
+
Systematically check the new work on this branch and fix issues as you find them. Work through the following checklist:
|
|
27
|
+
|
|
28
|
+
**Important:** This skill references project rules for detailed guidance. Review the relevant rules files for complete standards:
|
|
29
|
+
- [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - Core principles, DRY, patterns, semantic clarity, cognitive complexity, anti-patterns
|
|
30
|
+
- [testing.mdc](mdc:.cursor/rules/testing.mdc) - Test coverage, organization, and quality standards
|
|
31
|
+
- [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) - Code structure, naming conventions, reuse guidelines
|
|
32
|
+
- [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - PR size and review requirements
|
|
33
|
+
|
|
34
|
+
### Code Quality Checks
|
|
35
|
+
|
|
36
|
+
**Feature Gaps**
|
|
37
|
+
- [ ] Are all requirements from the ticket/issue addressed?
|
|
38
|
+
- [ ] Are edge cases handled appropriately?
|
|
39
|
+
- [ ] Is error handling comprehensive?
|
|
40
|
+
- [ ] Are user-facing features complete (no TODOs or placeholders)?
|
|
41
|
+
|
|
42
|
+
**Potential New Bugs**
|
|
43
|
+
- [ ] Review logic for potential race conditions
|
|
44
|
+
- [ ] Check for null/undefined handling
|
|
45
|
+
- [ ] Verify error paths are tested
|
|
46
|
+
- [ ] Look for off-by-one errors or boundary issues
|
|
47
|
+
- [ ] Check for memory leaks or resource cleanup issues
|
|
48
|
+
- [ ] Verify async/await patterns are correct
|
|
49
|
+
- [ ] Check for potential infinite loops or performance issues
|
|
50
|
+
|
|
51
|
+
**Missing Tests**
|
|
52
|
+
- [ ] Are all new functions/components tested? (See [testing.mdc](mdc:.cursor/rules/testing.mdc))
|
|
53
|
+
- [ ] Are edge cases covered in tests?
|
|
54
|
+
- [ ] Are error cases tested?
|
|
55
|
+
- [ ] Is integration testing appropriate and present?
|
|
56
|
+
- [ ] Do tests follow existing test patterns?
|
|
57
|
+
|
|
58
|
+
**Duplicated Tests**
|
|
59
|
+
- [ ] Are there redundant test cases?
|
|
60
|
+
- [ ] Can tests be consolidated without losing coverage?
|
|
61
|
+
- [ ] Are test utilities being reused appropriately?
|
|
62
|
+
|
|
63
|
+
**Anti-Patterns**
|
|
64
|
+
- [ ] Check against project anti-patterns in [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc)
|
|
65
|
+
- [ ] Verify no copy-paste code that should be extracted (DRY principle)
|
|
66
|
+
- [ ] Ensure no commented-out code or debugging statements
|
|
67
|
+
- [ ] Check for code smells (god objects, deep nesting, magic numbers)
|
|
68
|
+
|
|
69
|
+
**Files Only Imported by Tests**
|
|
70
|
+
- [ ] Identify any files/functions only used in test files
|
|
71
|
+
- [ ] Determine if these should be removed or if they're intentionally test-only utilities
|
|
72
|
+
- [ ] Flag dead code that can be safely removed
|
|
73
|
+
|
|
74
|
+
**AI Slop That Needs to Be Flagged**
|
|
75
|
+
- [ ] Check against "Avoid AI Slop" section in [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc)
|
|
76
|
+
- [ ] Look for code that doesn't follow project patterns
|
|
77
|
+
- [ ] Identify code that seems generated without understanding context
|
|
78
|
+
- [ ] Check for unused imports or variables
|
|
79
|
+
|
|
80
|
+
### Best Practices Verification
|
|
81
|
+
|
|
82
|
+
**All New Code Uses Pre-Existing Patterns**
|
|
83
|
+
- [ ] Code follows established architectural patterns (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "Leverage Existing Patterns")
|
|
84
|
+
- [ ] File structure matches existing conventions (see [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc))
|
|
85
|
+
- [ ] Naming conventions are consistent (see [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) and [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "Semantic Clarity")
|
|
86
|
+
- [ ] Code organization follows project standards
|
|
87
|
+
|
|
88
|
+
**Whenever Possible We Reused Existing Logic**
|
|
89
|
+
- [ ] No duplicate code that could use shared utilities (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "DRY Principle")
|
|
90
|
+
- [ ] Existing functions/components are leveraged
|
|
91
|
+
- [ ] Shared libraries are used appropriately (see [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) - "Code Reuse")
|
|
92
|
+
|
|
93
|
+
**New Code is Setup in Way We Can Share/Reuse Later**
|
|
94
|
+
- [ ] Functions are properly abstracted
|
|
95
|
+
- [ ] Code is modular and composable (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "Separation of Concerns")
|
|
96
|
+
- [ ] Utilities are placed in appropriate shared locations
|
|
97
|
+
- [ ] Components are reusable, not overly specific
|
|
98
|
+
|
|
99
|
+
**Make Sure Function Names Make Sense Based on Context**
|
|
100
|
+
- [ ] Function names clearly describe what they do (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "Semantic Clarity")
|
|
101
|
+
- [ ] Names are semantic and self-documenting
|
|
102
|
+
- [ ] Terminology is consistent with codebase
|
|
103
|
+
- [ ] Names match their actual behavior
|
|
104
|
+
|
|
105
|
+
**New Code is Simple to Understand for Humans**
|
|
106
|
+
- [ ] Code is readable without excessive comments
|
|
107
|
+
- [ ] Complex logic is broken down into smaller functions (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - "Cognitive Complexity")
|
|
108
|
+
- [ ] Cognitive complexity is low (maximum nesting depth: 3 levels)
|
|
109
|
+
- [ ] Code flow is easy to follow
|
|
110
|
+
- [ ] Proper description/documentation where needed
|
|
111
|
+
|
|
112
|
+
### Preparation Process
|
|
113
|
+
|
|
114
|
+
1. **Analyze the current branch**
|
|
115
|
+
- Read through all changed files
|
|
116
|
+
- Understand the overall change and scope
|
|
117
|
+
- Identify what was added, modified, or removed
|
|
118
|
+
|
|
119
|
+
2. **Work through the checklist systematically**
|
|
120
|
+
- Check each category thoroughly
|
|
121
|
+
- Fix issues as you find them
|
|
122
|
+
- Don't just flag—actually improve the code
|
|
123
|
+
|
|
124
|
+
3. **Make improvements**
|
|
125
|
+
- Refactor code that doesn't follow patterns
|
|
126
|
+
- Add missing tests
|
|
127
|
+
- Remove duplicated code
|
|
128
|
+
- Fix bugs and edge cases
|
|
129
|
+
- Clean up AI-generated code that doesn't fit
|
|
130
|
+
- Improve naming and structure
|
|
131
|
+
|
|
132
|
+
4. **Verify completeness**
|
|
133
|
+
- Ensure all requirements are met
|
|
134
|
+
- Confirm tests are comprehensive
|
|
135
|
+
- Verify code follows project standards
|
|
136
|
+
- Check that everything is ready for review
|
|
137
|
+
|
|
138
|
+
5. **Use the ask questions tool** if you need clarification on:
|
|
139
|
+
- Requirements or acceptance criteria
|
|
140
|
+
- Project-specific patterns or conventions
|
|
141
|
+
- Expected behavior or edge cases
|
|
142
|
+
- Where to place new code or utilities
|
|
143
|
+
|
|
144
|
+
## Output Format
|
|
145
|
+
|
|
146
|
+
After preparing the branch, provide:
|
|
147
|
+
|
|
148
|
+
1. **Summary**: Overview of what was checked and improved
|
|
149
|
+
2. **Issues Fixed**: List of specific issues that were addressed
|
|
150
|
+
3. **Remaining Items**: Any items that need attention but couldn't be fixed automatically
|
|
151
|
+
4. **Readiness Status**: Whether the branch is ready for PR creation
|
|
152
|
+
|
|
153
|
+
## Notes
|
|
154
|
+
|
|
155
|
+
- Actively fix issues, don't just identify them
|
|
156
|
+
- Focus on important issues first (bugs, missing tests, anti-patterns)
|
|
157
|
+
- Reference existing code patterns when making changes
|
|
158
|
+
- Make code improvements that will make the PR easier to review
|
|
159
|
+
- Ensure the branch is in a good state before creating the PR
|
|
160
|
+
- Balance thoroughness with pragmatism—fix what matters most
|
|
@@ -0,0 +1,267 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-pr
|
|
3
|
+
description: Review a pull request systematically, checking code quality, functionality, security, and adherence to project standards. Use when reviewing PRs, providing code review feedback, or checking someone else's changes.
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
tags:
|
|
6
|
+
- pr
|
|
7
|
+
- review
|
|
8
|
+
- code-quality
|
|
9
|
+
- workflow
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Review PR
|
|
13
|
+
|
|
14
|
+
Systematically review a pull request, checking code quality, functionality, security, tests, and adherence to project standards. Provide constructive feedback and approve or request changes.
|
|
15
|
+
|
|
16
|
+
## When to Use
|
|
17
|
+
|
|
18
|
+
- User wants to review a pull request
|
|
19
|
+
- User mentions code review, PR review, or checking someone else's changes
|
|
20
|
+
- User provides a PR URL, number, or branch name
|
|
21
|
+
- When asked to review code before merge
|
|
22
|
+
|
|
23
|
+
## Instructions
|
|
24
|
+
|
|
25
|
+
### Step 1: Get PR Information
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
# If PR number provided
|
|
29
|
+
gh pr view <pr-number> --json number,title,body,author,headRefName,baseRefName,files,commits
|
|
30
|
+
|
|
31
|
+
# If PR URL provided, extract number from URL
|
|
32
|
+
# Format: github.com/{owner}/{repo}/pull/{number}
|
|
33
|
+
|
|
34
|
+
# If branch name provided
|
|
35
|
+
gh pr list --head <branch-name> --json number,title,url
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
**Key information to extract:**
|
|
39
|
+
- PR number, title, description
|
|
40
|
+
- Author and branch names
|
|
41
|
+
- Changed files and commit history
|
|
42
|
+
- Current review status
|
|
43
|
+
|
|
44
|
+
### Step 2: Review PR Scope
|
|
45
|
+
|
|
46
|
+
- [ ] PR size is reasonable (see [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - max 400 lines)
|
|
47
|
+
- [ ] PR description is clear and explains purpose
|
|
48
|
+
- [ ] Related issues/tickets are referenced
|
|
49
|
+
- [ ] Changes align with PR description
|
|
50
|
+
- [ ] No unrelated changes included
|
|
51
|
+
|
|
52
|
+
### Step 3: Code Quality Review
|
|
53
|
+
|
|
54
|
+
Reference project standards:
|
|
55
|
+
- [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - DRY, patterns, semantic clarity, cognitive complexity
|
|
56
|
+
- [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) - Structure, naming, reuse
|
|
57
|
+
- [testing.mdc](mdc:.cursor/rules/testing.mdc) - Test requirements
|
|
58
|
+
|
|
59
|
+
**Check for:**
|
|
60
|
+
|
|
61
|
+
**Functionality & Logic**
|
|
62
|
+
- [ ] Code does what it's supposed to do
|
|
63
|
+
- [ ] Edge cases are handled
|
|
64
|
+
- [ ] Error handling is comprehensive
|
|
65
|
+
- [ ] Integration with existing code is smooth
|
|
66
|
+
- [ ] No obvious bugs or logic errors
|
|
67
|
+
|
|
68
|
+
**Code Quality**
|
|
69
|
+
- [ ] Follows existing patterns (see [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc))
|
|
70
|
+
- [ ] Reuses existing logic where possible
|
|
71
|
+
- [ ] Function names are semantic and clear
|
|
72
|
+
- [ ] Cognitive complexity is low
|
|
73
|
+
- [ ] Separation of concerns is maintained
|
|
74
|
+
- [ ] No code duplication (DRY principle)
|
|
75
|
+
|
|
76
|
+
**Security**
|
|
77
|
+
- [ ] No obvious security vulnerabilities
|
|
78
|
+
- [ ] Input validation and sanitization
|
|
79
|
+
- [ ] Authentication/authorization checks
|
|
80
|
+
- [ ] No sensitive data exposed
|
|
81
|
+
- [ ] Dependencies are up-to-date and secure
|
|
82
|
+
|
|
83
|
+
**Performance**
|
|
84
|
+
- [ ] No obvious performance bottlenecks
|
|
85
|
+
- [ ] Efficient algorithms and data structures
|
|
86
|
+
- [ ] No unnecessary re-renders/re-computations
|
|
87
|
+
- [ ] Resource cleanup (memory, connections)
|
|
88
|
+
|
|
89
|
+
**Style & Consistency**
|
|
90
|
+
- [ ] Follows project naming conventions
|
|
91
|
+
- [ ] Consistent with codebase style
|
|
92
|
+
- [ ] No commented-out code or debug statements
|
|
93
|
+
- [ ] Proper formatting
|
|
94
|
+
|
|
95
|
+
### Step 4: Test Coverage Review
|
|
96
|
+
|
|
97
|
+
- [ ] New code has tests (see [testing.mdc](mdc:.cursor/rules/testing.mdc))
|
|
98
|
+
- [ ] Tests cover happy path, error cases, edge cases
|
|
99
|
+
- [ ] Test quality is good (clear, focused, maintainable)
|
|
100
|
+
- [ ] No duplicate or redundant tests
|
|
101
|
+
- [ ] Tests follow project patterns
|
|
102
|
+
|
|
103
|
+
### Step 5: Breaking Changes Analysis
|
|
104
|
+
|
|
105
|
+
Check for breaking changes that could affect clients:
|
|
106
|
+
|
|
107
|
+
- [ ] API endpoints, request/response formats, or signatures changed?
|
|
108
|
+
- [ ] Public functions/interfaces modified or removed?
|
|
109
|
+
- [ ] Database schema changes that aren't backward compatible?
|
|
110
|
+
- [ ] Behavioral changes that alter existing functionality?
|
|
111
|
+
- [ ] Configuration options changed or removed?
|
|
112
|
+
|
|
113
|
+
**If breaking changes found:** Flag as **Blocking** unless properly handled with version bump, deprecation notices, migration guides, and CHANGELOG entries.
|
|
114
|
+
|
|
115
|
+
### Step 6: Documentation Review
|
|
116
|
+
|
|
117
|
+
- [ ] Complex logic is documented
|
|
118
|
+
- [ ] Function/class documentation where needed
|
|
119
|
+
- [ ] README updated if needed
|
|
120
|
+
- [ ] Code comments explain "why" not "what"
|
|
121
|
+
|
|
122
|
+
### Step 7: Architecture & Design
|
|
123
|
+
|
|
124
|
+
- [ ] Aligns with system architecture
|
|
125
|
+
- [ ] Follows established design patterns
|
|
126
|
+
- [ ] No unnecessary abstractions
|
|
127
|
+
- [ ] Proper separation of concerns
|
|
128
|
+
- [ ] Changes are maintainable
|
|
129
|
+
|
|
130
|
+
### Step 8: Provide Feedback
|
|
131
|
+
|
|
132
|
+
**For each issue found:**
|
|
133
|
+
|
|
134
|
+
1. **Categorize feedback:**
|
|
135
|
+
- **Blocking** - Must fix before merge (bugs, security, breaking changes)
|
|
136
|
+
- **Important** - Should fix (code quality, maintainability)
|
|
137
|
+
- **Suggestion** - Nice to have (style, minor improvements)
|
|
138
|
+
- **Question** - Need clarification
|
|
139
|
+
|
|
140
|
+
2. **Write constructive comments:**
|
|
141
|
+
- Be specific about the issue
|
|
142
|
+
- Explain why it matters
|
|
143
|
+
- Suggest solutions when possible
|
|
144
|
+
- Reference project standards
|
|
145
|
+
- Use positive, respectful language
|
|
146
|
+
|
|
147
|
+
3. **Post comments on GitHub:**
|
|
148
|
+
|
|
149
|
+
```bash
|
|
150
|
+
# Post review comment on specific line
|
|
151
|
+
gh pr comment <pr-number> --body "Comment text" --file <file-path> --line <line-number>
|
|
152
|
+
|
|
153
|
+
# Or use API: POST /repos/{owner}/{repo}/pulls/{pull_number}/comments
|
|
154
|
+
# Body: {"body": "...", "path": "file.ts", "line": 42}
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
**Comment format:**
|
|
158
|
+
```markdown
|
|
159
|
+
**Issue:** [Brief description]
|
|
160
|
+
|
|
161
|
+
**Why:** [Why this matters - reference to standards if applicable]
|
|
162
|
+
|
|
163
|
+
**Suggestion:** [How to fix or improve]
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
### Step 9: Submit Review
|
|
167
|
+
|
|
168
|
+
**After reviewing:**
|
|
169
|
+
|
|
170
|
+
1. **Summarize findings:**
|
|
171
|
+
- List blocking issues
|
|
172
|
+
- List important issues
|
|
173
|
+
- Note positive aspects
|
|
174
|
+
|
|
175
|
+
2. **Submit review:**
|
|
176
|
+
|
|
177
|
+
```bash
|
|
178
|
+
# Request changes (blocking issues)
|
|
179
|
+
gh pr review <pr-number> --request-changes --body "Review summary"
|
|
180
|
+
|
|
181
|
+
# Approve (no blocking issues)
|
|
182
|
+
gh pr review <pr-number> --approve --body "LGTM! Minor suggestions in comments."
|
|
183
|
+
|
|
184
|
+
# Comment only (suggestions but not blocking)
|
|
185
|
+
gh pr review <pr-number> --comment --body "Review summary"
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
**API endpoint:** `POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews`
|
|
189
|
+
```json
|
|
190
|
+
{
|
|
191
|
+
"body": "Review summary",
|
|
192
|
+
"event": "APPROVE" | "REQUEST_CHANGES" | "COMMENT",
|
|
193
|
+
"comments": [
|
|
194
|
+
{
|
|
195
|
+
"path": "file.ts",
|
|
196
|
+
"line": 42,
|
|
197
|
+
"body": "Comment text"
|
|
198
|
+
}
|
|
199
|
+
]
|
|
200
|
+
}
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### Step 10: Follow Up
|
|
204
|
+
|
|
205
|
+
- [ ] Respond to author's questions
|
|
206
|
+
- [ ] Re-review after changes are made
|
|
207
|
+
- [ ] Update review status if issues are resolved
|
|
208
|
+
|
|
209
|
+
## Review Checklist Summary
|
|
210
|
+
|
|
211
|
+
**Must Check:**
|
|
212
|
+
- ✅ Functionality works correctly
|
|
213
|
+
- ✅ Security vulnerabilities
|
|
214
|
+
- ✅ Test coverage adequate
|
|
215
|
+
- ✅ Follows project patterns
|
|
216
|
+
- ✅ PR size reasonable
|
|
217
|
+
- ✅ Breaking changes identified and properly handled
|
|
218
|
+
|
|
219
|
+
**Should Check:**
|
|
220
|
+
- Code quality and maintainability
|
|
221
|
+
- Performance considerations
|
|
222
|
+
- Documentation completeness
|
|
223
|
+
- Error handling
|
|
224
|
+
|
|
225
|
+
**Nice to Check:**
|
|
226
|
+
- Code style consistency
|
|
227
|
+
- Minor optimizations
|
|
228
|
+
- Documentation improvements
|
|
229
|
+
|
|
230
|
+
## Output Format
|
|
231
|
+
|
|
232
|
+
Provide:
|
|
233
|
+
|
|
234
|
+
1. **Review Summary:**
|
|
235
|
+
- Overall assessment
|
|
236
|
+
- Number of blocking/important/suggestion comments
|
|
237
|
+
- Key findings
|
|
238
|
+
|
|
239
|
+
2. **Comments Posted:**
|
|
240
|
+
- List of comments with file:line references
|
|
241
|
+
- Categorization (blocking/important/suggestion)
|
|
242
|
+
|
|
243
|
+
3. **Review Decision:**
|
|
244
|
+
- Approve / Request Changes / Comment
|
|
245
|
+
- Rationale
|
|
246
|
+
|
|
247
|
+
4. **Positive Feedback:**
|
|
248
|
+
- What was done well
|
|
249
|
+
- Appreciate good patterns or solutions
|
|
250
|
+
|
|
251
|
+
## Notes
|
|
252
|
+
|
|
253
|
+
- **Read every line** of changed code
|
|
254
|
+
- **Understand context** before commenting
|
|
255
|
+
- **Be constructive** - focus on code, not person
|
|
256
|
+
- **Ask questions** rather than making demands
|
|
257
|
+
- **Reference standards** from project rules
|
|
258
|
+
- **Test locally** if possible for complex changes
|
|
259
|
+
- **Focus on scope** - don't request out-of-scope changes
|
|
260
|
+
- Use the ask questions tool if PR context is unclear
|
|
261
|
+
|
|
262
|
+
## References
|
|
263
|
+
|
|
264
|
+
- [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - PR review standards
|
|
265
|
+
- [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) - Code quality standards
|
|
266
|
+
- [testing.mdc](mdc:.cursor/rules/testing.mdc) - Test requirements
|
|
267
|
+
- [code-quality.mdc](mdc:.cursor/rules/code-quality.mdc) - Code structure standards
|
package/README.md
CHANGED
|
@@ -4,10 +4,12 @@ A tool for managing Cursor IDE rules and Claude Code configuration across differ
|
|
|
4
4
|
|
|
5
5
|
## Overview
|
|
6
6
|
|
|
7
|
-
This project provides a structured way to manage AI agent rules for different development environments while maintaining a shared base configuration. It generates:
|
|
7
|
+
This project provides a structured way to manage AI agent rules and skills for different development environments while maintaining a shared base configuration. It generates:
|
|
8
8
|
|
|
9
|
-
- **Cursor IDE**: `.cursor/rules/*.mdc` files
|
|
10
|
-
- **Claude Code**: A combined `CLAUDE.md` file
|
|
9
|
+
- **Cursor IDE**: `.cursor/rules/*.mdc` files and `.cursor/skills/*/SKILL.md` files
|
|
10
|
+
- **Claude Code**: A combined `CLAUDE.md` file and `.claude/skills/*/SKILL.md` files
|
|
11
|
+
- **Codex**: `.codex/skills/*/SKILL.md` files
|
|
12
|
+
- **Cross-platform Skills**: Skills are automatically copied to all three platform directories for maximum compatibility
|
|
11
13
|
|
|
12
14
|
It supports three main environment types:
|
|
13
15
|
|
|
@@ -50,12 +52,13 @@ npx @mallardbay/cursor-rules backend
|
|
|
50
52
|
|
|
51
53
|
## Project Structure
|
|
52
54
|
|
|
53
|
-
The rules are organized in the following directory structure:
|
|
55
|
+
The rules and skills are organized in the following directory structure:
|
|
54
56
|
|
|
55
57
|
```
|
|
56
58
|
.cursor/
|
|
57
59
|
├── shared/
|
|
58
|
-
│
|
|
60
|
+
│ ├── rules/ # Shared base rules
|
|
61
|
+
│ └── skills/ # Shared skills (installable workflows)
|
|
59
62
|
├── frontend/
|
|
60
63
|
│ └── rules/ # Frontend-specific rules
|
|
61
64
|
├── frontend-lib/
|
|
@@ -78,15 +81,34 @@ Running the setup script generates:
|
|
|
78
81
|
```
|
|
79
82
|
your-project/
|
|
80
83
|
├── .cursor/
|
|
81
|
-
│
|
|
82
|
-
│
|
|
83
|
-
│
|
|
84
|
-
│
|
|
84
|
+
│ ├── rules/ # Cursor IDE rules (*.mdc files)
|
|
85
|
+
│ │ ├── code-quality.mdc
|
|
86
|
+
│ │ ├── testing.mdc
|
|
87
|
+
│ │ └── ...
|
|
88
|
+
│ └── skills/ # Cursor Skills (installable workflows)
|
|
89
|
+
│ ├── example-skill/
|
|
90
|
+
│ │ └── SKILL.md
|
|
91
|
+
│ └── create-pr/
|
|
92
|
+
│ └── SKILL.md
|
|
93
|
+
├── .claude/
|
|
94
|
+
│ └── skills/ # Claude Code Skills (same skills)
|
|
95
|
+
│ ├── example-skill/
|
|
96
|
+
│ │ └── SKILL.md
|
|
97
|
+
│ └── create-pr/
|
|
98
|
+
│ └── SKILL.md
|
|
99
|
+
├── .codex/
|
|
100
|
+
│ └── skills/ # Codex Skills (same skills)
|
|
101
|
+
│ ├── example-skill/
|
|
102
|
+
│ │ └── SKILL.md
|
|
103
|
+
│ └── create-pr/
|
|
104
|
+
│ └── SKILL.md
|
|
85
105
|
└── CLAUDE.md # Claude Code configuration (combined rules)
|
|
86
106
|
```
|
|
87
107
|
|
|
88
108
|
The `CLAUDE.md` file combines all applicable rules into a single file, with YAML frontmatter stripped for compatibility with Claude Code.
|
|
89
109
|
|
|
110
|
+
Skills are automatically discovered by Cursor, Claude Code, and Codex, and can be invoked with `/skill-name` in chat. The setup script copies skills to all three platform directories for cross-platform compatibility.
|
|
111
|
+
|
|
90
112
|
## Development
|
|
91
113
|
|
|
92
114
|
### Adding New Rules
|
|
@@ -94,14 +116,39 @@ The `CLAUDE.md` file combines all applicable rules into a single file, with YAML
|
|
|
94
116
|
1. Create `.mdc` files in the appropriate rules directory
|
|
95
117
|
2. Rules will be automatically copied to `.cursor/rules/` when running the setup script
|
|
96
118
|
|
|
119
|
+
### Adding New Skills
|
|
120
|
+
|
|
121
|
+
1. Create a skill directory in `.cursor/shared/skills/your-skill-name/`
|
|
122
|
+
2. Add a `SKILL.md` file with YAML frontmatter and instructions
|
|
123
|
+
3. Optionally add `scripts/`, `references/`, or `assets/` directories
|
|
124
|
+
4. Skills will be automatically copied to `.cursor/skills/`, `.claude/skills/`, and `.codex/skills/` when running the setup script for cross-platform compatibility
|
|
125
|
+
5. See [SKILLS.md](SKILLS.md) for detailed documentation
|
|
126
|
+
|
|
97
127
|
### Directory Structure
|
|
98
128
|
|
|
99
129
|
- `bin/setup-cursor.sh`: Main setup script
|
|
100
130
|
- `.cursor/shared/rules/`: Shared base rules
|
|
131
|
+
- `.cursor/shared/skills/`: Shared skills (installable workflows)
|
|
101
132
|
- `.cursor/frontend/rules/`: Frontend-specific rules
|
|
102
133
|
- `.cursor/frontend-lib/rules/`: Frontend library-specific rules
|
|
103
134
|
- `.cursor/backend/rules/`: Backend-specific rules
|
|
104
135
|
|
|
136
|
+
## Skills
|
|
137
|
+
|
|
138
|
+
This repository includes example Cursor Skills that can be installed:
|
|
139
|
+
|
|
140
|
+
- **example-skill**: Template for creating new skills
|
|
141
|
+
- **create-pr**: Workflow for creating well-structured pull requests
|
|
142
|
+
- **prep-for-pr**: Prepare your branch for a PR by checking and fixing code quality issues
|
|
143
|
+
- **review-pr**: Systematically review someone else's PR with code quality, security, and standards checks
|
|
144
|
+
- **address-pr-feedback**: Find PR by branch, review feedback, create plan, implement fixes, and resolve GitHub conversations
|
|
145
|
+
|
|
146
|
+
See [SKILLS.md](SKILLS.md) for complete documentation on:
|
|
147
|
+
- Creating new skills
|
|
148
|
+
- Installing skills from GitHub
|
|
149
|
+
- Skill structure and format
|
|
150
|
+
- Best practices
|
|
151
|
+
|
|
105
152
|
## License
|
|
106
153
|
|
|
107
154
|
[Add your license information here]
|
package/bin/setup-cursor.sh
CHANGED
|
@@ -24,8 +24,12 @@ SHARED_DIR="$SRC_DIR/.cursor/shared/rules"
|
|
|
24
24
|
FRONTEND_DIR="$SRC_DIR/.cursor/frontend/rules"
|
|
25
25
|
FRONTEND_LIB_DIR="$SRC_DIR/.cursor/frontend-lib/rules"
|
|
26
26
|
BACKEND_DIR="$SRC_DIR/.cursor/backend/rules"
|
|
27
|
+
SHARED_SKILLS_DIR="$SRC_DIR/.cursor/shared/skills"
|
|
27
28
|
|
|
28
29
|
mkdir -p .cursor/rules
|
|
30
|
+
mkdir -p .cursor/skills
|
|
31
|
+
mkdir -p .claude/skills
|
|
32
|
+
mkdir -p .codex/skills
|
|
29
33
|
|
|
30
34
|
# Temporary file to collect CLAUDE.md content
|
|
31
35
|
CLAUDE_MD_TEMP=$(mktemp)
|
|
@@ -39,6 +43,24 @@ copy_rules() {
|
|
|
39
43
|
fi
|
|
40
44
|
}
|
|
41
45
|
|
|
46
|
+
copy_skills() {
|
|
47
|
+
local DIR="$1"
|
|
48
|
+
if [ -d "$DIR" ]; then
|
|
49
|
+
echo "Copying skills from: $DIR"
|
|
50
|
+
# Copy each skill directory to all three locations for cross-platform compatibility
|
|
51
|
+
for skill_dir in "$DIR"/*; do
|
|
52
|
+
if [ -d "$skill_dir" ] && [ -f "$skill_dir/SKILL.md" ]; then
|
|
53
|
+
skill_name=$(basename "$skill_dir")
|
|
54
|
+
echo " - Copying skill: $skill_name"
|
|
55
|
+
# Copy to Cursor, Claude, and Codex skill directories
|
|
56
|
+
cp -r "$skill_dir" .cursor/skills/ 2>/dev/null || true
|
|
57
|
+
cp -r "$skill_dir" .claude/skills/ 2>/dev/null || true
|
|
58
|
+
cp -r "$skill_dir" .codex/skills/ 2>/dev/null || true
|
|
59
|
+
fi
|
|
60
|
+
done
|
|
61
|
+
fi
|
|
62
|
+
}
|
|
63
|
+
|
|
42
64
|
# Append rules to CLAUDE.md (strips YAML frontmatter)
|
|
43
65
|
append_to_claude_md() {
|
|
44
66
|
local DIR="$1"
|
|
@@ -66,6 +88,9 @@ append_to_claude_md() {
|
|
|
66
88
|
copy_rules "$SHARED_DIR"
|
|
67
89
|
append_to_claude_md "$SHARED_DIR"
|
|
68
90
|
|
|
91
|
+
# Always include shared skills
|
|
92
|
+
copy_skills "$SHARED_SKILLS_DIR"
|
|
93
|
+
|
|
69
94
|
# Inheritance handling
|
|
70
95
|
case "$ENV_TYPE" in
|
|
71
96
|
frontend)
|
|
@@ -93,4 +118,11 @@ mv "$CLAUDE_MD_TEMP" CLAUDE.md
|
|
|
93
118
|
trap - EXIT
|
|
94
119
|
echo "CLAUDE.md generated for Claude Code"
|
|
95
120
|
|
|
96
|
-
|
|
121
|
+
if [ -d ".cursor/skills" ] && [ "$(ls -A .cursor/skills 2>/dev/null)" ]; then
|
|
122
|
+
echo "Skills installed in:"
|
|
123
|
+
echo " - .cursor/skills/ (Cursor)"
|
|
124
|
+
echo " - .claude/skills/ (Claude Code)"
|
|
125
|
+
echo " - .codex/skills/ (Codex)"
|
|
126
|
+
fi
|
|
127
|
+
|
|
128
|
+
echo "Setup complete for '$ENV_TYPE' (Cursor + Claude + Codex)"
|