@mallardbay/cursor-rules 1.0.27 → 1.0.29

package/.cursor/rules/code-quality.mdc

@@ -14,7 +14,13 @@ alwaysApply: false
     -   Functions: camelCase
     -   Constants: UPPER_SNAKE_CASE
     -   Types: PascalCase
--   Types should be defined at the bottom of files
+-   Follow this ordering within files:
+    1.  Imports
+    2.  Constants
+    3.  Exported functions / components
+    4.  Helpers and other non-exported definitions
+    5.  Types (when not imported)
+-   Exported members always come before non-exported members
 -   PropTypes should be defined before component definitions
 -   Prefer using alias for importing components. Only use relative for tests or when there's a direct sibling
 

package/.cursor/rules/testing.mdc

@@ -53,13 +53,14 @@ We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully
 
 ### Mocking Guidelines
 
--   Use mock helpers instead of inline mocks
--   Follow existing patterns for:
+-   **Always use mock helpers**—never define mocks inline. All mocks should come from dedicated mock helper files following existing patterns for:
     -   Entity mocks
     -   Apollo mocks
     -   Provider mocks
+-   **Mock data through Apollo mocks, not module mocks**—use Apollo mock providers to control query/mutation responses instead of mocking modules or components directly
 -   Keep mocks simple and maintainable
 -   **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
+-   **Never mock `@mallardbay/lib-react-components`**—if truly unavoidable, stop and ask for approval first
 
 ### Test Utilities
 

package/.cursor/rules/typescript.mdc

@@ -14,7 +14,13 @@ Be as strictly as possible where it delivers clear value—specifically in preve
 
 ### File Organization
 
--   Place types at the bottom of files
+-   Follow this ordering within files:
+    1.  Imports
+    2.  Constants
+    3.  Exported functions / components
+    4.  Helpers and other non-exported definitions
+    5.  Types (when not imported)
+-   Exported members always come before non-exported members
 -   Define PropTypes before component definitions
 
 ## Best Practices

package/.cursor/shared/rules/check-and-fix-ci.mdc

@@ -0,0 +1,14 @@
+---
+description: When user invokes /check-and-fix-ci, apply the check-and-fix-ci skill—find PR for current branch, check CI status, fix non-transient failures, push.
+alwaysApply: false
+---
+
+# Check and Fix CI
+
+When the user says **`/check-and-fix-ci`** (or asks to fix CI/build failures on their PR), apply the **check-and-fix-ci** skill:
+
+1. **Find PR** — `gh pr list --head $(git branch --show-current)`
+2. **Check CI status** — `gh pr checks <pr-number>` or `gh run list --branch <branch> --status failure`
+3. **Classify failures** — Transient (timeout, flaky, rate limit) vs non-transient (lint, tests, build, types)
+4. **Fix non-transient** — Run lint/tests/build locally, fix issues (apply fix-tests skill for local test/lint fixes)
+5. **Push** — Commit fixes and push; never use `eslint-disable` to silence errors

package/.cursor/shared/rules/code-quality.mdc

@@ -14,7 +14,13 @@ alwaysApply: false
     -   Functions: camelCase
     -   Constants: UPPER_SNAKE_CASE
     -   Types: PascalCase
--   Types should be defined at the bottom of files
+-   Follow this ordering within files:
+    1.  Imports
+    2.  Constants
+    3.  Exported functions / components
+    4.  Helpers and other non-exported definitions
+    5.  Types (when not imported)
+-   Exported members always come before non-exported members
 -   PropTypes should be defined before component definitions
 -   Prefer using alias for importing components. Only use relative for tests or when there's a direct sibling
 

package/.cursor/shared/rules/testing.mdc

@@ -56,13 +56,14 @@ We do not chase 100% coverage for its own sake. If a test doesn’t meaningfully
 
 ### Mocking Guidelines
 
--   Use mock helpers instead of inline mocks
--   Follow existing patterns for:
+-   **Always use mock helpers**—never define mocks inline. All mocks should come from dedicated mock helper files following existing patterns for:
     -   Entity mocks
     -   Apollo mocks
     -   Provider mocks
+-   **Mock data through Apollo mocks, not module mocks**—use Apollo mock providers to control query/mutation responses instead of mocking modules or components directly
 -   Keep mocks simple and maintainable
 -   **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
+-   **Never mock `@mallardbay/lib-react-components`**—if truly unavoidable, stop and ask for approval first
 
 ### Test Utilities
 

package/.cursor/shared/rules/typescript.mdc

@@ -14,7 +14,13 @@ Be as strictly as possible where it delivers clear value—specifically in preve
 
 ### File Organization
 
--   Place types at the bottom of files
+-   Follow this ordering within files:
+    1.  Imports
+    2.  Constants
+    3.  Exported functions / components
+    4.  Helpers and other non-exported definitions
+    5.  Types (when not imported)
+-   Exported members always come before non-exported members
 -   Define PropTypes before component definitions
 
 ## Best Practices

package/.cursor/shared/skills/check-and-fix-ci/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: check-and-fix-ci
+description: Find the PR for the current branch, check CI/build status, fix non-transient failures, and push. Use when the user says /check-and-fix-ci, CI is failing, build is red, or needs to fix and re-push after CI failures.
+version: 1.0.0
+tags:
+  - ci
+  - pr
+  - build
+  - workflow
+  - fix
+---
+
+# Check and Fix CI
+
+Find the PR for the current branch, check the build status, fix any non-transient CI failures, and push again.
+
+## When to Use
+
+- User says `/check-and-fix-ci`
+- CI is failing on a PR and needs fixing
+- Build is red and user wants to fix and re-push
+- After pushing changes and CI fails
+
+## Prerequisites
+
+- `gh` CLI installed and authenticated (`gh auth status`)
+- Run `gh` commands with network access
+
+## Instructions
+
+### Step 1: Find the PR for the Current Branch
+
+```bash
+BRANCH=$(git branch --show-current)
+gh pr list --head "$BRANCH" --json number,title,url,headRefOid
+```
+
+If no PR exists, inform the user and create one if appropriate. Otherwise proceed with the PR number.
+
+### Step 2: Check CI/Build Status
+
+```bash
+# Get check status and details
+gh pr checks <pr-number>
+# Or: gh pr view <pr-number> --json statusCheckRollup
+```
+
+**Get structured JSON for detailed failure info:**
+```bash
+gh pr view <pr-number> --json statusCheckRollup
+# Or for workflow runs: gh run list --branch <branch-name> --limit 5
+```
+
+**Check failed runs:**
+```bash
+gh run list --branch "$BRANCH" --status failure --limit 5
+# For failed run details: gh run view <run-id> --log-failed
+```
+
+### Step 3: Classify Failures
+
+**Transient (do not fix):**
+- Timeout / network flakiness
+- Rate limiting (429)
+- Resource exhaustion (e.g. "out of memory")
+- Infrastructure/service outages
+- Known flaky tests that pass on retry
+- Cancelled runs (e.g. superseded by new push)
+
+**Non-transient (fix these):**
+- Linting errors
+- Test failures (unit, integration, e2e)
+- Type errors (TypeScript)
+- Build/compile errors
+- Security/validation failures
+- Missing or incorrect configuration
+
+**How to tell:**
+- Read error messages and logs
+- Check if failure is consistent (same step/assertion always fails)
+- Transient: "timeout", "connection refused", "rate limit", "cancelled"
+- Non-transient: specific file:line, assertion, test name, lint rule
+
+### Step 4: Fix Non-Transient Issues
+
+For each non-transient failure:
+
+1. **Linting:** Run `yarn lint:quiet` or `yarn lint:quiet:slow` locally and fix issues
+2. **Tests:** Run tests locally (use sharding when appropriate: `yarn test --shard=1/4`, etc.)
+3. **Build:** Run build command locally (`yarn build`, etc.)
+4. **Type errors:** Run `tsc --noEmit` or equivalent
+
+**Reference:** [fix-tests](.cursor/shared/skills/fix-tests/SKILL.md) skill for local test/lint fixes; [testing.mdc](mdc:.cursor/rules/testing.mdc) and [general-best-practices.mdc](mdc:.cursor/rules/general-best-practices.mdc) for standards.
+
+**Never add `eslint-disable`** to silence errors—fix the underlying issue.
+
+### Step 5: Push and Verify
+
+```bash
+git add -A
+git status
+git commit -m "fix: <description of what was fixed>"
+git push origin "$BRANCH"
+```
+
+After pushing, wait for CI to re-run. If using `gh run watch`:
+```bash
+gh run watch
+```
+
+### Step 6: Report Outcome
+
+- **All fixed:** Summarize what was fixed and that CI should pass
+- **Transient only:** Explain which failures are transient and suggest retrying (`gh pr checks --watch` or re-run in GitHub UI)
+- **Mixed:** Fix non-transient, push, and note any transient ones to retry
+- **Unclear:** Share failure logs and ask user for guidance
+
+## Output Format
+
+```markdown
+## CI Check Results
+
+**PR:** #<number> - <title>
+**Branch:** <branch>
+
+### Status
+- [ ] / [x] Lint
+- [ ] / [x] Tests
+- [ ] / [x] Build
+- Other: <list>
+
+### Failures
+| Check | Type | Action |
+|-------|------|--------|
+| <name> | transient / non-transient | <fixed / retry / skip> |
+
+### Actions Taken
+- <what was fixed>
+- <what was pushed>
+
+### Next Steps
+- <if any remain>
+```
+
+## Notes
+
+- Prioritize fixing non-transient issues; don't waste time on flaky/timeout failures
+- Run fixes locally before pushing to avoid repeated CI cycles
+- Use `gh run view <run-id> --log-failed` to see detailed failure logs
+- If `gh` hits auth/rate issues, prompt user to run `gh auth login` and retry

package/README.md

@@ -147,6 +147,7 @@ This repository includes example Cursor Skills that can be installed:
 - **prep-for-pr**: Prepare your branch for a PR by checking and fixing code quality issues
 - **review-pr**: Systematically review someone else's PR with code quality, security, and standards checks
 - **address-pr-feedback**: Find PR by branch, review feedback, create plan, implement fixes, and resolve GitHub conversations
+- **check-and-fix-ci**: Find PR for current branch, check CI status, fix non-transient failures, and push (invoke with `/check-and-fix-ci`)
 
 See [SKILLS.md](SKILLS.md) for complete documentation on:
 - Creating new skills

package/package.json

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