systems: optimize "Project (shared)" Claude Code configuration for network effect force multiplier

## The Force Multiplier Column 🎯

Based on the [Mastering Claude Code configuration matrix](https://www.youtube.com/live/6eBSHbLKuN0?t=989), the **"Project (shared)"** column is our most important configuration category for creating network effects across repositories.

**Why this column matters most:**
- **Shareable across repos**: Configuration travels with each project
- **Network effect**: Improvements in one repo benefit all repos
- **Force multiplier**: Each enhancement compounds across our entire project ecosystem
- **Team consistency**: Same configuration for all team members working on any project

## Current Project (Shared) Configuration State

| Category | File | Status | Network Effect Potential | Provider-Agnostic? |
|----------|------|--------|-------------------------|-------------------|
| **Memory** | `knowledge/` (via `--add-dir`) | ✅ **SOLVED ADVANCED** | 🎯 **Future-proof** - Provider-agnostic, auto-distributed | ✅ **YES** - Works with Claude, Cursor, Amazon Q, Copilot |
| **Slash Commands** | `commands/templates/` | ✅ **SOLVED ADVANCED** | 🎯 **Universal** - Provider-agnostic, symlinked distribution | ✅ **YES** - Universal templates, provider adapters |
| **Permissions** | `.claude/settings.json` | ⚠️ **Important Gap** | 🔧 **Enhancement Opportunity** - 137 lines exist, expansion possible | ❌ **NO** - Claude-specific format |
| **MCP Servers** | `.mcp.json` | ✅ **Strong** | ❓ **TBD** - Per-project config, reuse patterns unclear | ✅ **YES** - Standard protocol, multiple clients |

## Memory: Advanced Implementation ✅

**Current State**: We've solved memory MORE elegantly than the official approach.

**Our Advanced Approach:**
- **Provider-agnostic**: Single `knowledge/` system works across Claude, Cursor, Amazon Q, etc.
- **Auto-distributed**: `--add-dir knowledge/` pulls all principles/procedures into every context automatically
- **Zero maintenance**: No separate CLAUDE.md, .cursorrules.md files to sync
- **Compound improvements**: Updates to `knowledge/` immediately benefit all projects and providers
- **Ecosystem reality**: Teams using 60% Cursor, 20% Copilot, 20% Claude/Amazon Q - our unified approach serves all

**Potential Enhancement**: Fine-grained context inclusion headers (like other teams use) to save tokens on queries that don't need certain context.

## Slash Commands: Advanced Implementation ✅

**Current State**: We've solved commands MORE elegantly than provider-specific approaches.

**Our Advanced Approach:**
- **True source**: `commands/templates/` - human-readable, version-controlled
- **Provider distribution**: Symlinks to `.claude/commands/` (not the source of truth)
- **Universal patterns**: `close-issue` command used constantly across all projects
- **Future-proof**: Works regardless of AI provider evolution
- **Provider-agnostic**: Templates work across providers via generation/adaptation

**Current Issues**:
- **Unused commands**: `retro` command rarely/never used - should be removed
- **Provider confusion**: Sometimes editing symlinked `.claude/commands/` instead of source `commands/templates/`

## Permissions: Important Enhancement Opportunity 🔧

**Current State**: Global permissions working across repos via symlinks + substantial whitelist foundation.

**What's Working:**
- **Global symlink architecture**: `.claude/settings.json` → `~/.claude/settings.json` works as intended
- **Substantial foundation**: 137 lines of carefully curated permissions already exist
- **Cross-repo consistency**: Same permissions apply to all projects automatically
- **Network effect achieved**: Permission improvements benefit entire project ecosystem

**Provider Limitation**:
- **Claude-specific format**: `.claude/settings.json` only works with Claude Code
- **No universal standard**: Each provider has different permission systems
- **Migration complexity**: Would need translation layer for other providers

**Enhancement Opportunity**:
- Current whitelist covers core workflows but could be expanded for smoother agent orchestration
- Some workflows still require manual approvals that could be pre-authorized
- Consider dedicated spike for systematic permission expansion analysis

**Strategic Assessment**: The global config architecture is working correctly. This is an optimization opportunity, not a critical blocker.

## MCP Servers: Provider-Agnostic Success ✅

**Current State**: MCP (Model Context Protocol) is inherently provider-agnostic.

**Provider Support:**
- **Claude Code**: Native support via `.mcp.json`
- **Amazon Q**: Support via symlinked configuration
- **Cursor**: MCP support available
- **Others**: Growing ecosystem adoption

**Key Achievement**: Same MCP servers work across multiple AI providers without modification.

## The Achievement: Global Config Network Effect ✅

**Key Success**: We've achieved the primary goal - **global configuration that works across repositories**.

**Evidence**:
- Memory: ✅ Solved elegantly via provider-agnostic `knowledge/`
- Commands: ✅ Solved elegantly via universal `commands/templates/`
- Permissions: ✅ Global symlink architecture working + 137-line foundation (Claude-specific)
- MCP: ✅ Per-project configuration with reusable patterns (provider-agnostic)

**Provider-Agnostic Score**: 3/4 categories are fully provider-agnostic, with permissions being the only Claude-specific component.

**Force Multiplier Reality**: Configuration improvements in dotfiles automatically propagate to all projects.

## Strategic Focus: Document Success + Optimize

**Primary Goal**: Document the advanced implementation approaches we've achieved.

**Secondary Goal**: Identify targeted optimization opportunities (permissions expansion, unused command cleanup).

**Consider**: Breaking permissions expansion into its own spike for systematic analysis.

## Acceptance Criteria

- [ ] Document advanced memory approach (`--add-dir knowledge/` superiority)
- [ ] Document advanced commands approach (source truth in `commands/templates/`)
- [ ] Document global permissions architecture success (symlinks + 137-line foundation)
- [ ] Document provider-agnostic achievements (3/4 categories)
- [ ] Remove unused `retro` command
- [ ] Analyze MCP network effect potential
- [ ] **Consider**: Create separate spike for permissions expansion analysis
- [ ] **Consider**: Research provider-agnostic permission approaches
- [ ] Evidence of configuration network effect across project ecosystem

## Context

This issue celebrates achieving the core goal: **global configuration with network effects across repositories**. Memory, Commands, and Permissions all demonstrate working global config architecture. The remaining work is optimization and documentation of these advanced implementations.

**Key Insight**: 3 out of 4 configuration categories are fully provider-agnostic, demonstrating our commitment to future-proof architecture.

**Related**: Issue #903 (comprehensive matrix analysis - findings superseded by this advanced analysis)

## Labels

- systems
- claude-code
- force-multiplier
- network-effect
- enhancement
- documentation
- provider-agnostic

Read knowledge/, commands/templates/, .claude/settings.json, and .mcp.json to verify the current shared-configuration architecture. Document the four configuration categories and provider-agnostic findings, remove the unused retro command, analyze MCP reuse, and record whether permissions need a separate spike.

Written by the indexing model from the issue text.