@mallardbay/cursor-rules 1.0.34 → 1.1.0

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

@@ -48,9 +48,6 @@ 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/{mobile-ui.mdc → ui.mdc}

@@ -87,7 +87,6 @@ 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/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
+-   Reference related issues/tickets
 -   Respond to review comments promptly

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

@@ -139,34 +139,7 @@ gh pr comment <number> --body "@reviewer Ready for another look! ✅"
 
 ## Output Format
 
-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.
+Provide: PR status (conflicts & checks), summary of feedback addressed, changes made, conversations resolved, remaining items, next steps.
 
 ## Notes
 

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

@@ -120,8 +120,6 @@ 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>
 
@@ -144,26 +142,6 @@ 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.
+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.
+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
 
@@ -22,12 +22,17 @@ Automates the workflow of staging untracked files, committing changes, and creat
 
 ## Usage Examples
 
-- `/commit-and-pr` - Commit changes and create a PR
-- `commit and create PR` - Same workflow using natural language
+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
 
-**Important:** Do not request or require ticket/issue numbers. This workflow no longer depends on issue IDs.
+**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.
 
 ### Step 1: Check Git Status and Branch
 
@@ -90,7 +95,29 @@ Verify what was added:
 git status
 ```
 
-### Step 3: Analyze Changes for Commit Message
+### 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
 
 Before committing, analyze the changes to infer commit type and description:
 
@@ -117,7 +144,7 @@ git diff --cached --stat
 - Create a concise, descriptive summary
 - Use present tense, imperative mood (e.g., "Add feature" not "Added feature")
 
-### Step 4: Commit Changes
+### Step 5: Commit Changes
 
 **Prepare commit message:**
 
@@ -125,8 +152,12 @@ 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:
@@ -150,6 +181,8 @@ 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)
@@ -163,6 +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 GitHub issue number when prompted: `#<issue-number>` (include # prefix for GitHub linking)
 
 Then run: `yarn commit`
 
@@ -170,36 +204,18 @@ Then run: `yarn commit`
 
 Use standard git commit with conventional commit format:
 ```bash
-git commit -m "<type>: <description>"
+git commit -m "<type>: <description>
+
+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)
+- `<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:**
@@ -238,8 +254,9 @@ 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. **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
+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
 
 ### Step 8: Create PR Description
 
@@ -253,9 +270,9 @@ Use the Mallard Bay PR template from: https://github.com/mallardbay/.github/blob
 
 - [Generate from commit messages and changed files]
 
-**2. Context / links (optional)**
+**2. What ticket does this PR address?**
 
-- N/A
+- #<issue-number>
 
 **3. Screenshots, clips, demo links etc**
 
@@ -286,7 +303,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 any optional context links if provided
+- 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: Check for Existing PR
@@ -303,12 +320,11 @@ 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 into `PR_URL`, `PR_NUMBER`, `PR_TITLE`
-- Also attempt to capture a `PREVIEW_URL` using the detection snippet in Step 10 (preview URL fetch)
+- 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 and preview URL
+- 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)
@@ -353,12 +369,14 @@ fi
 ```bash
 BRANCH_NAME=$(git branch --show-current)
 gh pr create \
-  --title "<type>: <description>" \
+  --title "<type>: <description> - #<issue-number>" \
   --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
@@ -371,73 +389,42 @@ 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, PR Link, and Branch Preview URL
-
-**Always display the PR link and, when available, the branch preview URL prominently at the end.**
+### Step 11: Provide Summary and PR Link
 
-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)
+**Always display the PR link prominently at the end:**
 
-If PR already existed (from Step 9 check):
-- **PR Link:** `PR_URL`
-- **Branch Preview:** `PREVIEW_URL` (include only if non-empty)
+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
 
-If PR was just created (from Step 10 creation):
-- **PR Link:** `PR_URL`
-- **Branch Preview:** `PREVIEW_URL` (include only if non-empty)
+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"
 
 **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: <PR_URL>
-🔗 Branch Preview: <PREVIEW_URL>   ← omit this line entirely if no preview URL was found
+✅ 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 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.
+**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
 
@@ -445,10 +432,14 @@ If PR was just created (from Step 10 creation):
 - 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 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`
+- 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
 
@@ -461,11 +452,13 @@ If PR was just created (from Step 10 creation):
 - **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.
+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
@@ -26,20 +26,22 @@ 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. **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
+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 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.
+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` - Commit and push changes, then handle PR
-- `commit and push changes` - Same workflow using natural language
+- `/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
 

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 issue addressed?
+- [ ] Are all requirements from the ticket/issue addressed?
 - [ ] Are edge cases handled appropriately?
 - [ ] Is error handling comprehensive?
 - [ ] Are user-facing features complete (no TODOs or placeholders)?
@@ -149,37 +149,6 @@ 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 are referenced
+- [ ] Related issues/tickets are referenced
 - [ ] Changes align with PR description
 - [ ] No unrelated changes included
 
@@ -232,47 +232,23 @@ gh pr review <pr-number> --comment --body "Review summary"
 
 Provide:
 
-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:**
+1. **Review Summary:**
    - Overall assessment
    - Number of blocking/important/suggestion comments
    - Key findings
 
-3. **Comments Posted:**
+2. **Comments Posted:**
    - List of comments with file:line references
    - Categorization (blocking/important/suggestion)
 
-4. **Review Decision:**
+3. **Review Decision:**
    - Approve / Request Changes / Comment
    - Rationale
 
-5. **Positive Feedback:**
+4. **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 referenced
+- [ ] Related issues/tickets referenced
 - [ ] No unrelated changes
 - [ ] Commit messages are descriptive
 
@@ -115,9 +115,6 @@ 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]
 
 ---
@@ -143,26 +140,6 @@ 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 issue addressed?
+- [ ] Are all requirements from the ticket/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 are referenced
+- [ ] Related issues/tickets 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.34",
+    "version": "1.1.0",
     "description": "Mallard Bay shared cursor rules",
     "main": "bin/setup-cursor.sh",
     "repository": "git@github.com:mallardbay/cursor-rules.git",
@@ -29,5 +29,6 @@
     },
     "bin": {
         "cursor-rules": "bin/setup-cursor.sh"
-    }
+    },
+    "packageManager": "yarn@4.13.0"
 }