@mallardbay/cursor-rules 1.0.32 → 1.0.34

package/.cursor/frontend/rules/ui.mdc

@@ -48,6 +48,9 @@ Maintain clean and consistent component structure:
 
 -   Use existing components in @mallardbay/lib-react-components, @mallardbay/lib-react-components is based off Crakra UI v2
 -   If no component available in @mallardbay/lib-react-components, create one using Crakra UI and place it under src/components/shared/todo-lib-react-components/ to me moved later
+-   **Do not import directly from `@chakra-ui/react`**—always import components, hooks, and utilities from `@mallardbay/lib-react-components` instead
+    -   This ensures a consistent design system, proper theming, and easier future migrations
+    -   If something you need is not re-exported by `@mallardbay/lib-react-components`, add it there first rather than importing from `@chakra-ui/react` directly
 
 ## Responsive Design
 

package/.cursor/frontend-mobile/rules/{ui.mdc → mobile-ui.mdc}

@@ -87,6 +87,7 @@ Maintain clean and consistent component structure:
 ### React Native Specifics
 
 - Use `StyleSheet.create` or NativeBase style props — avoid inline object styles
+- **`StyleSheet.create` must be placed at the bottom of the file** — never at the top. See [react-native.mdc](mdc:react-native.mdc) for full file ordering and the `useStyles` hook pattern
 - Prefer `FlatList` / `SectionList` over mapping arrays for long lists
 - Use platform-specific extensions (`.ios.tsx`, `.android.tsx`) only when behavior genuinely diverges
 - Test on both iOS and Android

package/.cursor/frontend-mobile/rules/react-native.mdc

@@ -0,0 +1,92 @@
+---
+description: React Native specific conventions for styling, component structure, and patterns that complement the general UI and TypeScript rules
+globs:
+alwaysApply: true
+---
+
+# React Native Development Standards
+
+These rules extend the general UI, TypeScript, and code quality standards with React Native specific conventions.
+
+## Styling
+
+### File Ordering for Styles
+
+StyleSheet definitions must live at the **bottom** of the file, after all component and helper definitions—following the same principle as types. This keeps the scannable, important logic (exports, components, hooks) at the top.
+
+**File ordering for RN component files:**
+
+1. Imports
+2. Constants
+3. Exported components / functions
+4. Helpers and non-exported definitions
+5. Types (when not imported)
+6. StyleSheet definitions (`StyleSheet.create`)
+
+### Prefer Hook-Based Styling Over Static StyleSheets
+
+When styles need access to **theme values, colors, spacing, or any dynamic context**, use a `useStyles` hook pattern instead of a top-level `StyleSheet.create`. This avoids hardcoding values that should come from the theme and prevents painful refactors later.
+
+- **Use `StyleSheet.create` only for truly static styles** that will never need theme values
+- **Use a `useStyles` hook** when styles depend on theme, colors, spacing, or dynamic values
+- Even when using `StyleSheet.create`, place it at the bottom of the file
+
+```typescript
+// Preferred: hook-based styling with theme access
+function useStyles() {
+    const theme = useTheme()
+
+    return useMemo(
+        () =>
+            StyleSheet.create({
+                container: {
+                    padding: theme.space[4],
+                    backgroundColor: theme.colors.background,
+                },
+                title: {
+                    fontSize: theme.fontSizes.lg,
+                    color: theme.colors.text,
+                },
+            }),
+        [theme]
+    )
+}
+```
+
+```typescript
+// Acceptable: static styles that genuinely don't need theme
+// BUT must be at the BOTTOM of the file
+const styles = StyleSheet.create({
+    row: {
+        flexDirection: "row",
+        alignItems: "center",
+    },
+})
+```
+
+### Avoid Hardcoded Style Values
+
+- Never hardcode colors — use theme colors
+- Never hardcode spacing — use theme spacing
+- Never hardcode font sizes — use theme typography
+- If you find yourself reaching for a hardcoded value in `StyleSheet.create`, that's a signal to switch to `useStyles`
+
+## Performance
+
+### Lists
+
+- Use `FlatList` or `SectionList` for long lists — never `ScrollView` with `.map()`
+- Always provide a `keyExtractor`
+- Use `getItemLayout` when item heights are known for better scroll performance
+- Memoize `renderItem` callbacks with `useCallback`
+
+### Images
+
+- Use cached image libraries (e.g., `react-native-fast-image`) over the default `Image` when dealing with remote URLs
+- Always specify image dimensions to avoid layout thrashing
+
+### Animations
+
+- Prefer `react-native-reanimated` over `Animated` API for complex animations
+- Run animations on the UI thread when possible
+- Avoid JS-driven animations for performance-critical interactions

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

@@ -82,6 +82,12 @@ These principles apply to all code changes and should guide every implementation
 - Use shared test utilities and fixtures to reduce boilerplate
 - Each test should be independent and runnable in isolation
 
+### Before Pushing
+- **Lint the entire project** before pushing—not just modified files. Use `yarn lint:quiet:slow` for a full deep check. Your changes may introduce lint errors in files you didn't directly edit (e.g. unused exports, circular dependencies, type mismatches)
+- **Run related tests** before pushing to confirm nothing is broken. Identify test files related to your changes and run them. If unsure which tests are related, err on the side of running more rather than fewer
+- **Fix any failures before pushing**—do not push code that fails lint or tests
+- These checks are a hard gate: **no push without a clean lint and passing tests**
+
 ### Code Organization
 - Group related functionality together
 - Keep related code close (cohesion)
@@ -141,6 +147,11 @@ These principles apply to all code changes and should guide every implementation
 5. **Verify the change works** end-to-end
 6. **Check for side effects**—ensure changes don't break unrelated code
 
+### Before Pushing
+1. **Lint the entire project** with `yarn lint:quiet:slow`—not just modified files. Fix all failures
+2. **Run related tests** and ensure they pass. If unsure which tests are related, run more rather than fewer
+3. **Do not push** until lint and tests are clean
+
 ### When Changes Are Large
 1. **Consider splitting** into multiple smaller PRs
 2. **Use test sharding**—run tests in batches, not all at once

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

@@ -42,5 +42,5 @@ Ensure comprehensive test coverage:
 
 -   Keep PRs focused and manageable
 -   Include clear PR descriptions
--   Reference related issues/tickets
+-   Reference related issues
 -   Respond to review comments promptly

package/.cursor/shared/skills/address-pr-feedback/SKILL.md

@@ -139,7 +139,34 @@ gh pr comment <number> --body "@reviewer Ready for another look! ✅"
 
 ## Output Format
 
-Provide: PR status (conflicts & checks), summary of feedback addressed, changes made, conversations resolved, remaining items, next steps.
+Always start the output with the PR link and the branch preview URL (when available), then provide the rest of the summary.
+
+```markdown
+**PR Link:** <pr-url>
+**Branch Preview:** <preview-url>   ← include only if detected; omit entirely otherwise
+```
+
+Then provide: PR status (conflicts & checks), summary of feedback addressed, changes made, conversations resolved, remaining items, next steps.
+
+### Detecting the Branch Preview URL
+
+```bash
+PR_NUMBER=<pr-number>
+
+PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+  --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+        | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+        | .[0] // ""')
+
+if [ -z "$PREVIEW_URL" ]; then
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+    --jq '.comments[]?.body' \
+    | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+    | head -1)
+fi
+```
+
+Do not use a placeholder such as "n/a" when no preview URL is found—omit the line.
 
 ## Notes
 

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

@@ -120,6 +120,8 @@ gh run watch
 ```markdown
 ## CI Check Results
 
+**PR Link:** <pr-url>
+**Branch Preview:** <preview-url>   ← include only if detected; omit entirely otherwise
 **PR:** #<number> - <title>
 **Branch:** <branch>
 
@@ -142,6 +144,26 @@ gh run watch
 - <if any remain>
 ```
 
+### Detecting the Branch Preview URL
+
+```bash
+PR_NUMBER=<pr-number>
+
+PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+  --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+        | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+        | .[0] // ""')
+
+if [ -z "$PREVIEW_URL" ]; then
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+    --jq '.comments[]?.body' \
+    | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+    | head -1)
+fi
+```
+
+Omit the Branch Preview line entirely when no preview URL is detected—do not use a placeholder.
+
 ## Notes
 
 - Prioritize fixing non-transient issues; don't waste time on flaky/timeout failures

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. 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.
+description: Add untracked files, commit changes using yarn commit (if available) with prefilled answers, and create a PR using the Mallard Bay template.
 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. 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.
+Automates the workflow of staging untracked files, committing changes, and creating a pull request. Uses `yarn commit` (commitizen) if available with prefilled answers.
 
 ## When to Use
 
@@ -22,17 +22,12 @@ Automates the workflow of staging untracked files, committing changes, and creat
 
 ## 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.
+- `/commit-and-pr` - Commit changes and create a PR
+- `commit and create PR` - Same workflow using natural language
 
 ## Instructions
 
-**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.
+**Important:** Do not request or require ticket/issue numbers. This workflow no longer depends on issue IDs.
 
 ### Step 1: Check Git Status and Branch
 
@@ -95,29 +90,7 @@ Verify what was added:
 git status
 ```
 
-### Step 3: Get GitHub Issue Number
-
-**Priority order for finding GitHub issue number:**
-
-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
+### Step 3: Analyze Changes for Commit Message
 
 Before committing, analyze the changes to infer commit type and description:
 
@@ -144,7 +117,7 @@ git diff --cached --stat
 - Create a concise, descriptive summary
 - Use present tense, imperative mood (e.g., "Add feature" not "Added feature")
 
-### Step 5: Commit Changes
+### Step 4: Commit Changes
 
 **Prepare commit message:**
 
@@ -152,12 +125,8 @@ Create a commit message using the inferred type and description from Step 4:
 
 ```bash
 # Format: <type>: <description>
-# 
-# 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:
@@ -181,8 +150,6 @@ Create a commit message file and use it:
 # Create commit message file
 cat > /tmp/commit-msg.txt <<EOF
 <type>: <description>
-
-Closes #<issue-number>
 EOF
 
 # Use git commit directly (bypasses commitizen but uses same format)
@@ -196,7 +163,6 @@ 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 GitHub issue number when prompted: `#<issue-number>` (include # prefix for GitHub linking)
 
 Then run: `yarn commit`
 
@@ -204,18 +170,36 @@ Then run: `yarn commit`
 
 Use standard git commit with conventional commit format:
 ```bash
-git commit -m "<type>: <description>
-
-Closes #<issue-number>"
+git commit -m "<type>: <description>"
 ```
 
 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)
-- `<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 5: Lint and Test Before Pushing
+
+**This is a hard gate—do not push until lint and tests are clean.**
+
+**Lint the entire project:**
+```bash
+yarn lint:quiet:slow
+```
+
+- Fix all lint errors before proceeding. Your changes may introduce lint errors in files you didn't directly edit (e.g. unused exports, circular dependencies, type mismatches).
+- Do not disable eslint rules to make errors go away—fix the underlying issues.
+
+**Run related tests:**
+```bash
+# Identify test files related to your changes and run them
+# If unsure which tests are related, err on the side of running more
+```
+
+- Ensure all related tests pass before pushing.
+- If any tests fail, fix the failures before proceeding.
+
 ### Step 6: Push Branch
 
 **Before pushing, verify branch protection one more time:**
@@ -254,9 +238,8 @@ 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. **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
+3. **Commit messages:** Use `git log origin/main..HEAD --oneline` to get commit messages since base branch
+4. **Changed files:** Use `git diff --name-status origin/main...HEAD` to see what changed
 
 ### Step 8: Create PR Description
 
@@ -270,9 +253,9 @@ Use the Mallard Bay PR template from: https://github.com/mallardbay/.github/blob
 
 - [Generate from commit messages and changed files]
 
-**2. What ticket does this PR address?**
+**2. Context / links (optional)**
 
-- #<issue-number>
+- N/A
 
 **3. Screenshots, clips, demo links etc**
 
@@ -303,7 +286,7 @@ 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 GitHub issue number (format as `#123`)
+- Fill in section 2 with any optional context links if provided
 - Leave sections 3 and 4 as TODO for the developer to fill
 
 ### Step 9: Check for Existing PR
@@ -320,11 +303,12 @@ 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
+- Extract the PR URL, number, and title from the JSON output into `PR_URL`, `PR_NUMBER`, `PR_TITLE`
+- Also attempt to capture a `PREVIEW_URL` using the detection snippet in Step 10 (preview URL fetch)
 - 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
+- Skip PR creation and proceed to Step 11 with the existing PR information and preview URL
 
 **If PR does not exist** (exit code non-zero or empty PR_INFO):
 - Continue to create a new PR (proceed to Step 10)
@@ -369,14 +353,12 @@ fi
 ```bash
 BRANCH_NAME=$(git branch --show-current)
 gh pr create \
-  --title "<type>: <description> - #<issue-number>" \
+  --title "<type>: <description>" \
   --body "<PR description from Step 8>" \
   --base "$BASE_BRANCH" \
   --head "$BRANCH_NAME"
 ```
 
-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
@@ -389,42 +371,73 @@ PR_TITLE=$(gh pr view "$BRANCH_NAME" --json title --jq '.title')
 # Store these for use in Step 11
 ```
 
+**Capture branch preview URL (if available):**
+
+Many projects have a preview deployment (Vercel, Netlify, Cloudflare Pages, Render, etc.) that exposes a per-branch URL via a status check or a bot-posted PR comment. Attempt to detect it:
+
+```bash
+# Prefer status checks - deployment providers usually expose a targetUrl/detailsUrl
+PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+  --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+        | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+        | .[0] // ""')
+
+# Fallback: scan PR comments for preview URLs posted by deployment bots
+if [ -z "$PREVIEW_URL" ]; then
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+    --jq '.comments[]?.body' \
+    | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+    | head -1)
+fi
+```
+
+Preview checks may take a few seconds to appear after pushing. If `PREVIEW_URL` is empty, it's fine—omit the preview line from the final summary rather than showing a placeholder.
+
 **Handle errors:**
 - 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
+### Step 11: Provide Summary, PR Link, and Branch Preview URL
+
+**Always display the PR link and, when available, the branch preview URL prominently at the end.**
 
-**Always display the PR link prominently at the end:**
+Before returning the summary, make sure you have captured (from Step 9 or Step 10):
+- `PR_URL` — the pull request URL
+- `PR_NUMBER` — the pull request number
+- `PR_TITLE` — the pull request title
+- `PREVIEW_URL` — the branch preview deployment URL (may be empty)
 
-If PR already existed (from Step 9):
-- **PR Link:** `https://github.com/<owner>/<repo>/pull/<number>`
+If PR already existed (from Step 9 check):
+- **PR Link:** `PR_URL`
+- **Branch Preview:** `PREVIEW_URL` (include only if non-empty)
 - Message: "PR already exists for this branch"
 - PR number and title
 
-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)
+If PR was just created (from Step 10 creation):
+- **PR Link:** `PR_URL`
+- **Branch Preview:** `PREVIEW_URL` (include only if non-empty)
 - Success message: "PR created successfully"
 
 **Additional summary information:**
 - Summary of what was committed
 - 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 Link: <PR_URL>
+🔗 Branch Preview: <PREVIEW_URL>   ← omit this line entirely if no preview URL was found
 📋 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.
+**CRITICAL:**
+- Always display the PR link prominently at the very end of your response. Make it the most visible element—use markdown formatting so it stands out and is clickable.
+- Always include the branch preview URL when one was detected. It is the second most important output for visual/QA review.
+- If no preview URL was detected, do NOT show a placeholder like "n/a" or "none"—simply omit the Branch Preview line.
 
 ## Error Handling
 
@@ -432,14 +445,10 @@ If PR was just created (from Step 10):
 - Fall back to standard `git commit`
 - Inform user that commitizen wasn't used
 
-**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:**
-- 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`
+- Verify branch is pushed (should already be done in Step 5)
+- Check authentication status (should already be verified in Step 9)
+- If PR already exists, this should have been caught in Step 8 - double-check with `gh pr view`
 - Provide clear error message and next steps
 - Still attempt to show PR link if one exists
 
@@ -452,13 +461,11 @@ If PR was just created (from Step 10):
 - **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.)
-- 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 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

@@ -1,6 +1,6 @@
 ---
 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").
+description: Alias for commit-and-pr skill. Commits changes and pushes to remote. If PR exists, shows link; if not, creates PR.
 version: 1.0.0
 tags:
     - commit
@@ -26,22 +26,20 @@ This is an alias skill that uses the same functionality as `commit-and-pr`. It c
 
 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
+3. **Analyze Changes** - Infer commit type and description from changes
+4. **Commit Changes** - Use `yarn commit` if available, or standard git commit with conventional format
+5. **Lint and Test** - Lint the entire project (`yarn lint:quiet:slow`) and run related tests. Fix all failures before pushing
 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
+9. **Show PR Link and Branch Preview URL** - Always display the PR link prominently at the end, and include the branch preview URL whenever a preview deployment is detected (see `commit-and-pr` Step 10/11 for the detection snippet and output format). Omit the preview line entirely if no URL is found—do not use a placeholder.
 
 **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
+- `/commit-and-push` - Commit and push changes, then handle PR
+- `commit and push changes` - Same workflow using natural language
 
 ## Notes
 

package/.cursor/shared/skills/prep-for-pr/SKILL.md

@@ -34,7 +34,7 @@ Systematically check the new work on this branch and fix issues as you find them
 ### Code Quality Checks
 
 **Feature Gaps**
-- [ ] Are all requirements from the ticket/issue addressed?
+- [ ] Are all requirements from the issue addressed?
 - [ ] Are edge cases handled appropriately?
 - [ ] Is error handling comprehensive?
 - [ ] Are user-facing features complete (no TODOs or placeholders)?
@@ -149,6 +149,37 @@ After preparing the branch, provide:
 2. **Issues Fixed**: List of specific issues that were addressed
 3. **Remaining Items**: Any items that need attention but couldn't be fixed automatically
 4. **Readiness Status**: Whether the branch is ready for PR creation
+5. **PR Link and Branch Preview URL**: If a PR already exists for this branch, include:
+   - **PR Link:** the pull request URL
+   - **Branch Preview:** the preview deployment URL (if one is detected)
+
+   If no PR exists yet (this skill commonly runs before PR creation), clearly note "No PR yet—run `/commit-and-pr` to create one" instead of fabricating a link.
+
+### Detecting PR and Preview URL
+
+```bash
+BRANCH=$(git branch --show-current)
+PR_JSON=$(gh pr view "$BRANCH" --json url,number 2>/dev/null)
+
+if [ -n "$PR_JSON" ]; then
+  PR_URL=$(echo "$PR_JSON" | jq -r '.url')
+  PR_NUMBER=$(echo "$PR_JSON" | jq -r '.number')
+
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+    --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+          | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+          | .[0] // ""')
+
+  if [ -z "$PREVIEW_URL" ]; then
+    PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+      --jq '.comments[]?.body' \
+      | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+      | head -1)
+  fi
+fi
+```
+
+Omit the Branch Preview line entirely if no preview URL is detected—do not show a placeholder.
 
 ## Notes
 

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

@@ -45,7 +45,7 @@ gh pr list --head <branch-name> --json number,title,url
 
 - [ ] PR size is reasonable (see [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - max 400 lines)
 - [ ] PR description is clear and explains purpose
-- [ ] Related issues/tickets are referenced
+- [ ] Related issues are referenced
 - [ ] Changes align with PR description
 - [ ] No unrelated changes included
 
@@ -232,23 +232,47 @@ gh pr review <pr-number> --comment --body "Review summary"
 
 Provide:
 
-1. **Review Summary:**
+1. **PR Link and Branch Preview URL** (always at the top so it's easy to jump to):
+   - **PR Link:** the pull request URL
+   - **Branch Preview:** the preview deployment URL (include only when detected)
+
+2. **Review Summary:**
    - Overall assessment
    - Number of blocking/important/suggestion comments
    - Key findings
 
-2. **Comments Posted:**
+3. **Comments Posted:**
    - List of comments with file:line references
    - Categorization (blocking/important/suggestion)
 
-3. **Review Decision:**
+4. **Review Decision:**
    - Approve / Request Changes / Comment
    - Rationale
 
-4. **Positive Feedback:**
+5. **Positive Feedback:**
    - What was done well
    - Appreciate good patterns or solutions
 
+### Detecting the Branch Preview URL
+
+```bash
+PR_NUMBER=<pr-number>
+
+PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+  --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+        | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+        | .[0] // ""')
+
+if [ -z "$PREVIEW_URL" ]; then
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+    --jq '.comments[]?.body' \
+    | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+    | head -1)
+fi
+```
+
+Omit the Branch Preview line entirely if no preview URL is detected—do not show a placeholder like "n/a".
+
 ## Notes
 
 - **Read every line** of changed code

package/.cursor/shared/skills/should-we-merge/SKILL.md

@@ -104,7 +104,7 @@ Review the PR against project standards. **Assign every finding to exactly one s
 
 **PR hygiene:**
 - [ ] PR description explains purpose
-- [ ] Related issues/tickets referenced
+- [ ] Related issues referenced
 - [ ] No unrelated changes
 - [ ] Commit messages are descriptive
 
@@ -115,6 +115,9 @@ Use this output format:
 ```markdown
 ## Should We Merge? [YES / NO / CONDITIONAL]
 
+**PR Link:** <pr-url>
+**Branch Preview:** <preview-url>   ← include only if detected; omit entirely otherwise
+
 **Summary:** [1–2 sentence verdict]
 
 ---
@@ -140,6 +143,26 @@ Use this output format:
 - [Rules/standards cited]
 ```
 
+### Detecting the Branch Preview URL
+
+```bash
+PR_NUMBER=<pr-number>
+
+PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json statusCheckRollup \
+  --jq '[.statusCheckRollup[]? | (.targetUrl // .detailsUrl // "")]
+        | map(select(test("vercel\\.app|netlify\\.app|pages\\.dev|onrender\\.com|preview"; "i")))
+        | .[0] // ""')
+
+if [ -z "$PREVIEW_URL" ]; then
+  PREVIEW_URL=$(gh pr view "$PR_NUMBER" --json comments \
+    --jq '.comments[]?.body' \
+    | grep -oE 'https?://[a-zA-Z0-9.-]+\.(vercel\.app|netlify\.app|pages\.dev|onrender\.com)[^ )>"]*' \
+    | head -1)
+fi
+```
+
+Omit the Branch Preview line entirely when no preview URL is detected—do not use a placeholder like "n/a".
+
 **Merge decision logic:**
 - **YES** — No P0 issues; P1 issues are minimal or acceptable to merge with follow-up
 - **NO** — Any P0 issues

package/.cursor/skills/prep-for-pr/SKILL.md

@@ -34,7 +34,7 @@ Systematically check the new work on this branch and fix issues as you find them
 ### Code Quality Checks
 
 **Feature Gaps**
-- [ ] Are all requirements from the ticket/issue addressed?
+- [ ] Are all requirements from the issue addressed?
 - [ ] Are edge cases handled appropriately?
 - [ ] Is error handling comprehensive?
 - [ ] Are user-facing features complete (no TODOs or placeholders)?

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

@@ -45,7 +45,7 @@ gh pr list --head <branch-name> --json number,title,url
 
 - [ ] PR size is reasonable (see [code-review.mdc](mdc:.cursor/rules/code-review.mdc) - max 400 lines)
 - [ ] PR description is clear and explains purpose
-- [ ] Related issues/tickets are referenced
+- [ ] Related issues are referenced
 - [ ] Changes align with PR description
 - [ ] No unrelated changes included
 

package/package.json

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