chore: add Claude Code project skills

.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 `main` 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/feature-docs-layout/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: feature-docs-layout
+description: Use when saving or creating any design, spec, brainstorming, or implementation-plan markdown doc in this repo — including docs produced by the superpowers brainstorming/writing-plans skills, or any time you are about to choose a path under docs/ (especially docs/superpowers/) or decide where feature documentation lives.
+user_invocable: true
+---
+
+# Feature Docs Layout
+
+## Overview
+
+Every planning, design, and implementation document for a feature is the **system of record** for how that feature was built. Keep them together in ONE per-feature directory:
+
+```
+docs/<feature-slug>/<doc>.md
+```
+
+**Never** write to `docs/superpowers/` and **never** date-prefix filenames.
+
+## The Rule
+
+- `<feature-slug>` — kebab-case, descriptive, stable (e.g. `bulk-work-item-archive`). No dates, no `superpowers`.
+- All docs for one feature live in the same folder, side by side.
+
+## Quick Reference
+
+| Doc                                        | Path                                        |
+| ------------------------------------------ | ------------------------------------------- |
+| Design / spec (from brainstorming)         | `docs/<feature-slug>/design.md`             |
+| Implementation plan (from writing-plans)   | `docs/<feature-slug>/plan.md`               |
+| Anything else (research, decisions, notes) | `docs/<feature-slug>/<descriptive-name>.md` |
+
+## Picking the slug
+
+1. If `docs/<feature-slug>/` already exists for this feature, **reuse it** — add your doc there, don't make a new folder.
+2. Otherwise derive a kebab-case slug from the feature name; match the branch slug if one exists (see `branch-name`).
+
+## Overriding superpowers (important)
+
+The superpowers `brainstorming` and `writing-plans` skills default to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and `docs/superpowers/plans/YYYY-MM-DD-<feature>.md`. **Both skills explicitly state that user preferences for the doc location override this default. This skill is that preference.** So when following them:
+
+- design / spec → `docs/<feature-slug>/design.md`
+- plan → `docs/<feature-slug>/plan.md`
+
+Do not create `docs/superpowers/`. If you find docs already there, move them into `docs/<feature-slug>/` (precedent: PR #7684).
+
+## Common Mistakes
+
+| Mistake                                                    | Fix                       |
+| ---------------------------------------------------------- | ------------------------- |
+| `docs/superpowers/specs/2026-06-12-foo-design.md`          | `docs/foo/design.md`      |
+| `docs/superpowers/plans/2026-06-12-foo.md`                 | `docs/foo/plan.md`        |
+| `docs/2026-06-12-foo-design.md` (date prefix at top level) | `docs/foo/design.md`      |
+| Design and plan in different top-level folders             | Both under `docs/foo/`    |
+| New folder when `docs/foo/` already exists                 | Reuse the existing folder |
+
+## Examples (existing in this repo)
+
+`docs/permissions/`, `docs/data-layer/`, `docs/work-item-types/`, `docs/pi-prediction-entity-abstraction/design.md`, `docs/rich-text-external-endpoints/plan.md`.

.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                 |