diff --git a/.claude/command-templates/close-issue.md b/.claude/command-templates/close-issue.md
index 5dfdbcfc..8b655083 100644
--- a/.claude/command-templates/close-issue.md
+++ b/.claude/command-templates/close-issue.md
@@ -19,7 +19,7 @@ When following the procedure:
 ## Final Step: Retro
 Let's retro this context and wring out the gleanings.
 
-{{ INJECT:principles/continuous-improvement.md }}
+{{ INJECT:principles/eager-evolution.md }}
 
 **Consider capturing any ghost procedures** that emerged during this work - see [Procedure Creation](knowledge/procedures/procedure-creation.md).
 
diff --git a/.claude/command-templates/create-issue.md b/.claude/command-templates/create-issue.md
new file mode 100644
index 00000000..572cf3e6
--- /dev/null
+++ b/.claude/command-templates/create-issue.md
@@ -0,0 +1,25 @@
+---
+name: create-issue
+description: Create GitHub issue with intelligent type detection and template selection
+---
+
+# Create GitHub Issue
+
+I'll help you create a GitHub issue with the appropriate template and context.
+
+{{ INJECT:procedures/github-issue-creation.md }}
+
+## Request Analysis
+
+Please provide:
+1. **What you want to create an issue for**
+2. **Any specific details or context**
+3. **Whether this is for dotfiles or another repository**
+
+I'll:
+- Auto-detect the issue type
+- Suggest the best template
+- Link relevant procedures
+- Include appropriate labels
+
+What would you like to create an issue for?
\ No newline at end of file
diff --git a/.claude/command-templates/retro.md b/.claude/command-templates/retro.md
index 377c71d2..13bf3472 100644
--- a/.claude/command-templates/retro.md
+++ b/.claude/command-templates/retro.md
@@ -1,10 +1,10 @@
 ---
 name: retro
-description: Mine gleanings through continuous improvement principle
+description: Mine gleanings through eager evolution of living systems
 ---
 
 Timeout - let's retro this context and wring out the gleanings.
 
-{{ INJECT:principles/continuous-improvement.md }}
+{{ INJECT:procedures/post-pr-mini-retro.md }}
 
-You drive - I'll support with observations when you ask.
\ No newline at end of file
+{{ INJECT:principles/eager-evolution.md }}
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/close-issue-guide.md b/.github/ISSUE_TEMPLATE/close-issue-guide.md
new file mode 100644
index 00000000..cfcfcdc0
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/close-issue-guide.md
@@ -0,0 +1,94 @@
+# Close Issue Detailed Guide
+
+Complete workflow for analyzing and implementing GitHub issues.
+
+## Step 1: Analyze the Issue
+
+Use `mcp__github__get_issue` to read the issue and determine:
+- Is this already resolved? → Quick close
+- Does this need implementation? → Full workflow
+- Is this invalid/duplicate? → Close with explanation
+- **Is this a spike?** → Spike workflow (no PR)
+- **Repository check**: If issue requires git operations in a different repo, STOP and ask human to restart session there. Claude Code cannot `cd` outside initial directory tree, breaking git workflows.
+- Check recent merged PRs for similar patterns → `mcp__github__list_pull_requests` (state: "closed")
+- Get issue comments with `mcp__github__get_issue_comments` to enrich understanding
+
+**Clarity opportunity**: If the issue contains vague language ("doesn't work", "should handle", "it depends"), consider exploring with EARS patterns to surface hidden assumptions and edge cases. This often reveals interesting test scenarios and sparks productive conversations about the real requirements. See [EARS Requirements](../../knowledge/procedures/ears-requirements.md) for conversation-driven discovery techniques.
+
+## Quick Close Path
+
+If the issue is already resolved, invalid, or duplicate:
+1. Add explanatory comment with `mcp__github__add_issue_comment`
+2. Close with `mcp__github__update_issue` (state: "closed")
+3. Done!
+
+## Spike Workflow Path
+
+If the issue is a spike:
+1. Research. Prototype. Document findings.
+2. Comment findings with `mcp__github__add_issue_comment`
+3. Discuss with human
+4. Close issue when done
+5. **NO PR** - spikes deliver knowledge, not code
+
+## Full Implementation Path
+
+If the issue needs implementation:
+
+### 1. Set Up Development
+Follow [Worktree Workflow](../../knowledge/procedures/worktree-workflow.md) to create isolated development environment.
+
+### 2. Implement Solution
+Apply tracer bullets methodology:
+
+**First, establish your target:**
+- Define clear success criteria for the issue resolution
+- Understand what failure looks like (how to detect when it's NOT fixed)
+- Create verification methods (tests, checks, validations) that can detect hits/misses
+
+**Then iterate with tracer rounds:**
+- Fire and miss: See verifications fail (confirms target detection works)
+- Adjust aim: Modify implementation while keeping target stable
+- Fire again: Run verifications to check progress
+- Use TodoWrite to track verified hits on target
+- Each commit is a confirmed hit - only commit code that moves toward the target
+
+**Natural behaviors that emerge:**
+- Test-first development (you need a target before you can aim)
+- Incremental progress through verified steps
+- Progressive refinement from rough to precise shots
+- Clear trajectory visible through commit history
+
+Follow [Git Workflow](../../knowledge/procedures/git-workflow.md) for commit standards.
+
+### 3. Create Pull Request
+- Push the feature branch to remote
+- Look for PR template:
+  - First check local repo: `.github/PULL_REQUEST_TEMPLATE.md`
+  - If not found, use dotfiles fallback: `~/ppv/pillars/dotfiles/.github/PULL_REQUEST_TEMPLATE.md`
+  - Inform which template is being used for transparency
+- Create PR with `mcp__github__create_pull_request` following the discovered template
+- Add "Conduct post-PR mini retro" to your todo list
+
+### 4. Iterate Based on Feedback
+Keep worktree active for PR adjustments based on the tracer bullets principle. Only cleanup after PR is merged.
+
+If MCP tools fail during implementation, follow [MCP Error Reporting](../../knowledge/procedures/mcp-error-reporting.md) to create self-healing feedback loop.
+
+## Decision Matrix
+
+- **Spike label** → Spike workflow (research only)
+- **Bug report with clear reproduction** → Implementation path
+- **Feature request approved by maintainer** → Implementation path  
+- **Question already answered** → Quick close with link
+- **Duplicate issue** → Quick close referencing original
+- **Invalid/out of scope** → Quick close with explanation
+- **Implemented in recent PR** → Quick close with PR reference
+
+Remember: Act agentically. Make the decision and execute.
+
+## See Also
+
+- [Issue to PR Workflow](../../knowledge/procedures/issue-to-pr-workflow.md) - High-level workflow overview
+- [Tracer Bullets](../../knowledge/principles/tracer-bullets.md) - Target-first development
+- [Post-PR Mini Retro](../../knowledge/procedures/post-pr-mini-retro.md) - Learning from implementation
\ No newline at end of file
diff --git a/docs/procedures/git-workflow-detailed.md b/docs/procedures/git-workflow-detailed.md
new file mode 100644
index 00000000..708533b1
--- /dev/null
+++ b/docs/procedures/git-workflow-detailed.md
@@ -0,0 +1,38 @@
+# Git Workflow Detailed Rules
+
+## Branch Management
+
+**Core principle: Working on main creates future work**. Every commit on main that should be on a feature branch guarantees recovery work: cherry-picking, rebasing, or complex git surgery. This violates the subtraction principle - we're adding unnecessary future tasks.
+
+**Go slow to go fast**: The recovery tax compounds invisibly. A stale starting point pollutes every subsequent action - your PR carries ghost commits, review gets clouded by unintended diffs, context windows fill with noise. The principle isn't about git mechanics but about preserving clarity of intent. When we rush past orientation, we mortgage our future attention.
+
+### Quick orientation checks (prevent future cleanup)
+1. `mcp__git__git_status` - Where am I? What's already changed?
+   → [subtraction-creates-value](../../knowledge/principles/subtraction-creates-value.md) (avoid recovery tax)
+2. Check current branch - Am I on main? Do I have uncommitted work?
+3. **Is main current?** - `git fetch && git status` - Behind origin/main means your PR will include unwanted commits
+   → [subtraction-creates-value](../../knowledge/principles/subtraction-creates-value.md)
+4. If changes exist on main - commit them properly or stash before branching
+
+Starting from a stale foundation guarantees the recovery tax - double work to achieve what orientation would have prevented.
+
+### Standards (not methods)
+- Branch naming: `type/description` (e.g., `feature/add-authentication`, `fix/login-bug`)
+- Issue suffix: `type/description-123` (e.g., `feature/add-authentication-512`)
+- Order: Check surroundings → create branch → switch → work → commit
+  → [subtraction-creates-value](../../knowledge/principles/subtraction-creates-value.md) (prevent recovery work)
+
+These standards make intent visible and prevent the recovery tax.
+
+## Directory to Symlink Conversions
+When converting a directory to a symlink (or vice versa), it's safer to use different names or do it in separate commits to avoid git tree corruption.
+
+**Why**: Git can create invalid tree objects when the same path transitions from directory to symlink within a single commit, causing push failures with "duplicateEntries" errors.
+
+**Safe approaches**:
+1. Use different names (e.g., rename directory first, then create symlink)
+2. Split into separate commits (remove directory in one commit, add symlink in another)
+3. Create fresh branch from clean state if corruption occurs
+
+## Think-Tank Content in Worktrees
+**CRITICAL**: Never add think-tank notes or personal content to worktree locations. Worktrees are temporary directories that will be deleted when cleanup occurs. Always use the main repository at `/think-tank/` for any persistent personal content, notes, or documentation.
\ No newline at end of file
diff --git a/docs/procedures/issue-to-pr-detailed-workflow.md b/docs/procedures/issue-to-pr-detailed-workflow.md
new file mode 100644
index 00000000..629ee6bf
--- /dev/null
+++ b/docs/procedures/issue-to-pr-detailed-workflow.md
@@ -0,0 +1,106 @@
+# Issue-to-PR Detailed Workflow
+
+The complete mechanical workflow from GitHub issue to merged pull request.
+
+## The Complete Flow
+
+```
+GitHub Issue → Planning Mode → Implementation → Pull Request → Review → Merge
+```
+
+## Step-by-Step Mechanics
+
+### 1. GitHub Issue Defines the Work
+
+Every task starts as a GitHub issue:
+- Clear problem statement  
+- Success criteria defined
+- Labels automatically assigned by Claude Code GitHub Action based on principles
+
+**Anti-pattern**: Starting work without an issue leads to scope creep and unclear PRs.
+
+### 2. Planning Mode Review
+
+Run `/close-issue <number>` with planning mode (default):
+- Claude analyzes the issue
+- Presents a plan for review
+- You approve, refine, or reject
+
+**Key insight**: This shifts you from "driving" to "managing" - you review plans, not implementation details.
+
+### 3. Implementation in Isolation
+
+Once plan is approved:
+- Automatic worktree creation for complete isolation
+- Claude implements in focused sessions
+- Each commit represents verified progress
+
+**Tools involved**:
+- [Git worktrees](../../knowledge/procedures/worktree-workflow.md) for isolation
+- [Git workflow](../../knowledge/procedures/git-workflow.md) for commits
+- MCP tools for file operations
+
+### 4. Pull Request Packages the Solution
+
+Implementation complete:
+- Push branch to remote
+- Create PR referencing "Closes #<issue>"
+- PR description explains the solution
+
+**Quality gates**:
+- Small, focused changes (planning mode enables this)
+- Clear connection to original issue
+- Tests pass, linting clean
+
+### 5. Review Completes the Cycle
+
+PR review happens at the right altitude:
+- Review the solution, not individual lines
+- Verify it solves the original issue
+- Merge when approved
+
+### 6. Post-Merge Workflow
+
+After merging via GitHub UI:
+1. Exit Claude Code
+2. `git checkout main`
+3. `git pull origin main`
+4. `source setup.sh`
+5. Start new terminal session
+6. Restart Claude Code:
+   - Resume last chat for context continuity
+   - Or start fresh for new work
+
+**Note**: This manual process ensures clean environment and updated configurations.
+
+### 7. Optional: Post-PR Retro
+
+For significant work:
+- Run [post-PR mini retro](../../knowledge/procedures/post-pr-mini-retro.md)
+- Capture learnings
+- Update procedures if needed
+- Document any ghost procedures discovered - see [Procedure Creation](../../knowledge/procedures/procedure-creation.md)
+
+## Why This Works
+
+1. **Clear boundaries**: Issues define WHAT, PRs deliver solutions
+2. **Parallel execution**: Multiple issues → multiple agents → multiple PRs
+3. **Quality through planning**: Better plans = better PRs
+4. **Reduced cognitive load**: Review plans and PRs, not live coding
+
+## Configuration
+
+Planning mode should be enabled by default for all users:
+```bash
+# In ~/.claude/settings.json
+{
+  "defaultMode": "plan"
+}
+```
+
+**Recommendation**: Add this to your `setup.sh` or dotfiles to ensure all team members start with planning mode enabled. This enforces OSE principles from day one.
+
+## Related
+
+- [tmux + git worktrees + Claude Code + Planning Mode](../../knowledge/procedures/tmux-git-worktrees-claude-code.md) - The complete productivity system
+- [OSE Principle](../../knowledge/principles/ose.md) - Why this workflow embodies management over doing
\ No newline at end of file
diff --git a/docs/procedures/procedure-creation-guide.md b/docs/procedures/procedure-creation-guide.md
new file mode 100644
index 00000000..9beee68b
--- /dev/null
+++ b/docs/procedures/procedure-creation-guide.md
@@ -0,0 +1,97 @@
+# Procedure Creation Guide
+
+How to capture ghost procedures and improve existing ones, inspired by Sam Carpenter's "Work the System".
+
+## Ghost Procedures
+
+Ghost procedures are the unwritten processes we follow repeatedly but haven't documented. Like Sam Carpenter discovered after 25 years of firefighting at his telephone answering service, these hidden procedures are everywhere - we just need to capture them.
+
+## When to Create a New Procedure
+
+Create a procedure when you:
+- Do something more than twice
+- Explain how to do something
+- Find yourself saying "the way we usually..."
+- Discover an undocumented pattern
+- Hit the same problem repeatedly
+- Notice tribal knowledge that should be shared
+
+## When to Improve Existing Procedures
+
+Improve a procedure when:
+- It feels incomplete or unclear
+- You had to figure out missing steps
+- The context has changed
+- You found a better way
+- It references outdated tools/methods
+
+## Creating a New Procedure
+
+1. **Check if it exists** - Look in `procedures/` first
+2. **Name it clearly** - Use verb-noun format (e.g., `manage-dependencies.md`)
+3. **Start simple** - Even a rough draft is better than nothing
+4. **Follow the template** below
+5. **Link it** - Add to relevant sections in ai-index.md
+
+**Quick capture option**: Use the [Procedure Documentation issue template](/.github/ISSUE_TEMPLATE/procedure-documentation.md) to quickly document a ghost procedure for later formalization.
+
+## Procedure Template
+
+```markdown
+# [Procedure Name]
+
+Brief description of what this procedure accomplishes.
+
+## When to Use This
+
+Specific situations or triggers that indicate this procedure should be followed.
+
+## Prerequisites
+
+- Required tools, access, or knowledge
+- Links to related procedures
+
+## Procedure
+
+1. **Step name** - Clear action
+   - Sub-step if needed
+   - Expected outcome
+
+2. **Next step** - What to do next
+   - Details
+   - Validation
+
+## Common Issues
+
+- Known problems and solutions
+- Edge cases to watch for
+
+## See Also
+
+- Related procedures
+- Relevant principles
+```
+
+## Improving Procedures
+
+When improving:
+1. **Make the edit** - Don't create v2 files (versioning mindset)
+2. **Add what's missing** - Fill gaps you discovered
+3. **Remove what's outdated** - Subtraction creates value
+4. **Test it mentally** - Would this help someone new?
+
+## The Carpenter Principle
+
+Sam Carpenter transformed his business by documenting every procedure, no matter how small. After 25 years of chaos, systematic documentation gave him control. Every ghost procedure you capture reduces future firefighting.
+
+Remember: **Perfect is the enemy of good**. A rough procedure that exists beats a perfect one that doesn't.
+
+## Examples of Ghost Procedures to Capture
+
+- How we handle MCP server updates
+- Steps for debugging flaky tests
+- Process for reviewing PRs
+- Method for setting up new machines
+- Workflow for handling service outages
+
+Start capturing - every documented procedure is one less fire to fight!
\ No newline at end of file
diff --git a/docs/procedures/worktree-troubleshooting.md b/docs/procedures/worktree-troubleshooting.md
new file mode 100644
index 00000000..ddbdeab6
--- /dev/null
+++ b/docs/procedures/worktree-troubleshooting.md
@@ -0,0 +1,29 @@
+# Worktree Troubleshooting Guide
+
+## Known Failure Modes (From Crisis Learning)
+
+### Dirty main
+**Problem**: Worktree inherits untracked files → empty PR
+**Solution**: Always stash or commit changes before creating worktree
+
+### Wrong base commit
+**Problem**: Local main ahead of origin → PR shows no diff
+**Solution**: Always fetch and verify main is up-to-date with origin/main
+
+### Wrong file paths
+**Problem**: Files created in main, not worktree → empty commits
+**Solution**: Always use full worktree path for all file operations
+
+### OSE Principle violation
+**Problem**: Not verifying GitHub PR diff before creating PR
+**Solution**: Always run `mcp__git__git_diff target: origin/main` before creating PR
+**Reference**: [OSE Principle](../../knowledge/principles/ose.md) - Only GitHub PR diff matters for review
+
+### Broken symlinks
+**Problem**: Running setup.sh from worktree creates symlinks that break when worktree is deleted
+**Solution**: Never run `source setup.sh` from worktree - only from main repository
+**Note**: setup.sh automatically detects and fixes broken symlinks from deleted worktrees
+
+### Think-tank content in worktrees
+**Problem**: Personal notes or think-tank content added to worktree gets lost when worktree is deleted
+**Solution**: Always use the main repository at `/think-tank/` for any persistent personal content
\ No newline at end of file
diff --git a/knowledge/ai-index.md b/knowledge/ai-index.md
index 7d898eba..0137a441 100644
--- a/knowledge/ai-index.md
+++ b/knowledge/ai-index.md
@@ -20,6 +20,7 @@ Your starting point for understanding and working with this dotfiles repository.
 - Apply [Tracer Bullets](principles/tracer-bullets.md) - Iterative development
 
 ### Handle GitHub Tasks
+- Create issues with [GitHub Issue Creation](procedures/github-issue-creation.md) - Smart template selection
 - See [Issue to PR Workflow](procedures/issue-to-pr-workflow.md) - High-level flow
 - Follow [Close Issue Procedure](procedures/close-issue-procedure.md) - Detailed steps
 - Use GitHub MCP server for all GitHub operations
diff --git a/knowledge/principles/README.md b/knowledge/principles/README.md
index 0499547e..3df8160b 100644
--- a/knowledge/principles/README.md
+++ b/knowledge/principles/README.md
@@ -7,7 +7,7 @@ Foundational truths that guide development across all projects.
 
 ## Operating Principles
 - `ai-provider-agnosticism.md` - **Crisis-Proven**: Interchangeable AI providers for service outage resilience
-- `continuous-improvement.md` - Extract gleanings from every experience for systems strengthening
+- `eager-evolution.md` - **Living System**: Eagerly seeks to evolve, self-heal, and fit like a well-worn glove
 - `invent-and-simplify.md` - Constant reinvention and simplifying assumptions
 - `no-leaks.md` - Keep company details private while enabling rich AI context via gitignored documentation
 - `ose.md` - Outside and Slightly Elevated perspective for clear decision-making
diff --git a/knowledge/principles/continuous-improvement.md b/knowledge/principles/continuous-improvement.md
deleted file mode 100644
index e7068e44..00000000
--- a/knowledge/principles/continuous-improvement.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Continuous Improvement
-
-The principle that every experience contains gleanings worth extracting - insights that compound over time to strengthen systems and capabilities.
-
-**Wring out the towel**: Extract every drop of learning from each experience. The insights that seem obvious in hindsight are often the most valuable to document.
-
-**Never let a crisis go to waste**: Each failure or unexpected challenge becomes raw material for stronger systems and procedures.
-
-## The Spirit of Retrospection
-
-- **Mine the gleanings**: Look for patterns, tensions, and insights in whatever context just occurred
-- **Systems lens**: Focus on what would make future work flow more smoothly
-- **Principle tensions**: Notice when principles came into conflict and how decisions were made
-- **Compound learning**: Capture insights that build on previous knowledge
-
-## Collaborative Discovery
-
-The human drives the exploration while the agent provides observations when asked. This isn't a checklist - it's a conversation guided by curiosity about what can be learned and improved.
-
-**Context-aware**: The retrospective adapts to whatever just happened - post-PR work, crisis response, debugging sessions, or any significant effort.
-
-**Improvement focus**: What procedures need updating? What new patterns emerged? Which approaches felt natural versus forced?
-
-This principle transforms any pause into an opportunity for systems strengthening through reflective learning. See [Procedure Creation](../procedures/procedure-creation.md) for capturing ghost procedures discovered during retros.
diff --git a/knowledge/principles/eager-evolution.md b/knowledge/principles/eager-evolution.md
new file mode 100644
index 00000000..c67c3742
--- /dev/null
+++ b/knowledge/principles/eager-evolution.md
@@ -0,0 +1,51 @@
+# Eager Evolution
+
+The principle that systems should be **programmed to learn and get better** - creating a living organism that eagerly seeks to evolve, self-heal through feedback loops, and fit its owner like a well-worn glove.
+
+**Not just improving, but actively hunting**: This isn't passive continuous improvement from a management textbook. This is about creating systems with their own metabolism for growth - ones that mirror and amplify your own learning mindset.
+
+## The Living System
+
+Our dotfiles aren't just configuration - they're a **living system** that:
+
+- **Eagerly seeks to evolve** - Actively hunting for ways to get better, not waiting for problems
+- **Self-heals through feedback loops** - MCP error reporting, retros, ghost procedure capture
+- **Mirrors your strengths** - Reflects your own mindsets about learning and growth
+- **Fits like a well-worn glove** - Custom-tailored to how you actually work
+- **Programs itself to learn** - Each experience adds to its intelligence
+
+## Evidence Throughout the Codebase
+
+This principle manifests everywhere:
+- **MCP Error Reporting** → Self-healing feedback loops
+- **Ghost Procedure Capture** → Learning from undocumented patterns
+- **Post-PR Mini Retros** → Mining gleanings from every experience
+- **INJECT patterns** → Single source of truth that evolves
+- **Snowball Method** → Compound learning over time
+- **Worktree failures documented** → Crisis becomes prevention system
+
+## The Symbiotic Relationship
+
+You and your system grow together:
+- System learns your patterns → You work more efficiently
+- You discover better methods → System captures and reinforces them
+- System reveals tensions → You make better principle-based decisions
+- You hit obstacles → System evolves to prevent them
+
+**This is cross-linked systems thinking** - a system programmed to learn and get better, creating exponential returns as both human and system evolve together.
+
+## Mining the Gleanings
+
+**Wring out the towel**: Extract every drop of learning from each experience. The insights that seem obvious in hindsight are often the most valuable to document.
+
+**Never let a crisis go to waste**: Each failure or unexpected challenge becomes raw material for stronger systems and procedures.
+
+## In Practice
+
+- Look for patterns, tensions, and insights in every context
+- Focus on what would make future work flow more smoothly
+- Notice when principles conflict and how decisions get made
+- Capture insights that build on previous knowledge
+- Transform any pause into an opportunity for evolution
+
+This principle transforms systems from static tools into eager partners in growth. See [Post-PR Mini Retro](../procedures/post-pr-mini-retro.md) for structured evolution and [Procedure Creation](../procedures/procedure-creation.md) for capturing ghost procedures discovered during evolution.
\ No newline at end of file
diff --git a/knowledge/procedures/close-issue-procedure.md b/knowledge/procedures/close-issue-procedure.md
index 50a0ed54..161c43fe 100644
--- a/knowledge/procedures/close-issue-procedure.md
+++ b/knowledge/procedures/close-issue-procedure.md
@@ -1,94 +1,6 @@
 # Close Issue Procedure
 
-Detailed workflow for analyzing and implementing GitHub issues.
+Analyze GitHub issues and determine the path: quick close, spike research, or full implementation to PR.
 
-## Step 1: Analyze the Issue
-
-Use `mcp__github__get_issue` to read the issue and determine:
-- Is this already resolved? → Quick close
-- Does this need implementation? → Full workflow
-- Is this invalid/duplicate? → Close with explanation
-- **Is this a spike?** → Spike workflow (no PR)
-- **Repository check**: If issue requires git operations in a different repo, STOP and ask human to restart session there. Claude Code cannot `cd` outside initial directory tree, breaking git workflows.
-- Check recent merged PRs for similar patterns → `mcp__github__list_pull_requests` (state: "closed")
-- Get issue comments with `mcp__github__get_issue_comments` to enrich understanding
-
-**Clarity opportunity**: If the issue contains vague language ("doesn't work", "should handle", "it depends"), consider exploring with EARS patterns to surface hidden assumptions and edge cases. This often reveals interesting test scenarios and sparks productive conversations about the real requirements. See [EARS Requirements](ears-requirements.md) for conversation-driven discovery techniques.
-
-## Quick Close Path
-
-If the issue is already resolved, invalid, or duplicate:
-1. Add explanatory comment with `mcp__github__add_issue_comment`
-2. Close with `mcp__github__update_issue` (state: "closed")
-3. Done!
-
-## Spike Workflow Path
-
-If the issue is a spike:
-1. Research. Prototype. Document findings.
-2. Comment findings with `mcp__github__add_issue_comment`
-3. Discuss with human
-4. Close issue when done
-5. **NO PR** - spikes deliver knowledge, not code
-
-## Full Implementation Path
-
-If the issue needs implementation:
-
-### 1. Set Up Development
-Follow [Worktree Workflow](worktree-workflow.md) to create isolated development environment.
-
-### 2. Implement Solution
-Apply tracer bullets methodology:
-
-**First, establish your target:**
-- Define clear success criteria for the issue resolution
-- Understand what failure looks like (how to detect when it's NOT fixed)
-- Create verification methods (tests, checks, validations) that can detect hits/misses
-
-**Then iterate with tracer rounds:**
-- Fire and miss: See verifications fail (confirms target detection works)
-- Adjust aim: Modify implementation while keeping target stable
-- Fire again: Run verifications to check progress
-- Use TodoWrite to track verified hits on target
-- Each commit is a confirmed hit - only commit code that moves toward the target
-
-**Natural behaviors that emerge:**
-- Test-first development (you need a target before you can aim)
-- Incremental progress through verified steps
-- Progressive refinement from rough to precise shots
-- Clear trajectory visible through commit history
-
-Follow [Git Workflow](git-workflow.md) for commit standards.
-
-### 3. Create Pull Request
-- Push the feature branch to remote
-- Look for PR template:
-  - First check local repo: `.github/PULL_REQUEST_TEMPLATE.md`
-  - If not found, use dotfiles fallback: `~/ppv/pillars/dotfiles/.github/PULL_REQUEST_TEMPLATE.md`
-  - Inform which template is being used for transparency
-- Create PR with `mcp__github__create_pull_request` following the discovered template
-- Add "Conduct post-PR mini retro" to your todo list
-
-### 4. Iterate Based on Feedback
-Keep worktree active for PR adjustments based on the tracer bullets principle. Only cleanup after PR is merged.
-
-If MCP tools fail during implementation, follow [MCP Error Reporting](mcp-error-reporting.md) to create self-healing feedback loop.
-
-## Decision Matrix
-
-- **Spike label** → Spike workflow (research only)
-- **Bug report with clear reproduction** → Implementation path
-- **Feature request approved by maintainer** → Implementation path  
-- **Question already answered** → Quick close with link
-- **Duplicate issue** → Quick close referencing original
-- **Invalid/out of scope** → Quick close with explanation
-- **Implemented in recent PR** → Quick close with PR reference
-
-Remember: Act agentically. Make the decision and execute.
-
-## See Also
-
-- [Issue to PR Workflow](issue-to-pr-workflow.md) - High-level workflow overview
-- [Tracer Bullets](../principles/tracer-bullets.md) - Target-first development
-- [Post-PR Mini Retro](post-pr-mini-retro.md) - Learning from implementation
\ No newline at end of file
+**When to use**: Processing any GitHub issue with the /close-issue command
+**Details**: See [close-issue-guide.md](/.github/ISSUE_TEMPLATE/close-issue-guide.md)
\ No newline at end of file
diff --git a/knowledge/procedures/git-workflow.md b/knowledge/procedures/git-workflow.md
index daa0b40b..d5840c8f 100644
--- a/knowledge/procedures/git-workflow.md
+++ b/knowledge/procedures/git-workflow.md
@@ -1,59 +1,10 @@
 # Git Workflow Rules
 
-## MCP Git Tools Usage
-**IMPORTANT**: Use `mcp__git__*` tools instead of bash commands.
-- **Chain Commands**: Use `mcp__git__git_batch` to combine multiple git operations efficiently
-
-## Commit Standards
-- Always use conventional commit syntax: `<type>[scope]: description` (scope optional but encouraged; use separate `-m` for trailers)
-- Good scope choices add context about what component is being modified (e.g., api, ui, auth, config, docs)
-- Use `Principle: <slug>` trailer when work resonates with a specific principle (e.g., `Principle: subtraction-creates-value`, `Principle: versioning-mindset`, `Principle: systems-stewardship`)
-- Commit early and often with meaningful changes
-  → [tracer-bullets](../principles/tracer-bullets.md) → [versioning-mindset](../principles/versioning-mindset.md)
-- Remember: Commits build toward PRs - that's where feedback happens
-  → [systems-stewardship](../principles/systems-stewardship.md) ([OSE](../principles/ose.md) perspective)
-
-## Branch Management
-
-**Core principle: Working on main creates future work**. Every commit on main that should be on a feature branch guarantees recovery work: cherry-picking, rebasing, or complex git surgery. This violates the subtraction principle - we're adding unnecessary future tasks.
-
-**Go slow to go fast**: The recovery tax compounds invisibly. A stale starting point pollutes every subsequent action - your PR carries ghost commits, review gets clouded by unintended diffs, context windows fill with noise. The principle isn't about git mechanics but about preserving clarity of intent. When we rush past orientation, we mortgage our future attention.
-
-### Quick orientation checks (prevent future cleanup)
-1. `mcp__git__git_status` - Where am I? What's already changed?
-   → [subtraction-creates-value](../principles/subtraction-creates-value.md) (avoid recovery tax)
-2. Check current branch - Am I on main? Do I have uncommitted work?
-3. **Is main current?** - `git fetch && git status` - Behind origin/main means your PR will include unwanted commits
-   → [subtraction-creates-value](../principles/subtraction-creates-value.md)
-4. If changes exist on main - commit them properly or stash before branching
-
-Starting from a stale foundation guarantees the recovery tax - double work to achieve what orientation would have prevented.
-
-### Standards (not methods)
-- Branch naming: `type/description` (e.g., `feature/add-authentication`, `fix/login-bug`)
-- Issue suffix: `type/description-123` (e.g., `feature/add-authentication-512`)
-- Order: Check surroundings → create branch → switch → work → commit
-  → [subtraction-creates-value](../principles/subtraction-creates-value.md) (prevent recovery work)
-
-These standards make intent visible and prevent the recovery tax.
-
-## Post-Merge Best Practice
-After merging a PR, switch to the base branch and pull latest to avoid working on stale code.
-→ [versioning-mindset](../principles/versioning-mindset.md) (stay current with ground truth)
-
-## Common Errors to Avoid
-- Don't thank self when closing your own PRs
-- If git MCP tools fail, report via [MCP Error Reporting](mcp-error-reporting.md)
-
-## Directory to Symlink Conversions
-When converting a directory to a symlink (or vice versa), it's safer to use different names or do it in separate commits to avoid git tree corruption.
-
-**Why**: Git can create invalid tree objects when the same path transitions from directory to symlink within a single commit, causing push failures with "duplicateEntries" errors.
-
-**Safe approaches**:
-1. Use different names (e.g., rename directory first, then create symlink)
-2. Split into separate commits (remove directory in one commit, add symlink in another)
-3. Create fresh branch from clean state if corruption occurs
-
-## Think-Tank Content in Worktrees
-**CRITICAL**: Never add think-tank notes or personal content to worktree locations. Worktrees are temporary directories that will be deleted when cleanup occurs. Always use the main repository at `/think-tank/` for any persistent personal content, notes, or documentation.
+Use MCP git tools, follow conventional commits, and maintain branch hygiene to prevent recovery tax.
+
+**When to use**: All git operations in this repository
+**Core rules**: 
+- Use `mcp__git__*` tools (chain with `git_batch`)
+- Conventional commits: `type[scope]: description`
+- Never work on main - always branch first
+**Details**: See [git-workflow-detailed.md](/docs/procedures/git-workflow-detailed.md)
\ No newline at end of file
diff --git a/knowledge/procedures/github-issue-creation.md b/knowledge/procedures/github-issue-creation.md
new file mode 100644
index 00000000..3e4b00a5
--- /dev/null
+++ b/knowledge/procedures/github-issue-creation.md
@@ -0,0 +1,56 @@
+# GitHub Issue Creation
+
+Intelligent issue creation that auto-detects type, suggests templates, and links relevant procedures.
+
+## When to Use This
+
+When users request "create a GitHub issue for..." or need to document a new task, bug, or enhancement.
+
+## Decision Tree
+
+1. **Analyze the request** to determine issue type:
+   - Bug report → Use bug template
+   - Feature request → Use feature template
+   - MCP tool error → Use mcp-tool-error template
+   - Procedure documentation → Use procedure-documentation template
+   - General enhancement → Use enhancement template
+
+2. **Scan for keywords** to link relevant procedures:
+   - "MCP" → Link MCP-related procedures
+   - "worktree" → Link worktree-workflow
+   - "retro" → Link post-pr-mini-retro
+   - "git" → Link git-workflow
+
+3. **Auto-populate context**:
+   - Related principles from knowledge/principles/
+   - Existing procedures that might help
+   - Recent similar issues (if any)
+
+## Template Mapping
+
+| Request Contains | Suggested Template | Key Fields |
+|-----------------|-------------------|------------|
+| "error", "fails", "broken", "bug" | issue.md (bug report) | Steps to reproduce, expected behavior |
+| "feature", "add", "implement", "enhance" | issue.md (enhancement) | Problem statement, proposed solution |
+| "mcp__git", "mcp__github", "tool error" | mcp-tool-error.md | Tool name, error message, reproduction |
+| "procedure", "document process", "ghost" | procedure-documentation.md | Procedure name, steps, trigger |
+| General request | issue.md | Flexible format for any issue type |
+
+## Available Templates
+
+- **issue.md** - General purpose template for bugs, features, questions
+- **mcp-tool-error.md** - Specific to MCP tool failures (auto-assigns)
+- **procedure-documentation.md** - For capturing ghost procedures
+
+## Implementation
+
+Use `mcp__github__create_issue` with:
+- Appropriate labels based on type
+- Cross-referenced procedures in body
+- Clear title following conventions
+- Assignee if specified
+
+## See Also
+
+- [Issue to PR Workflow](issue-to-pr-workflow.md)
+- [Close Issue Procedure](close-issue-procedure.md)
\ No newline at end of file
diff --git a/knowledge/procedures/issue-to-pr-workflow.md b/knowledge/procedures/issue-to-pr-workflow.md
index ed4c34e2..2397006c 100644
--- a/knowledge/procedures/issue-to-pr-workflow.md
+++ b/knowledge/procedures/issue-to-pr-workflow.md
@@ -1,106 +1,6 @@
 # Issue-to-PR Workflow
 
-The mechanical workflow that delivers value: from GitHub issue to merged pull request.
+Transform GitHub issues into merged PRs through planning mode and isolated implementation.
 
-## The Complete Flow
-
-```
-GitHub Issue → Planning Mode → Implementation → Pull Request → Review → Merge
-```
-
-## Step-by-Step Mechanics
-
-### 1. GitHub Issue Defines the Work
-
-Every task starts as a GitHub issue:
-- Clear problem statement  
-- Success criteria defined
-- Labels automatically assigned by Claude Code GitHub Action based on principles
-
-**Anti-pattern**: Starting work without an issue leads to scope creep and unclear PRs.
-
-### 2. Planning Mode Review
-
-Run `/close-issue <number>` with planning mode (default):
-- Claude analyzes the issue
-- Presents a plan for review
-- You approve, refine, or reject
-
-**Key insight**: This shifts you from "driving" to "managing" - you review plans, not implementation details.
-
-### 3. Implementation in Isolation
-
-Once plan is approved:
-- Automatic worktree creation for complete isolation
-- Claude implements in focused sessions
-- Each commit represents verified progress
-
-**Tools involved**:
-- [Git worktrees](worktree-workflow.md) for isolation
-- [Git workflow](git-workflow.md) for commits
-- MCP tools for file operations
-
-### 4. Pull Request Packages the Solution
-
-Implementation complete:
-- Push branch to remote
-- Create PR referencing "Closes #<issue>"
-- PR description explains the solution
-
-**Quality gates**:
-- Small, focused changes (planning mode enables this)
-- Clear connection to original issue
-- Tests pass, linting clean
-
-### 5. Review Completes the Cycle
-
-PR review happens at the right altitude:
-- Review the solution, not individual lines
-- Verify it solves the original issue
-- Merge when approved
-
-### 6. Post-Merge Workflow
-
-After merging via GitHub UI:
-1. Exit Claude Code
-2. `git checkout main`
-3. `git pull origin main`
-4. `source setup.sh`
-5. Start new terminal session
-6. Restart Claude Code:
-   - Resume last chat for context continuity
-   - Or start fresh for new work
-
-**Note**: This manual process ensures clean environment and updated configurations.
-
-### 7. Optional: Post-PR Retro
-
-For significant work:
-- Run [post-PR mini retro](post-pr-mini-retro.md)
-- Capture learnings
-- Update procedures if needed
-- Document any ghost procedures discovered - see [Procedure Creation](procedure-creation.md)
-
-## Why This Works
-
-1. **Clear boundaries**: Issues define WHAT, PRs deliver solutions
-2. **Parallel execution**: Multiple issues → multiple agents → multiple PRs
-3. **Quality through planning**: Better plans = better PRs
-4. **Reduced cognitive load**: Review plans and PRs, not live coding
-
-## Configuration
-
-Planning mode should be enabled by default for all users:
-```bash
-# In ~/.claude/settings.json
-{
-  "defaultMode": "plan"
-}
-```
-
-**Recommendation**: Add this to your `setup.sh` or dotfiles to ensure all team members start with planning mode enabled. This enforces OSE principles from day one.
-
-## Related
-
-- [tmux + git worktrees + Claude Code + Planning Mode](tmux-git-worktrees-claude-code.md) - The complete productivity system
-- [OSE Principle](../principles/ose.md) - Why this workflow embodies management over doing
\ No newline at end of file
+**When to use**: Starting any feature work from a GitHub issue
+**Details**: See [issue-to-pr-detailed-workflow.md](/docs/procedures/issue-to-pr-detailed-workflow.md)
\ No newline at end of file
diff --git a/knowledge/procedures/post-pr-mini-retro.md b/knowledge/procedures/post-pr-mini-retro.md
index e1114035..3e82030d 100644
--- a/knowledge/procedures/post-pr-mini-retro.md
+++ b/knowledge/procedures/post-pr-mini-retro.md
@@ -1,3 +1,73 @@
 # Post-PR Mini Retro
 
-Conduct mini retrospectives after PRs to capture learnings. See [Continuous Improvement](../principles/continuous-improvement.md) for the underlying principle.
\ No newline at end of file
+<<<<<<< HEAD
+After submitting a pull request for feature-related workflows, conduct a mini retro focused on systems improvement. This supports the Snowball Method by capturing learnings and dedicating 20% of time to systems improvement.
+
+**Wring out the towel**: Extract every drop of learning from each experience - the insights that seem obvious in hindsight are often the most valuable to document. **Never let a crisis go to waste**: Each failure or unexpected challenge becomes raw material for stronger systems and procedures.
+
+## IMPORTANT: Agent-Led Collaborative Process
+
+**The agent drives the retro while actively inviting human participation:**
+
+1. **Agent creates a retro plan**: Think through the implementation, identify key moments, and structure the discussion
+2. **Agent invites human in**: Present your plan and explicitly invite the human to participate
+3. **Agent leads with substance**: Share your genuine reflections, tensions observed, and questions you have
+4. **Human adds perspective**: The human provides input where they have insights or corrections
+5. **Collaborative discussion**: Both parties explore insights together
+6. **Human confirms completion**: The human explicitly confirms when the retro is complete
+
+The agent should:
+- Start with something like: "I've been reflecting on our implementation. Here's my retro plan... [plan]. Let's work through this together."
+- Share real observations and questions, not just run through a checklist
+- Be specific about decision points and tensions noticed
+- Genuinely seek the human's perspective on key moments
+
+## Retro Questions
+
+**What worked well?**
+- Which documented procedures were followed successfully?
+- What felt smooth and efficient in the workflow?
+
+**What didn't work as expected?**
+- Which procedures were unclear or incomplete?
+- Where did manual course corrections become necessary?
+- What assumptions or approaches needed adjustment?
+
+**Procedure adherence:**
+- Which defined procedures were used as documented?
+- Which procedures were improvised or done with uncertainty?
+- Where did the human need to steer or provide manual input?
+
+**Systems improvement opportunities:**
+- What procedures need updating or clarification?
+- What new procedures should be documented?
+- What tools or workflows could be enhanced?
+
+**Formatting overhead check:**
+- Did any requirements feel like unnecessary cognitive load or "formatting overhead"?
+- Were there moments where precision requirements (line counts, exact formatting, etc.) made tasks harder than needed?
+- What formatting or precision requirements could be relaxed to reduce friction?
+- Permission to flag when working harder/longer than necessary due to overly specific constraints
+
+**Tool boundary clarity:**
+- Were there moments of uncertainty about which tool to use for a task?
+- Which tool descriptions or boundaries could be clearer?
+- Which tools needed example usage, edge cases, or input format requirements to be more obvious?
+- What tool definitions felt like they needed "prompt engineering attention" to be clearer?
+
+**Principle tensions:**
+- Which principles came into tension during decision points?
+- Which principle did you lean on when there was conflict, and why?
+- How did choosing one principle over another create tension or trade-offs?
+- What decisions required balancing competing principles?
+
+## Personality-Driven Focus
+
+The `/retro` command will select an appropriate consultant personality based on PR context:
+- **Jonah**: When dealing with constraints, bottlenecks, or competing priorities
+- **Brent**: When heroic interventions occurred or knowledge gaps were exposed
+- Future personalities can be added to `.claude/personalities/` as needed
+
+This ensures each retro has a specific lens while maintaining a single, unified command.
+
+This retro helps identify the 20% of systems work that enables the 80% of feature work to flow more smoothly.
diff --git a/knowledge/procedures/procedure-creation.md b/knowledge/procedures/procedure-creation.md
index f10387b3..655a47a9 100644
--- a/knowledge/procedures/procedure-creation.md
+++ b/knowledge/procedures/procedure-creation.md
@@ -1,97 +1,6 @@
 # Procedure Creation
 
-How to capture ghost procedures and improve existing ones, inspired by Sam Carpenter's "Work the System".
+Capture ghost procedures - the unwritten processes we follow repeatedly but haven't documented.
 
-## Ghost Procedures
-
-Ghost procedures are the unwritten processes we follow repeatedly but haven't documented. Like Sam Carpenter discovered after 25 years of firefighting at his telephone answering service, these hidden procedures are everywhere - we just need to capture them.
-
-## When to Create a New Procedure
-
-Create a procedure when you:
-- Do something more than twice
-- Explain how to do something
-- Find yourself saying "the way we usually..."
-- Discover an undocumented pattern
-- Hit the same problem repeatedly
-- Notice tribal knowledge that should be shared
-
-## When to Improve Existing Procedures
-
-Improve a procedure when:
-- It feels incomplete or unclear
-- You had to figure out missing steps
-- The context has changed
-- You found a better way
-- It references outdated tools/methods
-
-## Creating a New Procedure
-
-1. **Check if it exists** - Look in `procedures/` first
-2. **Name it clearly** - Use verb-noun format (e.g., `manage-dependencies.md`)
-3. **Start simple** - Even a rough draft is better than nothing
-4. **Follow the template** below
-5. **Link it** - Add to relevant sections in ai-index.md
-
-**Quick capture option**: Use the [Procedure Documentation issue template](/.github/ISSUE_TEMPLATE/procedure-documentation.md) to quickly document a ghost procedure for later formalization.
-
-## Procedure Template
-
-```markdown
-# [Procedure Name]
-
-Brief description of what this procedure accomplishes.
-
-## When to Use This
-
-Specific situations or triggers that indicate this procedure should be followed.
-
-## Prerequisites
-
-- Required tools, access, or knowledge
-- Links to related procedures
-
-## Procedure
-
-1. **Step name** - Clear action
-   - Sub-step if needed
-   - Expected outcome
-
-2. **Next step** - What to do next
-   - Details
-   - Validation
-
-## Common Issues
-
-- Known problems and solutions
-- Edge cases to watch for
-
-## See Also
-
-- Related procedures
-- Relevant principles
-```
-
-## Improving Procedures
-
-When improving:
-1. **Make the edit** - Don't create v2 files (versioning mindset)
-2. **Add what's missing** - Fill gaps you discovered
-3. **Remove what's outdated** - Subtraction creates value
-4. **Test it mentally** - Would this help someone new?
-
-## The Carpenter Principle
-
-Sam Carpenter transformed his business by documenting every procedure, no matter how small. After 25 years of chaos, systematic documentation gave him control. Every ghost procedure you capture reduces future firefighting.
-
-Remember: **Perfect is the enemy of good**. A rough procedure that exists beats a perfect one that doesn't.
-
-## Examples of Ghost Procedures to Capture
-
-- How we handle MCP server updates
-- Steps for debugging flaky tests
-- Process for reviewing PRs
-- Method for setting up new machines
-- Workflow for handling service outages
-
-Start capturing - every documented procedure is one less fire to fight!
\ No newline at end of file
+**When to use**: Doing something more than twice, discovering undocumented patterns, or improving existing procedures
+**Details**: See [procedure-creation-guide.md](/docs/procedures/procedure-creation-guide.md)
\ No newline at end of file
diff --git a/knowledge/procedures/tmux-git-worktrees-claude-code.md b/knowledge/procedures/tmux-git-worktrees-claude-code.md
index df6f947a..ca234334 100644
--- a/knowledge/procedures/tmux-git-worktrees-claude-code.md
+++ b/knowledge/procedures/tmux-git-worktrees-claude-code.md
@@ -67,6 +67,6 @@ Immediate issue creation/resolution cycle maintains snowball method momentum rat
 
 - [Worktree Workflow](worktree-workflow.md) - technical isolation details
 - [Slash Command Generation](slash-command-generation.md) - automation mechanics
-- [Post-PR Mini Retro](post-pr-mini-retro.md) - continuous improvement
+- [Post-PR Mini Retro](post-pr-mini-retro.md) - eager evolution through learning
 
 This workflow transforms development from sequential file-editing to parallel task orchestration - the foundation of the 100x productivity multiplier.
\ No newline at end of file
diff --git a/knowledge/procedures/worktree-workflow.md b/knowledge/procedures/worktree-workflow.md
index a7cc6807..3b87f463 100644
--- a/knowledge/procedures/worktree-workflow.md
+++ b/knowledge/procedures/worktree-workflow.md
@@ -1,36 +1,7 @@
 # Git Worktree Workflow
 
-Suppose you need to work on multiple tasks simultaneously with complete code isolation between Claude Code instances. Git worktrees provide this isolation.
+Use git worktrees for complete code isolation between simultaneous tasks. Start from origin/main to prevent empty PRs.
 
-**PRINCIPLE**: Start worktrees from the same commit GitHub will use for the PR diff (usually origin/main).
-
-**CRITICAL**: Empty PR Prevention - Multiple failure modes discovered through painful experience.
-
-## Pre-flight Checks (REQUIRED)
-1. **Sync with origin**: `git fetch && git status` - ensure local main == origin/main
-2. **Clean workspace**: No untracked files or uncommitted changes in main
-3. **Verify starting point**: Worktree must branch from origin/main, not local main
-
-## Procedure
-1. `mkdir -p ~/ppv/pillars/dotfiles/worktrees`
-2. Create worktree from CLEAN origin/main:
-   - **New branch**: Use `mcp__git__git_worktree_add` with `create_branch: true`
-   - **Existing branch**: Use `mcp__git__git_worktree_add` with branch name
-3. **CRITICAL**: Do NOT run `source setup.sh` from worktree - creates broken symlinks
-   - Only use worktree for isolated development, not environment setup
-   - setup.sh automatically detects and fixes broken symlinks from deleted worktrees
-4. **Set working directory**: Use full worktree path (e.g., `/home/user/ppv/pillars/dotfiles/worktrees/feature-X/`) as prefix for ALL file operations to prevent empty PRs
-5. Work in worktree: Pass worktree path as `repo_path` to MCP tools
-6. **CRITICAL**: Check diff vs origin/main - `mcp__git__git_diff target: origin/main`
-7. Cleanup: Use `mcp__git__git_worktree_remove`
-
-## Known Failure Modes (From Crisis Learning)
-- **Dirty main**: Worktree inherits untracked files → empty PR
-- **Wrong base commit**: Local main ahead of origin → PR shows no diff
-- **Wrong file paths**: Files created in main, not worktree → empty commits
-- **[OSE Principle](../principles/ose.md)**: Only GitHub PR diff matters for review - must verify before creating PR
-- **Broken symlinks**: Running setup.sh from worktree creates symlinks that break when worktree is deleted
-- **Think-tank content in worktrees**: Never add think-tank notes or personal content to worktree locations - they're ephemeral and will be lost. Always use the main repository at `/think-tank/`
-
-## See Also
-- [Close Issue Procedure](close-issue-procedure.md) - Full workflow using worktrees for issue implementation
+**When to use**: Working on multiple issues simultaneously, need isolated development environments
+**Critical**: Pre-flight checks prevent empty PRs - fetch, clean workspace, verify starting point
+**Details**: See [worktree-troubleshooting.md](/docs/procedures/worktree-troubleshooting.md) for failure modes
\ No newline at end of file
diff --git a/mcp/servers/git-mcp-server/src/mcp_server_git/server.py b/mcp/servers/git-mcp-server/src/mcp_server_git/server.py
index 96a02794..c9893ae8 100644
--- a/mcp/servers/git-mcp-server/src/mcp_server_git/server.py
+++ b/mcp/servers/git-mcp-server/src/mcp_server_git/server.py
@@ -382,9 +382,8 @@ def git_commit(repo: git.Repo, message: str) -> str:
     return f"Changes committed successfully with hash {commit.hexsha}"
 
 def git_add(repo: git.Repo, files: list[str]) -> str:
-    # Validate that all files exist in the repository before attempting to stage them.
-    # This prevents the "empty PR" problem where git claims success even when files
-    # don't exist in the worktree, leading to commits with no actual changes.
+    # Validate that all files exist in the repository OR are tracked (deleted) files.
+    # This prevents the "empty PR" problem while allowing deleted files to be staged.
     repo_path = str(Path(repo.working_dir))
     
     # Validate paths for security (prevent path traversal)
@@ -393,14 +392,25 @@ def git_add(repo: git.Repo, files: list[str]) -> str:
         if not file_path.startswith(repo_path):
             raise ValueError(f"Invalid file path: {file}")
     
-    # Find missing files using list comprehension
-    missing_files = [
-        file for file in files 
-        if not os.path.exists(os.path.normpath(os.path.join(repo_path, file)))
-    ]
+    # Get all tracked files (including deleted ones) from git
+    try:
+        # List all files known to git (including deleted)
+        tracked_files = set(repo.git.ls_files().splitlines())
+        # Also include deleted files specifically
+        deleted_files = set(repo.git.ls_files('--deleted').splitlines())
+        all_known_files = tracked_files | deleted_files
+    except git.GitCommandError:
+        all_known_files = set()
+    
+    # Find files that neither exist on disk nor are tracked by git
+    invalid_files = []
+    for file in files:
+        file_path = os.path.normpath(os.path.join(repo_path, file))
+        if not os.path.exists(file_path) and file not in all_known_files:
+            invalid_files.append(file)
     
-    if missing_files:
-        raise FileNotFoundError(f"Files not found in repository: {', '.join(missing_files)}")
+    if invalid_files:
+        raise FileNotFoundError(f"Files not found in repository: {', '.join(invalid_files)}")
     
     repo.index.add(files)
     return f"Files staged successfully: {', '.join(files)}"