@mallardbay/cursor-rules 1.0.21 → 1.0.24

package/.cursor/shared/rules/general-best-practices.mdc

@@ -114,6 +114,11 @@ These principles apply to all code changes and should guide every implementation
 4. **Check git history** to understand why code exists as it does
 5. **Identify related files** that might be affected
 6. **Ask clarifying questions** if requirements are unclear
+7. **Use MCP servers when available**—leverage Model Context Protocol servers for enhanced capabilities
+   - **Context7 MCP**: Use the context7 MCP server when available to retrieve up-to-date documentation and code examples for libraries
+   - If context7 MCP is not available, suggest adding it to improve access to library documentation
+   - **Suggest useful MCP servers**: When appropriate, suggest popular and useful MCP servers that could enhance development workflow based on the task at hand
+   - Consider MCP servers for documentation, testing, debugging, and other development tasks
 
 ### During Implementation
 1. Make **small, incremental changes**

package/.cursor/shared/skills/commit-and-pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: commit-and-pr
-description: Add untracked files, commit changes using yarn commit (if available) with prefilled answers, and create a PR using the Mallard Bay template. Only requires ticket number from developer.
+description: Add untracked files, commit changes using yarn commit (if available) with prefilled answers, and create a PR using the Mallard Bay template. GitHub issue number can be provided in the message (e.g., "/commit-and-pr 123" or "/commit-and-pr #123") or will be extracted from commit or asked if needed.
 version: 1.0.0
 tags:
   - pr
@@ -11,7 +11,7 @@ tags:
 
 # Commit and Create PR
 
-Automates the workflow of staging untracked files, committing changes, and creating a pull request. Uses `yarn commit` (commitizen) if available with prefilled answers, requiring only the ticket number from the developer. If changes are already committed, extracts the ticket number from the commit message.
+Automates the workflow of staging untracked files, committing changes, and creating a pull request. Uses `yarn commit` (commitizen) if available with prefilled answers. The GitHub issue number can be provided when invoking the skill (e.g., `/commit-and-pr 123` or `/commit-and-pr #123`), extracted from existing commit messages, or will be requested if not found.
 
 ## When to Use
 
@@ -20,14 +20,27 @@ Automates the workflow of staging untracked files, committing changes, and creat
 - When you need to add untracked files and commit them
 - User mentions committing changes, creating PR, or opening pull request
 
+## Usage Examples
+
+You can invoke this skill with a GitHub issue number:
+- `/commit-and-pr 123` - Commit and create PR for issue #123
+- `/commit-and-pr #123` - Commit and create PR for issue #123 (with # prefix)
+- `commit and create PR for issue 456` - Extract issue number from message
+- `commit-and-pr` - Will extract issue number from commit or ask for it
+
+The issue number can be provided in various formats: `123`, `#123`, `issue 123`, `ticket 123`, etc.
+
 ## Instructions
 
-### Step 1: Check Git Status
+**Important:** When this skill is invoked, check the user's message for a GitHub issue number first. Users can provide the issue number when invoking the skill (e.g., `/commit-and-pr 123` or `/commit-and-pr #123` or "commit and create PR for issue 123"). Extract it from their message before asking for it.
 
-First, check the current git status to understand what needs to be committed:
+### Step 1: Check Git Status and Branch
+
+First, check the current git status and branch:
 
 ```bash
 git status
+git branch --show-current
 ```
 
 Identify:
@@ -36,6 +49,39 @@ Identify:
 - Current branch name
 - Whether there are any uncommitted changes
 
+**CRITICAL: Verify Branch Protection**
+
+**Never push directly to protected branches:**
+- `main`
+- `development`
+- `production`
+
+**If currently on a protected branch:**
+1. **Stop immediately** - do not commit or push
+2. Create a new branch with a semantic release prefix:
+   - `feat/` - for new features
+   - `fix/` - for bug fixes
+   - `test/` - for test-related changes
+   - `docs/` - for documentation
+   - `refactor/` - for refactoring
+   - `chore/` - for maintenance tasks
+   - `perf/` - for performance improvements
+   - `style/` - for formatting/style changes
+3. **Example branch names:**
+   - `feat/add-user-authentication`
+   - `fix/resolve-login-bug`
+   - `test/add-component-tests`
+   - `docs/update-api-documentation`
+4. Switch to the new branch:
+   ```bash
+   git checkout -b <semantic-prefix>/<descriptive-name>
+   ```
+5. Then proceed with the commit and PR workflow
+
+**If already on a feature branch:**
+- Verify the branch name follows semantic prefix conventions
+- If it doesn't, consider renaming it before proceeding (optional but recommended)
+
 ### Step 2: Add Untracked Files
 
 Add all untracked files to staging:
@@ -49,17 +95,27 @@ Verify what was added:
 git status
 ```
 
-### Step 3: Get Ticket Number
+### Step 3: Get GitHub Issue Number
 
-**If not already committed:**
-- Ask the developer for the ticket number (e.g., "MB-123", "123", "TICKET-456")
-- Store this for use in commit and PR
+**Priority order for finding GitHub issue number:**
 
-**If already committed:**
-- Extract ticket number from the most recent commit message
-- Use `git log -1 --pretty=%B` to get the last commit message
-- Look for ticket patterns like: `MB-123`, `[MB-123]`, `(MB-123)`, `TICKET-123`, or just numbers
-- If ticket number is found in commit, use it; otherwise ask the developer
+1. **Check user's message** (if skill was invoked with issue number):
+   - Look for GitHub issue number patterns in the user's message when invoking the skill
+   - Common patterns: `#123`, `123`, `issue 123`, `ticket 123`, `[#123]`, `(#123)`, `Closes #123`, `Closes 123`
+   - Examples: User says "/commit-and-pr 123" or "/commit-and-pr #123" or "commit and create PR for issue 123"
+   - Extract the issue number from the message if present (remove # prefix if present, store as plain number)
+
+2. **If already committed** (and issue number not in user message):
+   - Extract issue number from the most recent commit message
+   - Use `git log -1 --pretty=%B` to get the last commit message
+   - Look for issue patterns like: `#123`, `Closes #123`, `Closes 123`, `[#123]`, `(#123)`, `issue 123`, or just numbers
+   - If issue number is found in commit, use it (extract number, ignore # prefix)
+
+3. **If not found** (and not already committed):
+   - Ask the developer for the GitHub issue number (e.g., "123" or "#123")
+   - Store this as a plain number (without # prefix) for use in commit and PR
+
+**Note:** When a user invokes this skill with an issue number (e.g., `/commit-and-pr 123` or `/commit-and-pr #123` or "commit and create PR for issue 123"), extract the issue number from their message rather than asking for it. Store issue numbers as plain numbers (e.g., `123`) for consistency, even if user provides `#123`.
 
 ### Step 4: Analyze Changes for Commit Message
 
@@ -97,9 +153,11 @@ Create a commit message using the inferred type and description from Step 4:
 ```bash
 # Format: <type>: <description>
 # 
-# Closes <ticket-number>
+# Closes #<issue-number>
 ```
 
+Where `<issue-number>` is the GitHub issue number from Step 3 (use `#` prefix in commit message for GitHub to link it).
+
 **If `yarn commit` is available:**
 
 Check if `yarn commit` script exists:
@@ -124,7 +182,7 @@ Create a commit message file and use it:
 cat > /tmp/commit-msg.txt <<EOF
 <type>: <description>
 
-Closes <ticket-number>
+Closes #<issue-number>
 EOF
 
 # Use git commit directly (bypasses commitizen but uses same format)
@@ -138,7 +196,7 @@ If commitizen requires interactive input, inform the developer they'll need to:
 - Confirm scope (if applicable, leave blank or suggest based on changed files)
 - Confirm short description (suggest: `<inferred-description>`)
 - Skip long description (unless needed)
-- Enter ticket number when prompted: `<ticket-number>`
+- Enter GitHub issue number when prompted: `#<issue-number>` (include # prefix for GitHub linking)
 
 Then run: `yarn commit`
 
@@ -148,18 +206,33 @@ Use standard git commit with conventional commit format:
 ```bash
 git commit -m "<type>: <description>
 
-Closes <ticket-number>"
+Closes #<issue-number>"
 ```
 
 Where:
 - `<type>` is the inferred commit type from Step 4 (e.g., `feat`, `fix`, `docs`)
 - `<description>` is the inferred description from Step 4 (concise, present tense)
-- `<ticket-number>` is the ticket number from Step 3
+- `<issue-number>` is the GitHub issue number from Step 3 (use `#` prefix for GitHub to automatically link the issue)
 
 **Important:** Always ensure the commit message follows conventional commit format. If commitizen interaction fails or is not available, use standard git commit with a properly formatted message.
 
 ### Step 6: Push Branch
 
+**Before pushing, verify branch protection one more time:**
+
+```bash
+CURRENT_BRANCH=$(git branch --show-current)
+PROTECTED_BRANCHES="main development production"
+
+if echo "$PROTECTED_BRANCHES" | grep -q "$CURRENT_BRANCH"; then
+  echo "ERROR: Cannot push to protected branch: $CURRENT_BRANCH"
+  echo "Please create a feature branch with semantic prefix (feat/, fix/, test/, etc.)"
+  exit 1
+fi
+```
+
+**If branch is safe to push:**
+
 Push the current branch to remote:
 ```bash
 git push origin $(git branch --show-current)
@@ -170,13 +243,18 @@ If branch doesn't exist on remote, set upstream:
 git push -u origin $(git branch --show-current)
 ```
 
+**Branch naming reminder:**
+- Use semantic prefixes: `feat/`, `fix/`, `test/`, `docs/`, `refactor/`, `chore/`, `perf/`, `style/`
+- Follow with descriptive name: `feat/add-user-authentication`, `fix/resolve-login-bug`
+- Never push directly to `main`, `development`, or `production`
+
 ### Step 7: Extract PR Information
 
 Gather information needed for PR:
 
 1. **Branch name:** `git branch --show-current`
 2. **Base branch:** Usually `main` or `master` (check with `git remote show origin`)
-3. **Ticket number:** From Step 3
+3. **GitHub issue number:** From Step 3
 4. **Commit messages:** Use `git log origin/main..HEAD --oneline` to get commit messages since base branch
 5. **Changed files:** Use `git diff --name-status origin/main...HEAD` to see what changed
 
@@ -194,7 +272,7 @@ Use the Mallard Bay PR template from: https://github.com/mallardbay/.github/blob
 
 **2. What ticket does this PR address?**
 
-- <ticket-number>
+- #<issue-number>
 
 **3. Screenshots, clips, demo links etc**
 
@@ -225,10 +303,37 @@ Use the Mallard Bay PR template from: https://github.com/mallardbay/.github/blob
 - Analyze commit messages to understand what the PR does
 - List key changes from `git diff --name-status`
 - Fill in section 1 with a summary based on commits and changes
-- Fill in section 2 with the ticket number
+- Fill in section 2 with the GitHub issue number (format as `#123`)
 - Leave sections 3 and 4 as TODO for the developer to fill
 
-### Step 9: Create PR Using GitHub CLI
+### Step 9: Check for Existing PR
+
+**Before creating a PR, check if one already exists:**
+
+```bash
+# Get current branch name
+BRANCH_NAME=$(git branch --show-current)
+
+# Check if PR exists for this branch
+PR_INFO=$(gh pr view "$BRANCH_NAME" --json url,number,title,state 2>/dev/null)
+EXIT_CODE=$?
+```
+
+**If PR already exists** (exit code 0 and PR_INFO contains data):
+- Extract the PR URL, number, and title from the JSON output
+- Display a message: "PR already exists for this branch"
+- Show the PR link: Use the `url` field from JSON (e.g., `https://github.com/<owner>/<repo>/pull/<number>`)
+- Show PR number and title
+- Skip PR creation and proceed to Step 11 with the existing PR information
+
+**If PR does not exist** (exit code non-zero or empty PR_INFO):
+- Continue to create a new PR (proceed to Step 10)
+
+**Note:** The `gh pr view` command returns a non-zero exit code if no PR exists, which is expected behavior. Only proceed with creation if the PR truly doesn't exist.
+
+### Step 10: Create PR Using GitHub CLI (if needed)
+
+**Only execute this step if no PR exists from Step 9.**
 
 **Check GitHub CLI authentication:**
 ```bash
@@ -240,33 +345,86 @@ If not authenticated, prompt user to run:
 gh auth login
 ```
 
+**Detect base branch:**
+```bash
+# Try to detect the default branch
+BASE_BRANCH=$(git remote show origin | grep "HEAD branch" | cut -d' ' -f5)
+
+# Fallback to common branch names if detection fails
+if [ -z "$BASE_BRANCH" ]; then
+  # Check which branch exists
+  if git show-ref --verify --quiet refs/remotes/origin/main; then
+    BASE_BRANCH="main"
+  elif git show-ref --verify --quiet refs/remotes/origin/master; then
+    BASE_BRANCH="master"
+  elif git show-ref --verify --quiet refs/remotes/origin/develop; then
+    BASE_BRANCH="develop"
+  else
+    BASE_BRANCH="main"  # Default fallback
+  fi
+fi
+```
+
 **Create the PR:**
 ```bash
+BRANCH_NAME=$(git branch --show-current)
 gh pr create \
-  --title "<type>: <description> - <ticket-number>" \
-  --body "<PR description from Step 7>" \
-  --base main \
-  --head $(git branch --show-current)
+  --title "<type>: <description> - #<issue-number>" \
+  --body "<PR description from Step 8>" \
+  --base "$BASE_BRANCH" \
+  --head "$BRANCH_NAME"
 ```
 
-**If base branch is different:**
-- Detect base branch: `git remote show origin | grep "HEAD branch" | cut -d' ' -f5`
-- Or check common branches: `main`, `master`, `develop`
-- Use detected base branch in `--base` flag
+Where `<issue-number>` is the GitHub issue number from Step 3 (include `#` prefix in title for GitHub linking).
+
+**Capture PR URL and details:**
+```bash
+# Get the PR URL and number after creation
+# The gh pr create command outputs the PR URL, but we'll also fetch it to be sure
+PR_URL=$(gh pr view "$BRANCH_NAME" --json url --jq '.url')
+PR_NUMBER=$(gh pr view "$BRANCH_NAME" --json number --jq '.number')
+PR_TITLE=$(gh pr view "$BRANCH_NAME" --json title --jq '.title')
+
+# If gh pr create already output a URL, use that; otherwise use the fetched one
+# Store these for use in Step 11
+```
 
 **Handle errors:**
-- If PR already exists, inform user and provide link
 - If authentication fails, prompt user to authenticate
 - If branch conflicts, inform user
+- If creation fails for other reasons, provide clear error message
+
+### Step 11: Provide Summary and PR Link
+
+**Always display the PR link prominently at the end:**
+
+If PR already existed (from Step 9):
+- **PR Link:** `https://github.com/<owner>/<repo>/pull/<number>`
+- Message: "PR already exists for this branch"
+- PR number and title
 
-### Step 10: Provide Summary
+If PR was just created (from Step 10):
+- **PR Link:** `https://github.com/<owner>/<repo>/pull/<number>` (from captured PR_URL)
+- PR number (from captured PR_NUMBER)
+- Success message: "PR created successfully"
 
-After PR is created, provide:
-- PR URL
-- PR number
+**Additional summary information:**
 - Summary of what was committed
-- Reminder to fill in TODO sections in PR description
-- Next steps (e.g., request reviewers, add labels)
+- Branch name
+- Base branch
+- GitHub issue number used (format as `#123`)
+- Reminder to fill in TODO sections in PR description (sections 3 and 4)
+- Next steps (e.g., request reviewers, add labels, fill in screenshots/demo links)
+
+**Format the final output clearly:**
+```markdown
+✅ PR Link: https://github.com/<owner>/<repo>/pull/<number>
+📋 PR #<number>: <title>
+🎫 Issue: #<issue-number>
+🌿 Branch: <branch-name> → <base-branch>
+```
+
+**CRITICAL:** Always display the PR link prominently at the very end of your response. Make it the most visible element - use markdown formatting to make it stand out, and ensure it's clickable. The PR link is the most important output of this skill.
 
 ## Error Handling
 
@@ -274,15 +432,16 @@ After PR is created, provide:
 - Fall back to standard `git commit`
 - Inform user that commitizen wasn't used
 
-**If ticket number not found:**
-- Ask user for ticket number explicitly
-- If user doesn't provide, create PR without ticket number (they can add later)
+**If GitHub issue number not found:**
+- Ask user for GitHub issue number explicitly
+- If user doesn't provide, create PR without issue number (they can add later or link manually)
 
 **If PR creation fails:**
-- Check if PR already exists
-- Verify branch is pushed
-- Check authentication status
+- Verify branch is pushed (should already be done in Step 6)
+- Check authentication status (should already be verified in Step 10)
+- If PR already exists, this should have been caught in Step 9 - double-check with `gh pr view`
 - Provide clear error message and next steps
+- Still attempt to show PR link if one exists
 
 **If no changes to commit:**
 - Inform user there are no changes
@@ -290,13 +449,17 @@ After PR is created, provide:
 
 ## Notes
 
+- **CRITICAL: Never push directly to protected branches** (`main`, `development`, `production`)
+- **Always use semantic release prefixes** for branch names (`feat/`, `fix/`, `test/`, `docs/`, `refactor/`, `chore/`, `perf/`, `style/`)
 - This skill assumes conventional commit format (feat, fix, docs, etc.)
-- Ticket number format may vary - be flexible in detection
+- GitHub issue numbers are plain numbers (e.g., `123`) but should be formatted with `#` prefix in commit messages and PR titles for GitHub linking
 - PR template TODOs should be filled by developer after PR creation
-- Always verify git status before making changes
+- Always verify git status and branch name before making changes
 - Use GitHub CLI (`gh`) for PR creation - it's the most reliable method
 - If commitizen config is non-standard, may need to adapt the commit step
 - Consider running `prep-for-pr` skill before this one to ensure code quality
+- When extracting issue numbers, remove `#` prefix for storage but add it back when using in commits/PRs for GitHub linking
+- If on a protected branch, create a feature branch first before committing
 
 ## Authentication
 

package/.cursor/shared/skills/commit-and-push/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: commit-and-push
+description: Alias for commit-and-pr skill. Commits changes and pushes to remote. If PR exists, shows link; if not, creates PR. GitHub issue number can be provided (e.g., "/commit-and-push 123").
+version: 1.0.0
+tags:
+    - commit
+    - push
+    - workflow
+    - git
+    - alias
+---
+
+# Commit and Push (Alias)
+
+This is an alias skill that uses the same functionality as `commit-and-pr`. It commits changes, pushes to remote, and handles PRs (shows existing PR link or creates new one if needed).
+
+## When to Use
+
+- When you want to commit and push changes
+- When you want a shorter command than `/commit-and-pr`
+- User mentions "commit and push", "commit changes", or similar
+
+## Instructions
+
+**This skill provides the same functionality as `commit-and-pr`.** Follow the complete workflow from the `commit-and-pr` skill, which includes:
+
+1. **Check Git Status** - Understand what needs to be committed
+2. **Add Untracked Files** - Stage all untracked files with `git add .`
+3. **Get GitHub Issue Number** - Extract from user message, existing commit, or ask
+4. **Analyze Changes** - Infer commit type and description from changes
+5. **Commit Changes** - Use `yarn commit` if available, or standard git commit with conventional format
+6. **Push Branch** - Push to remote, set upstream if needed
+7. **Check for Existing PR** - If PR exists, show link and skip creation
+8. **Create PR** - If no PR exists, create one using Mallard Bay template
+9. **Show PR Link** - Always display PR link prominently at the end
+
+**Reference:** See `.cursor/shared/skills/commit-and-pr/SKILL.md` for complete detailed instructions. This alias uses identical logic and behavior.
+
+## Usage Examples
+
+- `/commit-and-push 123` - Commit and push for issue #123
+- `/commit-and-push #123` - Commit and push for issue #123 (with # prefix)
+- `/commit-and-push` - Extract issue number from commit or ask
+- `commit and push changes` - Extract issue number from commit or ask
+
+## Notes
+
+- This skill provides the same functionality as `commit-and-pr`
+- Use whichever name feels more natural: `/commit-and-pr` or `/commit-and-push`
+- Both skills behave identically
+- **CRITICAL: Never push directly to protected branches** (`main`, `development`, `production`) - always use semantic prefix branches (`feat/`, `fix/`, `test/`, etc.)

package/.cursor/shared/skills/fix-tests/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: fix-tests
+description: Fix failing tests and linting errors to get the build green locally. Prioritize understanding failures before making changes. Fix all failures, even if not caused by our changes. Use when tests are failing, linting errors exist, or the build needs to be fixed.
+version: 1.0.0
+tags:
+  - tests
+  - linting
+  - debugging
+  - test-fixes
+  - quality
+  - workflow
+  - build
+---
+
+# Fix Tests and Linting
+
+Fix failing tests and linting errors to get the build green locally. Prioritize understanding failures before making changes. Fix all failures, even if they weren't caused by our changes. This skill helps maintain code quality and ensures the build passes.
+
+## When to Use
+
+- When tests are failing and need to be fixed
+- When linting errors exist and need to be resolved
+- When the build is failing and needs to be fixed
+- User mentions failing tests, linting errors, or build failures
+- After code changes break existing tests or introduce linting errors
+- When tests need updates due to API or behavior changes
+- **Goal: Get the build green locally**—fix all test and linting failures
+
+## Instructions
+
+**Critical Principle: Prioritize understanding failures over making changes without understanding.** Always analyze and understand the root cause before applying fixes.
+
+### Running Tests with Sharding
+
+**Use test sharding to run tests efficiently:**
+- **Server projects**: Run tests in 10 shards (e.g., `yarn test --shard=1/10`, `yarn test --shard=2/10`, etc.)
+- **Frontend projects**: Run tests in 4 shards (e.g., `yarn test --shard=1/4`, `yarn test --shard=2/4`, etc.)
+- Run all shards to ensure complete test coverage
+- This prevents running all tests in parallel and helps identify failures more efficiently
+
+### Fixing Tests
+
+1. **Identify failing tests**
+   - Run the test suite using appropriate sharding (10 shards for server, 4 for frontend)
+   - Run all shards to get a complete picture of failures
+   - Identify which tests are failing
+   - Note error messages and stack traces
+
+2. **Analyze test failures (CRITICAL: Understand before fixing)**
+   - **Prioritize understanding**: Read error messages carefully, understand what each test is trying to verify
+   - **Investigate root causes**: Don't make changes until you understand why tests are failing
+   - Identify the root cause of failures by examining:
+     - Code changes that broke existing behavior
+     - Test setup or mocking issues
+     - Outdated test expectations
+     - Missing dependencies or configuration
+     - Flaky test conditions
+     - Pre-existing failures (tests that were already broken)
+   - **Fix all failures**: Even if a test failure wasn't caused by our changes, we still need to fix it to get the build green
+
+3. **Apply appropriate fixes**
+   - Fix code if tests revealed actual bugs
+   - Update tests if expectations need to change
+   - Fix test setup, mocks, or fixtures
+   - Update test utilities or helpers
+   - Address timing or async issues
+   - Fix pre-existing failures—don't skip tests that were already broken
+
+4. **Verify fixes**
+   - Run tests again using sharding to confirm fixes work
+   - Run all shards to ensure no new failures were introduced
+   - Verify test coverage is maintained
+
+5. **Follow testing standards**
+   - Adhere to project testing standards (see [testing.mdc](mdc:.cursor/rules/testing.mdc))
+   - Maintain test quality and clarity
+   - Keep tests focused and atomic
+   - Use appropriate test utilities and patterns
+
+### Fixing Linting Errors
+
+1. **Run linting**
+   - Use `yarn lint:quiet:slow` to identify all linting errors (as specified in [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc))
+   - This provides deeper checks and identifies all issues
+
+2. **Analyze linting errors (CRITICAL: Understand before fixing)**
+   - **Prioritize understanding**: Read each linting error carefully
+   - **Investigate root causes**: Understand why each error exists before fixing
+   - **Never disable eslint rules** to make errors go away—fix the underlying issues instead
+   - Identify if errors are due to:
+     - Code quality issues that need fixing
+     - Missing dependencies or configuration
+     - Pre-existing errors (linting issues that were already present)
+   - **Fix all errors**: Even if a linting error wasn't caused by our changes, we still need to fix it to get the build green
+
+3. **Apply appropriate fixes**
+   - Fix code quality issues properly
+   - Add missing dependencies or configuration
+   - Refactor code to address linting concerns
+   - Fix pre-existing errors—don't skip linting issues that were already present
+   - **Never add `eslint-disable` comments** unless there's a legitimate, documented reason
+
+4. **Verify fixes**
+   - Run `yarn lint:quiet:slow` again to confirm all errors are resolved
+   - Ensure no new linting errors were introduced
+
+### Final Verification
+
+- Run all test shards to ensure all tests pass
+- Run `yarn lint:quiet:slow` to ensure all linting errors are resolved
+- **Goal achieved**: Build is green locally with all tests passing and no linting errors
+
+## Notes
+
+- **Always understand failures before fixing**—prioritize understanding over quick fixes
+- **Fix all failures**—even if they weren't caused by our changes, we need to fix them to get the build green
+- Focus on fixing root causes, not symptoms
+- Use test sharding (10 for server, 4 for frontend) to run tests efficiently
+- Use `yarn lint:quiet:slow` for comprehensive linting checks
+- Never disable eslint rules—fix the underlying issues instead
+- Ensure tests accurately validate expected behavior
+- Maintain or improve test coverage
+- Follow existing test patterns and conventions
+- Keep tests clear, fast, and maintainable
+- **Goal: Get the build green locally**—all tests passing, no linting errors

package/.cursor/shared/skills/review-pr/SKILL.md

@@ -136,6 +136,7 @@ Check for breaking changes that could affect clients:
    - **Important** - Should fix (code quality, maintainability)
    - **Suggestion** - Nice to have (style, minor improvements)
    - **Question** - Need clarification
+   
 
 2. **Write constructive comments:**
    - Be specific about the issue

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mallardbay/cursor-rules",
-    "version": "1.0.21",
+    "version": "1.0.24",
     "description": "Mallard Bay shared cursor rules",
     "main": "bin/setup-cursor.sh",
     "repository": "git@github.com:mallardbay/cursor-rules.git",