skills/linear-worktree/SKILL.md
Creates a git worktree from main for a Linear issue. Use when the user pastes a Linear URL (https://linear.app/.../issue/ABC-58/...), a Linear "copy as prompt" string, or just an issue ID like "ABC-58". Handles URL parsing, branch name derivation, and worktree creation as a sibling directory. Also use when asked to "make a worktree for ABC-58", "set up a branch for this issue", or "create a worktree".
npx skillsauth add mblode/agent-skills linear-worktreeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Creates a git worktree from main for a Linear issue as a sibling directory of the current repo.
Copy and track this checklist:
Worktree creation progress:
- [ ] Step 1: Resolve REPO_ROOT / REPO_NAME / REPOS_BASE
- [ ] Step 2: Parse input into ISSUE_ID and BRANCH
- [ ] Step 3: git fetch origin main
- [ ] Step 4: git worktree add at $REPOS_BASE/$REPO_NAME-$ISSUE_ID
- [ ] Step 5: Report worktree path, branch, and cd command with resolved paths
Resolve three variables:
REPO_ROOT = git rev-parse --show-toplevel, REPO_NAME = its basename, REPOS_BASE = its parent directory.config.json has repos_base: use that as REPOS_BASE. Ask the user which repo folder.The user provides one of:
https://linear.app/myteam/issue/ABC-58/add-dark-mode-toggleABC-58 Add dark mode toggle to settings pageABC-58All parsing produces two values: ISSUE_ID (lowercased) and BRANCH (id + slug).
/issue/ → ISSUE_ID = abc-58BRANCH = abc-58-add-dark-mode-toggleISSUE_ID = abc-58-, strip backticks/parentheses/.../quotes/#/@, collapse consecutive hyphens, trim leading/trailing hyphensBRANCH = abc-58-<slug>Example: ABC-58 Add dark mode toggle (don't break "light" default)
→ abc-58-add-dark-mode-toggle-dont-break-light-default
Lowercase the ID → ISSUE_ID = abc-58. Slugify any description the user provides for the branch, otherwise BRANCH = abc-58.
git -C $REPO_ROOT fetch origin main
git -C $REPO_ROOT worktree add \
-b $BRANCH \
$REPOS_BASE/$REPO_NAME-$ISSUE_ID \
main
This creates a worktree at $REPOS_BASE/$REPO_NAME-$ISSUE_ID (e.g. /Users/you/Code/myrepo-abc-58) — a sibling of the main repo, not inside it.
Tell the user the worktree path, branch name, and cd command using actual resolved paths:
Worktree: /Users/you/Code/myrepo-abc-58
Branch: abc-58-add-dark-mode-toggle
Run: cd /Users/you/Code/myrepo-abc-58
-b — use git worktree add $REPOS_BASE/$REPO_NAME-$ISSUE_ID $BRANCH.--force. Run git worktree list and tell the user to cd to the existing worktree.git fetch origin main before git worktree add, or the worktree gets a stale base.$REPO_ROOT, never inside it.git worktree add, not git checkout -b.cd: the worktree is useless if the user stays in the original repo.development
Designs and builds UI end to end, from visual direction (palettes, type scales, design tokens, layout systems, landing-page CRO strategy, brand kits) to Tailwind implementation with the ui.sh design guideline system, including multiple variants with an in-browser picker, semantic markup scaffolds from screenshots, retrofitting dark mode or responsive behavior, and componentizing or canonicalizing Tailwind code. Use when asked to "build a landing page", "create a dashboard", "make this look good", "make this look premium", "pick a visual style", "design the UI for", "show me 3 hero options", "improve conversions", "create a brand kit", "turn this screenshot into markup", "add dark mode", "make a dark version of this image", "make this responsive", "fix this on mobile", "componentize this page", "clean up the Tailwind", or any prompt that designs, creates, or refines UI code. For auditing existing UI use ui-audit; for motion use ui-animation; for landing page copy use copywriting.
development
Collaborative interrogation that produces an implementation plan before any code is written. Explores the codebase and relevant docs first, asks one question at a time with a concrete recommended answer, grills the rationale behind documented decisions, flags fuzzy terminology, and walks a decision tree until shared understanding is reached, then writes a plan file. First step of the shipping pipeline; it creates plans, plan-reviewer stress-tests them, pr-creator opens the PR. Use when asked to "create a plan", "help me think through this", "plan this feature", "I want to build X", "grill me", "grill with docs", "understand the docs", "unpack the decisions", "brainstorm a spec", "what should the plan be", "think this through with me", or before starting any non-trivial implementation.
development
--- name: pr-reviewer description: Reviews the current local diff or branch and returns a read-only, severity-tiered findings report. It never edits files. Four modes: standard bug and compliance review, structural quality, AI slop detection, and whole-codebase security audit. Use when asked to run /pr-reviewer, "review my changes", or "code review" before commit, push, or handoff. "Thermo-nuclear review", "structural review", "deep code quality audit", "harsh maintainability review", and "code
development
--- name: ux-audit description: Feature-level UX audit for React/Next.js code, diff-aware by default. Catches what Lighthouse, axe, ESLint, and Storybook miss: state-coverage gaps (missing loading/empty/error), form data loss on validation, double-submit, broken focus management, optimistic UI without rollback, stale async responses, skeleton-induced layout shift, and vague microcopy. 33 modern failure-mode rules plus 30 Laws of UX rules across 12 feature playbooks. Produces a 3-tier ship-readin