chore: restructure .claude/skills into per-skill directories

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