♻️ Update git worktree config to use sibling directories

Change worktree location from .gitworktrees/ (inside repo) to sibling
directories (e.g., mcp-hubby-feature-name) to avoid pnpm symlink and
ESLint module resolution issues.

Why sibling directories:
- Avoids pnpm symlink resolution errors with nested worktrees
- Prevents ESLint @rushstack/eslint-patch module patching errors
- Cleaner separation between main repo and feature work
- Standard practice for monorepo tools and shared deps

Lesson learned from memory integration PR where pre-commit hooks
failed due to ESLint config issues in nested .gitworktrees/ location.

Author: Nick Sullivan

git-worktree-task.mdc

@@ -0,0 +1,111 @@
+---
+description: Autonomous task workflow using git worktrees
+alwaysApply: false
+---
+
+# Git Worktree Task Workflow
+
+<objective>
+Deliver a pull request that passes all checks and merges without back-and-forth. Work in isolated git worktrees to keep the main directory clean and allow context switching.
+</objective>
+
+<workspace-setup>
+Create git worktree as a sibling directory to avoid pnpm/ESLint module resolution issues:
+
+```bash
+# Extract project name from current directory
+PROJECT_NAME=$(basename "$(git rev-parse --show-toplevel)")
+
+# Create worktree as sibling directory
+git worktree add -b feature/task-name "../${PROJECT_NAME}-task-name" main
+cd "../${PROJECT_NAME}-task-name"
+```
+
+Example: If working in `/Users/nick/src/mcp-hubby`, worktree will be created at `/Users/nick/src/mcp-hubby-task-name` (sibling directory).
+
+**Why sibling directories?**
+- Avoids pnpm symlink resolution issues with nested worktrees
+- Prevents ESLint module patching errors (@rushstack/eslint-patch)
+- Cleaner separation between main repo and feature work
+- Standard practice for monorepo tools and shared dependency trees
+
+**Note:** Do NOT use `.gitworktrees/` inside the repo - this breaks module resolution for pnpm-based projects.
+</workspace-setup>
+
+<environment-initialization>
+Run /setup-environment to prepare the worktree. This detects project type and sets up dependencies, code generation, and environment files.
+
+If /setup-environment doesn't exist, set up manually based on project type (Node.js: `pnpm install`, Python: `pip install -r requirements.txt`, Ruby: `bundle install`).
+
+Copy environment files from parent directory if needed. After proper setup, all tests (unit + integration) should pass.
+</environment-initialization>
+
+<standards-discovery>
+Read all cursor rules in .cursor/rules/. If CLAUDE.md or AGENTS.md exist at project root, read those too. Every applicable rule must be followed.
+</standards-discovery>
+
+<implementation>
+Write code that solves the problem following all cursor rules. Make commits along the way as logical units of work are completed. Follow git commit message guidelines in .cursor/rules/git-commit-message.mdc.
+</implementation>
+
+<local-validation>
+Run project's pre-push validation before pushing. This catches issues before CI:
+- Node.js: `pnpm pre-push` or check package.json scripts
+- Python: `pre-commit run --all-files`, `pytest`, `ruff check`, `mypy`
+- Ruby: `bundle exec rake test`, `bundle exec rubocop`
+- Go: `go test ./...`, `golangci-lint run`
+- Rust: `cargo test`, `cargo clippy`
+
+Check .github/workflows/ to see what CI runs - run those steps locally.
+
+All tests should pass after environment setup. If tests fail, it's either incomplete setup or bugs in your code. Fix before pushing.
+</local-validation>
+
+<self-review>
+Invoke code reviewer agent (Rivera in .claude/agents/rivera.md if available) to review changes before pushing. Address critical issues, consider warnings seriously, evaluate suggestions for merit. Learn from feedback.
+</self-review>
+
+<pull-request-creation>
+Once local validation passes and code review is addressed, push commits. Create pull request with clear description of what changed and why. Help reviewers understand context and decisions made.
+</pull-request-creation>
+
+<ci-validation>
+Let all CI jobs run to completion. All must pass. Green checks required before merge. If CI fails, read logs carefully, understand what broke and why, fix and push again.
+</ci-validation>
+
+<bot-review-handling>
+AI code review bots will analyze the pull request. Evaluate feedback critically - you have full project context, bots don't.
+
+Fix valuable feedback that identifies real issues. Mark as WONTFIX with clear reasoning if feedback is incorrect, not applicable, conflicts with project standards, or would break functionality.
+
+Be discerning. You are smarter than the bots.
+</bot-review-handling>
+
+<merge-and-cleanup>
+Once CI is green, bot reviews are addressed, and all checks pass, merge the PR.
+
+After merge, clean up worktree:
+
+```bash
+# Return to main repo directory
+cd "$(git rev-parse --show-toplevel)"
+
+# Remove the sibling worktree
+PROJECT_NAME=$(basename "$(git rev-parse --show-toplevel)")
+git worktree remove "../${PROJECT_NAME}-task-name"
+```
+
+Or use the /clean-up-worktree command if available.
+</merge-and-cleanup>
+
+<critical-success-factors>
+Environment setup is not optional. After creating worktree, run /setup-environment or manually install dependencies. Type errors and test failures often stem from missing code generation or dependencies.
+
+Local validation saves time. Don't push without running pre-push checks. Local tooling catches issues in seconds vs waiting for CI.
+
+Bot feedback requires judgment. Bots provide suggestions, not mandates. Evaluate each piece based on your context and project standards.
+
+Full test suite must pass. After setup, all tests (unit + integration) should pass. Fix setup or code before pushing.
+
+Successful autonomous task means: original request completed, all automated checks pass, code follows all cursor rules, tests green, code review addressed, bot feedback evaluated intelligently, PR merges without human intervention requesting changes.
+</critical-success-factors>