chore: sync upstream preview into main (105 commits) + reconcile custom features

.claude/skills/branch-name/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: branch-name
+description: Use when starting a new branch or renaming an existing one — produces a branch name in the format `<type>/<work-item-id>-<short-description>` that's compatible with the create-pr skill's work item ID extraction.
+user_invocable: true
+---
+
+# Branch Naming
+
+Create branch names that follow the convention `<type>/<work-item-id>-<short-description>`, where the work item ID can be cleanly extracted later (e.g., by the create-pr skill).
+
+## Format
+
+```
+<type>/<work-item-id>-<short-description>
+```
+
+- All lowercase, hyphen-separated
+- Work item ID stays in its original form but lowercased (e.g., `SILO-1146` → `silo-1146`)
+- Short description is 2–5 words in kebab-case, focused on the _what_, not the _how_
+
+## Workflow
+
+1. **Determine the type** based on the work being done:
+   - `feat` — new functionality
+   - `fix` — bug fix
+   - `chore` — tooling, deps, config, non-user-facing housekeeping
+   - `refactor` — restructuring without behavior change
+   - `docs` — documentation only
+   - `perf` — performance improvement
+
+2. **Determine the work item ID**:
+   - If the user gives one, use it
+   - If they reference a Plane work item (e.g., a URL or title), extract the ID
+   - If none exists, ask the user — don't invent one
+
+3. **Write the short description**:
+   - 2–5 words in kebab-case
+   - Describe the outcome, not the implementation (`add-app-tile-visibility`, not `update-tile-component`)
+   - Skip filler words (`the`, `a`, `for`)
+
+4. **Assemble and create the branch**:
+
+```
+   git checkout -b <type>/<work-item-id-lowercased>-<short-description>
+```
+
+5. **Return the branch name** to the user.
+
+## Examples
+
+```
+fix/silo-1146-relative-config-urls
+feat/web-1234-app-tile-visibility
+chore/web-2201-bump-eslint
+refactor/silo-980-extract-auth-middleware
+docs/web-1500-pr-template-update
+perf/silo-1310-cache-workspace-lookup
+```
+
+## Common Mistakes
+
+- Putting the work item ID at the end instead of after the type (breaks extraction)
+- Using underscores or camelCase instead of hyphens
+- Uppercasing the work item ID inside the branch name (it should be lowercase here, uppercased only when used as the PR title prefix)
+- Writing a long, narrative description — keep it scannable
+- Omitting the work item ID when one exists in Plane
+- Using a type that won't match the eventual PR type (pick the type you'd use in the PR title)

.claude/skills/create-pull-request/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: create-pull-request
+description: Use when creating a pull request for the current branch — gathers branch context, generates a PR description following the repo's pull_request_template.md, and creates the PR with a Plane work item ID prefix in the title.
+user_invocable: true
+---
+
+# Create PR
+
+Create a pull request using the repo's PR template, a Plane work item ID as the title prefix, and a fully filled-out description based on the actual diff.
+
+## Workflow
+
+1. **Determine the base branch**: Default to `preview` unless the user specifies otherwise.
+
+2. **Gather context** (in parallel):
+   - `git status -s` — check for uncommitted changes
+   - `git diff <base>...HEAD --stat` — files changed
+   - `git log <base>...HEAD --oneline` — all commits on the branch
+   - `git diff <base>...HEAD --no-color` — full diff for understanding changes (if very large, focus on the most important files first)
+   - `git rev-parse --abbrev-ref --symbolic-full-name @{u}` — check if branch tracks a remote
+   - Read `.github/pull_request_template.md` from the repo root
+
+3. **Determine work item ID**:
+   - Extract from branch name if it contains an identifier (e.g., `chore/silo-1146-foo` → `SILO-1146`, `feat/web-1234-x` → `WEB-1234`)
+   - If not found in branch name, ask the user
+
+4. **Draft the PR** using the template from step 2:
+
+   **Title**: `[WORK-ITEM-ID] <type>: <concise summary>` (under 70 chars)
+   - Type reflects the change: `fix`, `feat`, `chore`, `refactor`, `docs`, `perf`, etc.
+
+   **Body**: Fill in every section from the PR template based on the actual diff:
+   - **Description** — Clear, concise summary of what the PR does and why. Focus on the "what" and "why", not line-by-line changes. Mention important implementation decisions.
+   - **Type of Change** — Check the appropriate box(es): Bug fix, Feature, Improvement, Code refactoring, Performance improvements, Documentation update.
+   - **Screenshots and Media** — Leave a placeholder: `<!-- Add screenshots here -->`
+   - **Test Scenarios** — Suggest concrete scenarios grounded in the actual changes (e.g., "Navigate to project settings and verify the new toggle works"), not generic ones.
+   - **References** — Include the work item ID, any linked issues the user mentions, and any Sentry issue links/IDs (e.g., `SENTRY-ABC123` or Sentry URLs) referenced earlier in the conversation.
+
+   Append a Claude Code session line at the bottom of the body.
+
+5. **Push and create** (in parallel where possible):
+   - Push branch with `-u` if no upstream is set
+   - Create PR via `gh pr create` using a HEREDOC for the body
+
+6. **Return the PR URL** to the user.
+
+## Example Title
+
+```
+[SILO-1146] fix: allow relative URLs for configuration_url and improve app tile visibility
+```
+
+## Guidelines
+
+- Keep the description concise but informative
+- Use bullet points when listing multiple changes
+- Focus on user-facing impact, not implementation details
+- Don't fabricate test scenarios that aren't relevant to the actual changes
+
+## Common Mistakes
+
+- Summarizing only the latest commit instead of all commits on the branch
+- Forgetting to check for an upstream before pushing
+- Using a work item ID format that doesn't match the branch convention
+- Wrapping the PR body in a code fence when passing it to `gh pr create`

.claude/skills/react-doctor/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: react-doctor
+description: Use when finishing a feature, fixing a bug, before committing React code, or when the user types `/doctor`, asks to scan, triage, or clean up React diagnostics. Covers lint, accessibility, bundle size, architecture. Includes a regression check and a full local-triage workflow that fetches the canonical playbook.
+version: "1.1.0"
+---
+
+# React Doctor
+
+Scans React codebases for security, performance, correctness, and architecture issues. Outputs a 0–100 health score.
+
+## After making React code changes:
+
+Run `npx react-doctor@latest --verbose --diff` and check the score did not regress.
+
+If the score dropped, fix the regressions before committing.
+
+## For general cleanup or code improvement:
+
+Run `npx react-doctor@latest --verbose` (without `--diff`) to scan the full codebase. Fix issues by severity — errors first, then warnings.
+
+## /doctor — full local triage workflow
+
+When the user types `/doctor`, says "run react doctor", or asks for a full triage / cleanup pass (not just a regression check), fetch the canonical local-triage playbook and follow every step in it:
+
+```bash
+curl --fail --silent --show-error \
+  --header 'Cache-Control: no-cache' \
+  https://www.react.doctor/prompts/react-doctor-agent.md
+```
+
+The playbook is the single source of truth — a scan → filter → triage → fix → validate loop that edits the working tree directly (never commits, never opens PRs). Updating the prompt at its source updates every agent on its next fetch — no skill reinstall needed.
+
+Pair it with the matching per-rule prompts at `https://www.react.doctor/prompts/rules/<plugin>/<rule>.md` (fetched on demand inside the playbook) so each fix uses the canonical, reviewer-tested recipe.
+
+## Configuring or explaining rules
+
+When the user wants to understand a rule, disagrees with one, or wants to disable / tune which rules run (not fix code), use the `doctor-explain` skill (alias `/doctor-config`). Start with `npx react-doctor@latest rules explain <rule>`, then apply the narrowest control via `npx react-doctor@latest rules disable|set|category|ignore-tag …`, which edits your `doctor.config.*` (or `package.json#reactDoctor`).
+
+## Command
+
+```bash
+npx react-doctor@latest --verbose --diff
+```
+
+| Flag        | Purpose                                       |
+| ----------- | --------------------------------------------- |
+| `.`         | Scan current directory                        |
+| `--verbose` | Show affected files and line numbers per rule |
+| `--diff`    | Only scan changed files vs base branch        |
+| `--score`   | Output only the numeric score                 |

.claude/skills/release-notes/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: release-notes
+description: "Generate release notes for a Plane release PR in either `makeplane/plane-cloud` (date-based versioning, e.g. `release: vYY.MM.DD-N`) or `makeplane/plane-ee` (semver, e.g. `release: vX.Y.Z`). Reads PR commits, filters out noise, categorizes by conventional-commit type, optionally enriches via Plane MCP, and writes the result as the PR description in the GitHub Releases format."
+user_invocable: true
+---
+
+# Release Notes Generator
+
+Generate structured release notes from a Plane release PR by parsing its commit list, then update the PR description. Output matches the format used on `github.com/makeplane/plane/releases` (e.g. [v1.2.0](https://github.com/makeplane/plane/releases/tag/v1.2.0)). Works for both `makeplane/plane-cloud` and `makeplane/plane-ee`.
+
+## Repo-specific versioning
+
+Plane uses **different version schemes** across its two release repos. Detect which repo the PR belongs to and use the matching scheme when communicating about the release — the version itself does **not** appear in the release notes body (GitHub's release tag carries it).
+
+| Repo                    | Version scheme | Example PR title       | Source branch | Target branch        |
+| ----------------------- | -------------- | ---------------------- | ------------- | -------------------- |
+| `makeplane/plane-cloud` | Date-based     | `release: v26.04.13-1` | `uat`         | `master`             |
+| `makeplane/plane-ee`    | Semver         | `release: v1.12.0`     | `uat`         | `master` / `preview` |
+
+- **plane-cloud** ships daily — version is `vYY.MM.DD-N` where `N` is the counter for that date's release.
+- **plane-ee** ships on a versioned cadence — version is `vX.Y.Z` (major.minor.patch) following semver.
+- Detect the repo with `gh pr view <PR_NUM> --json headRepository,baseRepository` or from the URL the user shared.
+
+## When to Use
+
+- User links/mentions a Plane release PR (e.g. `release: v26.04.13-1` for cloud or `release: v1.12.0` for EE) and asks for release notes
+- User asks to "create release notes" / "update PR description" for a PR in `makeplane/plane-cloud` or `makeplane/plane-ee`
+- The branch is named `uat` or `release/x.y.z` and the base is `master` or `preview`
+
+## Steps
+
+### 1. Fetch commits
+
+```bash
+gh pr view <PR_NUM> --json title,body,baseRefName,headRefName,commits \
+  --jq '.commits[] | .messageHeadline + "\n---BODY---\n" + .messageBody + "\n===END==="'
+```
+
+For a quick scan first:
+
+```bash
+gh pr view <PR_NUM> --json commits \
+  --jq '.commits[] | {oid: .oid[0:10], message: .messageHeadline}'
+```
+
+### 2. Filter out noise
+
+**Always exclude** these commits — mechanical, not user-facing:
+
+| Pattern                                      | Reason                                |
+| -------------------------------------------- | ------------------------------------- |
+| `Sync: Enterprise Changes #NNNN`             | Cross-repo sync, no functional change |
+| `fix: merge conflicts`                       | Merge artifact                        |
+| `Merge branch '...' of github.com:...`       | Merge artifact                        |
+| `Revert "..."` (when immediately re-applied) | Internal churn                        |
+
+### 3. Identify work item IDs (for research only)
+
+Most meaningful commits begin with a Plane work item identifier in brackets:
+
+- `[WEB-XXXX]` — web/frontend product items
+- `[SILO-XXXX]` — Silo (integrations: Slack, GitHub, GitLab, Jira/Linear)
+- `[MOBILE-XXXX]`, `[API-XXXX]`, etc.
+
+**Do not include these IDs in the release notes.** The GitHub Releases format is end-user-facing — IDs are only useful as a lookup key for fetching context in step 4.
+
+### 4. (Optional) Enrich via Plane MCP
+
+For larger features where the commit headline is terse, fetch the work item to write a richer paragraph:
+
+```
+mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB", issue_identifier=6874)
+```
+
+Use the returned `name` and `description_stripped` to flesh out the prose. Skip for routine fixes — commit body is usually enough. Don't enrich every item (slow + descriptions are often empty).
+
+### 5. Categorize commits
+
+Map each surviving commit into one of four sections:
+
+| Commit signal                                                                                                         | Section         |
+| --------------------------------------------------------------------------------------------------------------------- | --------------- |
+| `feat:` that introduces a brand-new screen, flow, or capability                                                       | ✨ Features     |
+| `feat:` that improves an existing feature, plus most `refactor:` and behavioural `chore:` items that are user-visible | ⬆️ Enhancements |
+| `fix:`, `fix(scope):`                                                                                                 | 🐞 Bug fixes    |
+| CVE upgrades, dependency bumps that close a vulnerability, security hardening                                         | 🛡️ Security     |
+
+**Drop entirely** (do not surface to users): pure infra `chore:`, dependabot bumps with no CVE, internal refactors with no behavioural impact, test-only changes, doc-only changes.
+
+### 6. Format
+
+Output follows the GitHub Releases convention — `###` for section headers, with two spaces between the emoji and the label for ✨ / ⬆️ / 🐞 (matches `v1.2.0`).
+
+```markdown
+### ✨ Features
+
+#### **Short Feature Name in Title Case**
+
+A 1–3 sentence paragraph describing what the user gets, why it matters, and any notable behaviour. Write in product-marketing voice, not commit-message voice.
+
+- Optional nested bullets for sub-capabilities or callouts
+- Keep them user-facing — what the user can now do
+
+#### **Second Major Feature**
+
+Another descriptive paragraph. Each major feature gets its own `####` subsection.
+
+### ⬆️ Enhancements
+
+- One-line description of an improvement to an existing capability
+- Another improvement, written as a clean sentence (no commit prefix, no ticket ID)
+
+### 🐞 Bug fixes
+
+- Plain-English description of what was broken and is now fixed
+- Another bug fix
+
+### 🛡️ Security
+
+- Upgraded <component> to <version> to mitigate [CVE-XXXX-NNNNN](https://link-to-advisory). Brief impact note.
+- Other security-relevant change
+```
+
+Rules:
+
+- Section headers use `###` (three hashes), then emoji + **two spaces** + label — exactly as in the published v1.2.0 release. Exception: 🛡️ Security uses a single space (matches v1.2.0).
+- Features use `####` (four hashes) and the feature name is **bolded** inside the heading: `#### **Feature Name**`.
+- Each feature gets a real paragraph, not a bullet — written for end users, not engineers.
+- Enhancements, Bug fixes, and Security are simple bullets. No nested asterisks, no ticket IDs, no PR numbers.
+- **Do not include work item IDs (`[WEB-XXXX]`) or PR numbers (`(#NNNN)`)** in any section — this format is user-facing.
+- **Do not add a `# Release vX.Y.Z` heading.** The GitHub release tag carries the version; the body starts directly with the first `### ✨  Features` section.
+- **Do not insert images.** The user adds screenshots manually after the notes are drafted. Leave space for them only if the user asks.
+- Drop empty sections entirely.
+- Blank line between section header and first bullet/feature, and between sections.
+
+### 7. Update the PR description
+
+```bash
+gh pr edit <PR_NUM> --body "$(cat <<'EOF'
+<release notes markdown>
+EOF
+)"
+```
+
+Always use a HEREDOC with single-quoted `'EOF'` so backticks/dollars in the notes are preserved.
+
+## Quick Reference: end-to-end
+
+```bash
+PR=2498
+gh pr view $PR --json commits --jq '.commits[] | .messageHeadline + "\n---\n" + .messageBody + "\n==="' > /tmp/commits.txt
+# read /tmp/commits.txt, filter, categorize into the four sections, draft notes
+gh pr edit $PR --body "$(cat <<'EOF'
+### ✨  Features
+
+#### **...**
+
+...
+
+### ⬆️  Enhancements
+
+- ...
+
+### 🐞  Bug fixes
+
+- ...
+
+### 🛡️ Security
+
+- ...
+EOF
+)"
+```
+
+## Reference example
+
+The canonical target format is [v1.2.0](https://github.com/makeplane/plane/releases/tag/v1.2.0) on `makeplane/plane`. When in doubt about heading levels, spacing, bolding, or paragraph voice, match that page exactly (minus images).
+
+## Common Mistakes
+
+- **Including work item IDs in bullets** — the GitHub Releases format is user-facing; `[WEB-XXXX]` belongs in internal research, not the output.
+- **Adding a `# Release vX.Y.Z` heading** — GitHub's release tag is the version. The body starts with `### ✨  Features`.
+- **Copy-pasting commit subjects verbatim** — rewrite into product-marketing English. "fix: peek overview reload on parent add" → "Fixed peek overview reloading on adding a parent".
+- **Bulleting features instead of writing paragraphs** — major features get `#### **Name**` plus a real paragraph; only enhancements/bugs/security use bullets.
+- **Including `Sync: Enterprise Changes` commits** — these are sync PRs, never user-visible.
+- **Including `fix: merge conflicts`** — merge artifact, no functional content.
+- **Inserting images** — leave images for the user; they add screenshots manually.
+- **Using `--body` without HEREDOC** — backticks/dollar signs get shell-interpreted and corrupt the notes.
+- **Editing the PR title** — release PR titles are version markers; only edit the body.
+- **Adding a Chores section** — the GitHub Releases format has no Chores section; user-invisible chores are dropped entirely.
+
+## Plane-Specific Conventions
+
+- Release PRs go from `uat` → `master` (or `preview`).
+- PR title format:
+  - `plane-cloud`: `release: vYY.MM.DD-N` where N is the daily release counter for that date.
+  - `plane-ee`: `release: vX.Y.Z` semver (major.minor.patch).
+- Commits coming from feature branches always carry a work item ID; commits without one are usually infra/chores and almost always dropped from notes.
+- `Sync: Enterprise Changes #NNNN` are automated cross-repo syncs and are _always_ skipped.
+- CVE-related upgrades (NextJS, React, Django, nginx, etc.) belong under 🛡️ Security with a link to the advisory and a one-line impact note.