@pharaoh-so/mcp 0.3.14 → 0.3.15

package/skills/finish/SKILL.md

@@ -1,80 +0,0 @@
----
-name: finish
-prompt-name: finish-branch
-description: "Complete a development branch after implementation. Verify all tests pass, present structured options (merge locally, create PR, keep branch, or discard), execute the chosen workflow, and clean up worktrees. Never merge broken code or delete work without confirmation."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["git", "merge", "pull-request", "cleanup", "branch-management"]}
----
-
-# Finish Branch
-
-Guide completion of development work after implementation is done. Verify tests, present options, execute choice, clean up.
-
-## When to Use
-
-When implementation is complete and you need to decide how to integrate the work — merge, PR, keep, or discard.
-
-## Process
-
-### Step 1: Verify Tests
-
-Run the full test suite before presenting options.
-
-**If tests fail:** stop. Report failures. Do not proceed until tests pass.
-
-**If tests pass:** continue.
-
-### Step 2: Determine Base Branch
-
-Check what branch this work split from (typically `main` or `master`).
-
-### Step 3: Present Options
-
-Present exactly these 4 options:
-
-```
-Implementation complete. What would you like to do?
-
-1. Merge back to <base-branch> locally
-2. Push and create a Pull Request
-3. Keep the branch as-is (I'll handle it later)
-4. Discard this work
-
-Which option?
-```
-
-### Step 4: Execute Choice
-
-**Option 1 — Merge locally:**
-- Switch to base branch, pull latest, merge feature branch
-- Verify tests on merged result
-- Delete feature branch
-
-**Option 2 — Create PR:**
-- Push branch to remote
-- Create PR with summary and test plan
-- Keep worktree (may need it for review feedback)
-
-**Option 3 — Keep as-is:**
-- Report branch name and worktree path
-- Don't clean up anything
-
-**Option 4 — Discard:**
-- List what will be deleted (branch, commits, worktree)
-- Require typed "discard" confirmation before proceeding
-- Delete branch and clean up worktree
-
-### Step 5: Clean Up Worktree
-
-For Options 1 and 4: remove the worktree after completing the action.
-For Options 2 and 3: keep the worktree.
-
-## Iron Rules
-
-- Never proceed with failing tests
-- Never merge without verifying tests on the merged result
-- Never delete work without explicit confirmation
-- Never force-push without explicit request
-- Always present exactly 4 structured options — no open-ended questions

package/skills/health/SKILL.md

@@ -1,37 +0,0 @@
----
-name: health
-prompt-name: health-check
-description: "Full codebase health sweep using Pharaoh knowledge graph. Six-step pro-tier workflow: module map with metrics, dead code detection, test coverage gaps, duplicate logic, regression risk scoring, and spec drift analysis. Produces an A-F grade, top 5 risks, tech debt hotspots (high-complexity + low-coverage + high-volatility intersections), spec drift summary, and prioritized actions with effort estimates."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["health-check", "tech-debt", "architecture", "pharaoh", "test-coverage", "regression-risk", "spec-drift"]}
----
-
-# Health Check
-
-Full codebase health sweep. Uses `health-check` — a 6-step pro-tier workflow that grades the codebase A-F, surfaces the top risks, maps tech debt hotspots, checks spec alignment, and produces prioritized actions. Requires Pro tools.
-
-## When to Use
-
-Invoke when asked for a codebase health assessment, a technical debt overview, or a risk report. Use it at the start of a maintenance sprint, before a major refactor, or when the codebase has grown without systematic review.
-
-## Workflow
-
-1. Call `get_codebase_map` for the target repository with `include_metrics` to see all modules, their sizes, complexity, and volatility.
-2. Call `get_unused_code` for the target repository to find dead exports and orphaned functions.
-3. Call `get_test_coverage` for the target repository to identify modules and functions lacking tests.
-4. Call `get_consolidation_opportunities` for the target repository to find duplicated logic across modules.
-5. Call `get_regression_risk` for the target repository to assess which modules are most likely to break.
-6. Call `get_vision_gaps` for the target repository to check spec-vs-code drift.
-
-Iron law: Report what the data shows, not what you think should be true.
-
-## Output
-
-A health report containing:
-- **Overall grade (A-F):** based on dead code volume, test coverage, duplication, regression risk, and spec alignment
-- **Top 5 risks:** specific modules or functions, with data backing each risk
-- **Tech debt hotspots:** high-complexity + low-coverage + high-volatility intersections
-- **Spec drift:** what is specified but not built; what is built but not specified
-- **Prioritized actions:** ordered by impact, each with effort estimate (small / medium / large)

package/skills/investigate/SKILL.md

@@ -1,35 +0,0 @@
----
-name: investigate
-prompt-name: investigate-change
-description: "Full architectural context gathering before modifying a function, file, or module using Pharaoh knowledge graph. Four-step free-tier workflow: module structure, blast radius of downstream callers, related function discovery, and dependency mapping. Blocks code suggestions until all context is gathered. Produces an investigation report with structure, blast radius, related functions, dependency context, and risk assessment."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["investigation", "context-gathering", "blast-radius", "pharaoh", "architecture", "change-impact"]}
----
-
-# Investigate Change
-
-Gather full architectural context before modifying anything. Uses `investigate-change` — a 4-step free-tier workflow that maps the target's structure, blast radius, related functions, and dependency context before any code suggestions are made.
-
-## When to Use
-
-Invoke before modifying any function, file, or module — especially when the codebase is unfamiliar or when the change touches shared code. Use it to answer "what do I need to know before touching this?" without reading files one at a time.
-
-## Workflow
-
-1. Call `get_module_context` for the module containing the target to understand its structure and complexity.
-2. Call `get_blast_radius` for the target to see every downstream caller and affected module.
-3. Call `search_functions` for the target name to find related functions and potential naming conflicts.
-4. Call `query_dependencies` to map how the containing module connects to the rest of the codebase.
-
-Do NOT suggest any changes until all 4 queries complete.
-
-## Output
-
-An investigation report containing:
-- **Current structure:** what the target does and where it lives
-- **Blast radius:** every caller and module that would be affected by changes
-- **Related functions:** similar names or overlapping behavior, potential naming conflicts
-- **Dependency context:** how the module connects upstream and downstream
-- **Risk assessment:** safe to change vs. high-risk paths, with specific reasons

package/skills/onboard/SKILL.md

@@ -1,33 +0,0 @@
----
-name: onboard
-prompt-name: onboard-to-codebase
-description: "Quick codebase orientation using Pharaoh knowledge graph. Five-step workflow using only free-tier tools: full module map, deep-dive into the three largest modules, entry point discovery, critical path blast radius, and core data flow mapping. Produces an onboarding summary with module descriptions, entry points, data flow, and key functions to read first."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["onboarding", "codebase-orientation", "architecture", "pharaoh", "module-map", "entry-points"]}
----
-
-# Onboard to Codebase
-
-Quick orientation to an unfamiliar codebase. Uses `onboard-to-codebase` — a 5-step workflow using only free-tier Pharaoh tools to understand modules, entry points, data flow, and key functions without reading files one at a time.
-
-## When to Use
-
-Invoke at the start of any session with an unfamiliar repository, or when asked to understand how a codebase is structured before making changes. Use it instead of exploring files manually.
-
-## Workflow
-
-1. Call `get_codebase_map` for the target repository to see all modules and their relationships.
-2. For the 3 largest modules (by function count), call `get_module_context` to understand their internals.
-3. Call `search_functions` with broad terms like "main", "init", "start", "handler" to find entry points.
-4. Call `get_blast_radius` for the most-connected module to understand the critical path.
-5. Call `query_dependencies` between the two most-connected modules to understand the core data flow.
-
-## Output
-
-An onboarding summary containing:
-- **Module map:** what each module does, 1 sentence each
-- **Entry points:** where execution starts, with function names and file paths
-- **Core data flow:** how the main modules connect, with dependency directions
-- **Key functions to read first:** highest connectivity or most-depended-on functions, with brief descriptions

package/skills/orchestrate/SKILL.md

@@ -1,145 +0,0 @@
----
-name: orchestrate
-prompt-name: orchestrate-plan
-description: "Execute implementation plans by dispatching one subagent per task with two-stage review (spec compliance then code quality). Sequential task execution with quality gates. Controller stays in session, constructs focused context for each agent, never shares session history. Handles DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED status protocol."
-version: 0.2.5
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["subagents", "orchestration", "plan-execution", "quality-gates", "spec-review", "code-review"]}
----
-
-# Orchestrate Plan Execution
-
-Execute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance first, then code quality. The controller (you) coordinates — subagents implement and review.
-
-## When to Use
-
-- You have a written implementation plan with 2+ tasks
-- Tasks are mostly independent (different files/modules)
-- You want quality gates between tasks (not just fire-and-forget)
-- You're staying in this session (not dispatching to parallel worktrees)
-
-## When NOT to Use
-
-- Tasks are tightly coupled (use manual execution)
-- You want parallel execution across sessions (use `pharaoh:execute` instead)
-- You don't have a plan yet (use `pharaoh:plan` first)
-- You just need parallel dispatch without review gates (use `pharaoh:parallel`)
-
-## Workflow
-
-### Phase 0 — Setup
-
-1. Read the plan file once. Extract all tasks with full text.
-2. Note cross-task context: shared types, import paths, architectural constraints.
-3. Create a task list tracking each task's status.
-
-### Phase 1 — Per-Task Loop
-
-For each task:
-
-#### 1a. Dispatch Implementer
-
-Launch a subagent with:
-- **Full task text** (paste it, don't make the agent read the file)
-- **Scene-setting context** (where this fits, what's already built, dependencies)
-- **Constraints** (what NOT to change, scope boundaries)
-- **Working directory**
-
-The implementer should:
-1. Ask questions before starting (don't guess)
-2. Implement exactly what the task specifies
-3. Write tests
-4. Commit
-5. Self-review
-6. Report with status: **DONE** / **DONE_WITH_CONCERNS** / **NEEDS_CONTEXT** / **BLOCKED**
-
-#### 1b. Handle Status
-
-- **DONE** → proceed to spec review
-- **DONE_WITH_CONCERNS** → read concerns. If correctness/scope issues, address before review. If observations, note and proceed.
-- **NEEDS_CONTEXT** → provide missing information, re-dispatch
-- **BLOCKED** → assess: provide more context, use a more capable model, break task smaller, or escalate to user
-
-Never ignore an escalation. Never force retry without changes.
-
-#### 1c. Spec Compliance Review
-
-Dispatch a reviewer subagent with:
-- Full task requirements (original spec text)
-- Implementer's report of what they built
-
-The spec reviewer must:
-- Read actual code, not trust the report
-- Check: missing requirements, extra/unneeded work, misinterpretations
-- Verdict: **pass** or **issues found** (with file:line references)
-
-If issues found → implementer fixes → spec reviewer re-reviews → repeat until pass.
-
-#### 1d. Code Quality Review
-
-Only after spec compliance passes. Dispatch a quality reviewer with:
-- What was implemented
-- Git SHAs (base and head)
-- Task requirements
-
-The quality reviewer checks:
-- Single responsibility per file
-- Clean interfaces and decomposition
-- Test quality (assertions that verify behavior, not just coverage)
-- Following existing codebase patterns
-
-If issues found → implementer fixes → quality reviewer re-reviews → repeat until pass.
-
-#### 1e. Mark Complete
-
-Mark the task done. Move to next task.
-
-### Phase 2 — Final Review
-
-After all tasks complete, dispatch one final code reviewer across the entire implementation. Check for:
-- Cross-task integration issues
-- Consistency between tasks
-- Overall architecture coherence
-
-### Phase 3 — Finish
-
-Use `pharaoh:finish` to decide: merge, PR, or cleanup.
-
-## Model Selection
-
-Match model capability to task complexity:
-
-| Task type | Model tier |
-|-----------|-----------|
-| Isolated function, clear spec, 1-2 files | Fast/cheap |
-| Multi-file integration, pattern matching | Standard |
-| Architecture, design, review | Most capable |
-
-## Prompt Quality
-
-| Bad | Good |
-|-----|------|
-| "Implement the auth feature" | Full task text + context + constraints |
-| Sharing session history | Constructing focused context per agent |
-| "Fix it" | Specific report of what's wrong + file references |
-| Skipping spec review | Always spec review before quality review |
-
-## Iron Rules
-
-- **One task at a time** — no parallel implementation (conflicts)
-- **Never skip reviews** — spec compliance AND code quality, in that order
-- **Spec before quality** — wrong order wastes review cycles
-- **Construct context, don't inherit** — each agent gets exactly what it needs
-- **Never trust reports** — reviewers read code, not claims
-- **Fix before proceeding** — no moving to next task with open issues
-- **Escalation is success** — BLOCKED/NEEDS_CONTEXT means the system is working
-
-## Output
-
-After all tasks complete:
-- Summary of what was built (per task)
-- Review findings that were caught and fixed
-- Any concerns flagged by implementers
-- Final reviewer assessment
-- Ready for `pharaoh:finish`

package/skills/pr/SKILL.md

@@ -1,53 +0,0 @@
----
-name: pr
-prompt-name: pre-pr-review
-description: "Pre-pull-request architectural review checklist using Pharaoh codebase knowledge graph. Covers module context, blast radius per touched module, hidden coupling between modules, duplicate logic detection, regression risk scoring, and vision spec alignment. Produces a structured review summary before opening a PR."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["pull-request", "code-review", "architecture", "pharaoh", "pre-pr", "regression-risk"]}
----
-
-# Pre-PR Review
-
-Architectural review checklist to run before opening a pull request. Uses `pre-pr-review` — a 6-step workflow covering module context, blast radius, dependency coupling, duplicate logic, regression risk, and spec drift. Catches architectural problems before reviewers see the code.
-
-## When to Use
-
-Invoke before opening a pull request. Use it when changes touch one or more modules and you want a structured architectural assessment before requesting human review.
-
-## Workflow
-
-### Step 1: Module context
-
-For each touched module, call `get_module_context` to review its current structure and complexity.
-
-### Step 2: Blast radius
-
-For each touched module, call `get_blast_radius` to identify what else is affected by the changes.
-
-### Step 3: Dependency check
-
-Call `query_dependencies` between each pair of touched modules to find hidden coupling introduced by the PR.
-
-### Step 4: Consolidation check
-
-Call `get_consolidation_opportunities` for the target repository to flag any duplicate logic introduced by the PR.
-
-### Step 5: Regression risk
-
-Call `get_regression_risk` for the target repository to assess overall change risk.
-
-### Step 6: Vision alignment
-
-Call `get_vision_gaps` for the target repository to check if changes align with or drift from specs.
-
-## Output
-
-A review summary containing:
-- **Architecture impact:** modules affected, dependency changes introduced
-- **Risk assessment:** blast radius per module, overall regression risk level
-- **Cleanup opportunities:** consolidation candidates, unused code created
-- **Spec alignment:** vision gaps introduced or resolved by the PR
-
-Ready to paste into the PR description or share with reviewers.

package/skills/review-codex/SKILL.md

@@ -1,81 +0,0 @@
----
-name: review-codex
-prompt-name: cross-model-review
-description: "Cross-model security review. Dispatch code to a different AI model or subagent for independent second-opinion review. Evaluator applies AGREE, DISAGREE, or CONTEXT verdicts to each finding. Catches blind spots from single-model reasoning. Use for security-sensitive code, auth flows, data access, and architectural decisions."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["security-review", "cross-model", "second-opinion", "code-review", "verification"]}
----
-
-# Cross-Model Code Review
-
-Get a second opinion on critical code by dispatching it to an independent reviewer — a different agent, model, or subagent. One model's blind spots are another's obvious catches.
-
-## When to Use
-
-- Security-sensitive changes (auth, encryption, access control, token handling)
-- Data access patterns (tenant isolation, query construction, input validation)
-- Architectural decisions with long-term consequences
-- Code you're not fully confident about
-- Before shipping changes that affect user data or billing
-
-## Do Not Use When
-
-- Trivial changes (typos, formatting, dependency bumps)
-- Changes fully covered by existing tests with high mutation scores
-- Time-critical hotfixes where review delay is worse than risk
-
-## Process
-
-### 1. Prepare Review Package
-
-Assemble exactly what the reviewer needs:
-
-- **Changed files:** full diff or complete file contents
-- **Context:** what the code does, why it was changed, what it interacts with
-- **Constraints:** security requirements, isolation rules, performance bounds
-- **Specific concerns:** what you want the reviewer to focus on
-
-Do NOT send your session history — construct focused context.
-
-### 2. Dispatch to Reviewer
-
-Send the review package to an independent agent. The reviewer should have no knowledge of your reasoning process — they evaluate the code fresh.
-
-### 3. Reviewer Applies Verdicts
-
-For each finding, the reviewer assigns:
-
-| Verdict | Meaning |
-|---------|---------|
-| **AGREE** | Confirms the implementation is correct for the stated concern |
-| **DISAGREE** | Identifies a concrete issue with evidence |
-| **CONTEXT** | Cannot determine correctness — needs more information |
-
-Each DISAGREE must include: what's wrong, why it matters, and a suggested fix.
-
-### 4. Evaluate Findings
-
-When review returns:
-
-- **AGREE items:** no action needed
-- **DISAGREE items:** verify the finding against actual code. If confirmed, fix. If the reviewer misunderstood context, document why the current approach is correct.
-- **CONTEXT items:** provide the missing information and re-review that item
-
-## What to Include in Review
-
-| Category | Include | Skip |
-|----------|---------|------|
-| Auth/access control | Token validation, session management, permission checks | UI styling |
-| Data access | Query construction, tenant isolation, input sanitization | Logging format |
-| Cryptography | Key management, encryption/decryption, hashing | String formatting |
-| Error handling | What's exposed to users, what's logged, what's swallowed | Happy path only |
-
-## Key Principles
-
-- **Independent evaluation** — reviewer must not be primed with your conclusions
-- **Evidence-based verdicts** — no "looks fine" without specifics
-- **Verify disagreements** — reviewer may lack context; check before acting
-- **Don't skip uncomfortable findings** — the point is catching what you missed
-- **Repeat for high-stakes changes** — one review round may not be enough

package/skills/review-receive/SKILL.md

@@ -1,82 +0,0 @@
----
-name: review-receive
-prompt-name: receive-code-review
-description: "Receive code review feedback with technical rigor. No performative agreement — verify suggestions against codebase reality before implementing. Push back with evidence when feedback is wrong. Clarify all unclear items before implementing any. External feedback is suggestions to evaluate, not orders to follow."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["code-review", "feedback", "technical-rigor", "pushback", "collaboration"]}
----
-
-# Receiving Code Review
-
-Code review requires technical evaluation, not emotional performance.
-
-**Verify before implementing. Ask before assuming. Technical correctness over social comfort.**
-
-## When to Use
-
-When receiving code review feedback — from humans, external reviewers, or automated tools. Especially when feedback seems unclear or technically questionable.
-
-## The Response Pattern
-
-1. **READ:** complete feedback without reacting
-2. **UNDERSTAND:** restate the requirement in your own words (or ask)
-3. **VERIFY:** check against codebase reality
-4. **EVALUATE:** technically sound for THIS codebase?
-5. **RESPOND:** technical acknowledgment or reasoned pushback
-6. **IMPLEMENT:** one item at a time, test each
-
-## Forbidden Responses
-
-Never respond with:
-- "You're absolutely right!"
-- "Great point!" / "Excellent feedback!"
-- "Let me implement that now" (before verification)
-- Any gratitude expression
-
-Instead: restate the technical requirement, ask clarifying questions, push back with evidence if wrong, or just start fixing.
-
-## Handling Unclear Feedback
-
-If ANY item is unclear: **stop — do not implement anything yet.** Ask for clarification on unclear items before touching code. Items may be related; partial understanding produces wrong implementations.
-
-## Evaluating External Feedback
-
-Before implementing suggestions from external reviewers:
-
-1. Is this technically correct for THIS codebase?
-2. Does it break existing functionality?
-3. Is there a reason for the current implementation?
-4. Does the reviewer understand the full context?
-5. Does it conflict with prior architectural decisions?
-
-If a suggestion seems wrong, push back with technical reasoning — reference working tests, actual code, or codebase patterns.
-
-## When to Push Back
-
-- Suggestion breaks existing functionality
-- Reviewer lacks full context
-- Feature is unused (YAGNI)
-- Technically incorrect for this stack
-- Conflicts with established architectural decisions
-
-**How:** technical reasoning, specific questions, references to working code. Never defensive — just factual.
-
-## Implementation Order
-
-For multi-item feedback:
-
-1. Clarify anything unclear FIRST
-2. Implement in priority order: blocking issues, simple fixes, complex fixes
-3. Test each fix individually
-4. Verify no regressions
-
-## Acknowledging Correct Feedback
-
-When feedback IS correct:
-- "Fixed. [Brief description of what changed]"
-- "Good catch — [specific issue]. Fixed in [location]."
-- Or just fix it silently — the code shows you heard.
-
-Actions speak. No performative agreement needed.

package/skills/wiring/SKILL.md

@@ -1,35 +0,0 @@
----
-name: wiring
-prompt-name: validate-wiring
-description: "Wiring validation for a codebase module using Pharaoh knowledge graph. Four-step pro-tier workflow: entry point reachability, caller verification via blast radius, test coverage per function, and dead code detection. Categorizes functions as CONNECTED, UNREACHABLE, DEAD, or UNTESTED. Produces a PASS or FAIL verdict with specific issues listed. Iron law: zero callers on a non-entry-point export means the code is not wired."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["wiring", "reachability", "dead-code", "pharaoh", "test-coverage", "entry-points", "validation"]}
----
-
-# Validate Wiring
-
-Verify that code in a module is properly connected. Uses `validate-wiring` — a 4-step pro-tier workflow that checks reachability from entry points, verifies functions have callers, confirms test coverage, and detects dead code. Produces a PASS / FAIL verdict with categorized findings. Requires Pro tools.
-
-## When to Use
-
-Invoke after adding new exports or functions, before merging code that adds a new module, or when dead code is suspected. Use it to answer "is this code actually being used?" with data instead of guesswork.
-
-## Workflow
-
-1. Call `check_reachability` for the target module to verify all exports are reachable from production entry points.
-2. Call `get_blast_radius` for the target module to verify functions have callers.
-3. Call `get_test_coverage` for the target module to check which functions are tested.
-4. Call `get_unused_code` for the target module to detect any dead code.
-
-Iron law: Zero callers on a non-entry-point export = the code is not wired.
-
-## Output
-
-A wiring report containing:
-- **CONNECTED:** Functions reachable from entry points with test coverage
-- **UNREACHABLE:** Exports with no path from entry points
-- **DEAD:** Functions with zero callers (not entry points)
-- **UNTESTED:** Reachable functions lacking test coverage
-- **Verdict:** PASS (all exports wired and tested) or FAIL (with specific issues listed and recommended actions)

package/skills/worktree/SKILL.md

@@ -1,86 +0,0 @@
----
-name: worktree
-prompt-name: git-worktree
-description: "Set up isolated git worktrees for feature work. Smart directory selection with safety verification — checks for existing worktree directories, verifies gitignore, auto-detects project setup, and confirms clean test baseline before starting. Prevents accidentally committing worktree contents."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["git", "worktree", "isolation", "branching", "workspace"]}
----
-
-# Git Worktrees
-
-Create isolated workspaces sharing the same repository. Work on multiple branches simultaneously without switching.
-
-## When to Use
-
-Before starting feature work that needs isolation from the current workspace. Before executing implementation plans. Any time you need a clean branch without disturbing current work.
-
-## Directory Selection
-
-Follow this priority order:
-
-1. **Check existing directories:** look for `.worktrees/` or `worktrees/` in the project root. If both exist, `.worktrees/` wins.
-2. **Check project docs:** look for worktree directory preferences in CLAUDE.md or project config.
-3. **Ask the user:** if no directory exists and no preference is documented.
-
-## Safety Verification
-
-For project-local worktree directories:
-
-```bash
-git check-ignore -q .worktrees 2>/dev/null
-```
-
-If the directory is NOT gitignored: add it to `.gitignore` and commit before creating worktrees. This prevents accidentally committing worktree contents to the repository.
-
-Global directories (outside the project) don't need this check.
-
-## Creation Steps
-
-### 1. Create Worktree
-
-```bash
-git worktree add <path>/<branch-name> -b <branch-name>
-cd <path>/<branch-name>
-```
-
-### 2. Install Dependencies
-
-Auto-detect from project files:
-
-| File | Command |
-|------|---------|
-| `package.json` + `pnpm-lock.yaml` | `pnpm install` |
-| `package.json` | `npm install` |
-| `Cargo.toml` | `cargo build` |
-| `requirements.txt` | `pip install -r requirements.txt` |
-| `go.mod` | `go mod download` |
-
-### 3. Verify Clean Baseline
-
-Run the project's test suite. If tests fail, report failures and ask whether to proceed or investigate. Don't start work on a broken baseline.
-
-### 4. Report
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Skipping gitignore verification | Always check before creating project-local worktrees |
-| Assuming directory location | Follow priority: existing > docs > ask |
-| Proceeding with failing baseline tests | Report failures, get permission first |
-| Hardcoding setup commands | Auto-detect from project files |
-
-## Red Flags
-
-- Never create a worktree without verifying it's gitignored (project-local)
-- Never skip baseline test verification
-- Never proceed with failing tests without asking
-- Never assume directory location when ambiguous