Merge pull request #452 from Djelibeybi/add-oci-awareness

feat: Add OCI awareness across agents and skills

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -20,7 +20,7 @@ body:
       label: Preliminary Checks
       description: Please confirm you have completed these steps
       options:
-        - label: I have read the [Code of Conduct](.github/CODE_OF_CONDUCT.md)
+        - label: I have read the [Code of Conduct](https://github.com/wshobson/agents/blob/main/.github/CODE_OF_CONDUCT.md)
           required: true
         - label: >-
             I have searched existing issues to ensure this is not a duplicate

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -19,7 +19,7 @@ body:
       label: Preliminary Checks
       description: Please confirm you have completed these steps
       options:
-        - label: I have read the [Code of Conduct](.github/CODE_OF_CONDUCT.md)
+        - label: I have read the [Code of Conduct](https://github.com/wshobson/agents/blob/main/.github/CODE_OF_CONDUCT.md)
           required: true
         - label: >-
             I have searched existing issues to ensure this is not a duplicate

.github/ISSUE_TEMPLATE/new_subagent.yml

@@ -20,7 +20,7 @@ body:
       label: Preliminary Checks
       description: Please confirm you have completed these steps
       options:
-        - label: I have read the [Code of Conduct](.github/CODE_OF_CONDUCT.md)
+        - label: I have read the [Code of Conduct](https://github.com/wshobson/agents/blob/main/.github/CODE_OF_CONDUCT.md)
           required: true
         - label: >-
             I have reviewed existing subagents to ensure this is not a duplicate

Makefile

@@ -0,0 +1,120 @@
+# YouTube Design Extractor - Setup and Usage
+# ==========================================
+
+PYTHON := python3
+PIP := pip3
+SCRIPT := tools/yt-design-extractor.py
+
+.PHONY: help install install-ocr install-easyocr deps check run run-full run-ocr run-transcript clean
+
+help:
+	@echo "YouTube Design Extractor"
+	@echo "========================"
+	@echo ""
+	@echo "Setup (run in order):"
+	@echo "  make install-ocr     Install system tools (tesseract + ffmpeg)"
+	@echo "  make install         Install Python dependencies"
+	@echo "  make deps            Show what's installed"
+	@echo ""
+	@echo "Optional:"
+	@echo "  make install-easyocr Install EasyOCR + PyTorch (~2GB, for stylized text)"
+	@echo ""
+	@echo "Usage:"
+	@echo "  make run URL=<youtube-url>           Basic extraction"
+	@echo "  make run-full URL=<youtube-url>      Full extraction (OCR + colors + scene)"
+	@echo "  make run-ocr URL=<youtube-url>       With OCR only"
+	@echo "  make run-transcript URL=<youtube-url> Transcript + metadata only"
+	@echo ""
+	@echo "Examples:"
+	@echo "  make run URL='https://youtu.be/eVnQFWGDEdY'"
+	@echo "  make run-full URL='https://youtu.be/eVnQFWGDEdY' INTERVAL=15"
+	@echo ""
+	@echo "Options (pass as make variables):"
+	@echo "  URL=<url>          YouTube video URL (required)"
+	@echo "  INTERVAL=<secs>    Frame interval in seconds (default: 30)"
+	@echo "  OUTPUT=<dir>       Output directory"
+	@echo "  ENGINE=<engine>    OCR engine: tesseract (default) or easyocr"
+
+# Installation targets
+install:
+	$(PIP) install -r tools/requirements.txt
+
+install-ocr:
+	@echo "Installing Tesseract OCR + ffmpeg..."
+	@if command -v apt-get >/dev/null 2>&1; then \
+		sudo apt-get update && sudo apt-get install -y tesseract-ocr ffmpeg; \
+	elif command -v brew >/dev/null 2>&1; then \
+		brew install tesseract ffmpeg; \
+	elif command -v dnf >/dev/null 2>&1; then \
+		sudo dnf install -y tesseract ffmpeg; \
+	else \
+		echo "Please install tesseract-ocr and ffmpeg manually"; \
+		exit 1; \
+	fi
+
+install-easyocr:
+	@echo "Installing PyTorch (CPU) + EasyOCR (~2GB download)..."
+	$(PIP) install torch torchvision --index-url https://download.pytorch.org/whl/cpu
+	$(PIP) install easyocr
+
+deps:
+	@echo "Checking dependencies..."
+	@echo ""
+	@echo "System tools:"
+	@command -v ffmpeg >/dev/null 2>&1 && echo "  ✓ ffmpeg" || echo "  ✗ ffmpeg (run: make install-ocr)"
+	@command -v tesseract >/dev/null 2>&1 && echo "  ✓ tesseract" || echo "  ✗ tesseract (run: make install-ocr)"
+	@echo ""
+	@echo "Python packages (required):"
+	@$(PYTHON) -c "import yt_dlp; print('  ✓ yt-dlp', yt_dlp.version.__version__)" 2>/dev/null || echo "  ✗ yt-dlp (run: make install)"
+	@$(PYTHON) -c "from youtube_transcript_api import YouTubeTranscriptApi; print('  ✓ youtube-transcript-api')" 2>/dev/null || echo "  ✗ youtube-transcript-api (run: make install)"
+	@$(PYTHON) -c "from PIL import Image; print('  ✓ Pillow')" 2>/dev/null || echo "  ✗ Pillow (run: make install)"
+	@$(PYTHON) -c "import pytesseract; print('  ✓ pytesseract')" 2>/dev/null || echo "  ✗ pytesseract (run: make install)"
+	@$(PYTHON) -c "from colorthief import ColorThief; print('  ✓ colorthief')" 2>/dev/null || echo "  ✗ colorthief (run: make install)"
+	@echo ""
+	@echo "Optional (for stylized text OCR):"
+	@$(PYTHON) -c "import easyocr; print('  ✓ easyocr')" 2>/dev/null || echo "  ○ easyocr (run: make install-easyocr)"
+
+check:
+	@$(PYTHON) $(SCRIPT) --help >/dev/null && echo "✓ Script is working" || echo "✗ Script failed"
+
+# Run targets
+INTERVAL ?= 30
+ENGINE ?= tesseract
+OUTPUT ?=
+
+run:
+ifndef URL
+	@echo "Error: URL is required"
+	@echo "Usage: make run URL='https://youtu.be/VIDEO_ID'"
+	@exit 1
+endif
+	$(PYTHON) $(SCRIPT) "$(URL)" --interval $(INTERVAL) $(if $(OUTPUT),-o $(OUTPUT))
+
+run-full:
+ifndef URL
+	@echo "Error: URL is required"
+	@echo "Usage: make run-full URL='https://youtu.be/VIDEO_ID'"
+	@exit 1
+endif
+	$(PYTHON) $(SCRIPT) "$(URL)" --full --interval $(INTERVAL) --ocr-engine $(ENGINE) $(if $(OUTPUT),-o $(OUTPUT))
+
+run-ocr:
+ifndef URL
+	@echo "Error: URL is required"
+	@echo "Usage: make run-ocr URL='https://youtu.be/VIDEO_ID'"
+	@exit 1
+endif
+	$(PYTHON) $(SCRIPT) "$(URL)" --ocr --interval $(INTERVAL) --ocr-engine $(ENGINE) $(if $(OUTPUT),-o $(OUTPUT))
+
+run-transcript:
+ifndef URL
+	@echo "Error: URL is required"
+	@echo "Usage: make run-transcript URL='https://youtu.be/VIDEO_ID'"
+	@exit 1
+endif
+	$(PYTHON) $(SCRIPT) "$(URL)" --transcript-only $(if $(OUTPUT),-o $(OUTPUT))
+
+# Cleanup
+clean:
+	rm -rf yt-extract-*
+	@echo "Cleaned up extraction directories"

README.md

@@ -1,29 +1,29 @@
 # Claude Code Plugins: Orchestration and Automation
 
-> **⚡ Updated for Opus 4.5, Sonnet 4.5 & Haiku 4.5** — Three-tier model strategy for optimal performance
+> **⚡ Updated for Opus 4.6, Sonnet 4.6 & Haiku 4.5** — Three-tier model strategy for optimal performance
 
 [![Run in Smithery](https://smithery.ai/badge/skills/wshobson)](https://smithery.ai/skills?ns=wshobson&utm_source=github&utm_medium=badge)
 
-> **🎯 Agent Skills Enabled** — 129 specialized skills extend Claude's capabilities across plugins with progressive disclosure
+> **🎯 Agent Skills Enabled** — 146 specialized skills extend Claude's capabilities across plugins with progressive disclosure
 
-A comprehensive production-ready system combining **108 specialized AI agents**, **15 multi-agent workflow orchestrators**, **129 agent skills**, and **72 development tools** organized into **72 focused, single-purpose plugins** for [Claude Code](https://docs.claude.com/en/docs/claude-code/overview).
+A comprehensive production-ready system combining **112 specialized AI agents**, **16 multi-agent workflow orchestrators**, **146 agent skills**, and **79 development tools** organized into **72 focused, single-purpose plugins** for [Claude Code](https://docs.claude.com/en/docs/claude-code/overview).
 
 ## Overview
 
 This unified repository provides everything needed for intelligent automation and multi-agent orchestration across modern software development:
 
 - **72 Focused Plugins** - Granular, single-purpose plugins optimized for minimal token usage and composability
-- **108 Specialized Agents** - Domain experts with deep knowledge across architecture, languages, infrastructure, quality, data/AI, documentation, business operations, and SEO
-- **129 Agent Skills** - Modular knowledge packages with progressive disclosure for specialized expertise
-- **15 Workflow Orchestrators** - Multi-agent coordination systems for complex operations like full-stack development, security hardening, ML pipelines, and incident response
-- **72 Development Tools** - Optimized utilities including project scaffolding, security scanning, test automation, and infrastructure setup
+- **112 Specialized Agents** - Domain experts with deep knowledge across architecture, languages, infrastructure, quality, data/AI, documentation, business operations, and SEO
+- **146 Agent Skills** - Modular knowledge packages with progressive disclosure for specialized expertise
+- **16 Workflow Orchestrators** - Multi-agent coordination systems for complex operations like full-stack development, security hardening, ML pipelines, and incident response
+- **79 Development Tools** - Optimized utilities including project scaffolding, security scanning, test automation, and infrastructure setup
 
 ### Key Features
 
 - **Granular Plugin Architecture**: 72 focused plugins optimized for minimal token usage
-- **Comprehensive Tooling**: 72 development tools including test generation, scaffolding, and security scanning
+- **Comprehensive Tooling**: 79 development tools including test generation, scaffolding, and security scanning
 - **100% Agent Coverage**: All plugins include specialized agents
-- **Agent Skills**: 129 specialized skills following for progressive disclosure and token efficiency
+- **Agent Skills**: 146 specialized skills following for progressive disclosure and token efficiency
 - **Clear Organization**: 23 categories with 1-6 plugins each for easy discovery
 - **Efficient Design**: Average 3.4 components per plugin (follows Anthropic's 2-8 pattern)
 
@@ -73,7 +73,7 @@ Install the plugins you need:
 
 # Security & quality
 /plugin install security-scanning           # SAST with security skill
-/plugin install code-review-ai             # AI-powered code review
+/plugin install comprehensive-review       # Multi-perspective code analysis
 
 # Full-stack orchestration
 /plugin install full-stack-orchestration   # Multi-agent workflows
@@ -115,8 +115,8 @@ rm -rf ~/.claude/plugins/cache/claude-code-workflows && rm ~/.claude/plugins/ins
 ### Core Guides
 
 - **[Plugin Reference](docs/plugins.md)** - Complete catalog of all 72 plugins
-- **[Agent Reference](docs/agents.md)** - All 108 agents organized by category
-- **[Agent Skills](docs/agent-skills.md)** - 129 specialized skills with progressive disclosure
+- **[Agent Reference](docs/agents.md)** - All 112 agents organized by category
+- **[Agent Skills](docs/agent-skills.md)** - 146 specialized skills with progressive disclosure
 - **[Usage Guide](docs/usage.md)** - Commands, workflows, and best practices
 - **[Architecture](docs/architecture.md)** - Design principles and patterns
 
@@ -130,7 +130,44 @@ rm -rf ~/.claude/plugins/cache/claude-code-workflows && rm ~/.claude/plugins/ins
 
 ## What's New
 
-### Agent Skills (140 skills across 20 plugins)
+### Agent Teams Plugin (NEW)
+
+Orchestrate multi-agent teams for parallel workflows using Claude Code's experimental Agent Teams feature:
+
+```bash
+/plugin install agent-teams@claude-code-workflows
+```
+
+- **7 Team Presets** — `review`, `debug`, `feature`, `fullstack`, `research`, `security`, `migration`
+- **Parallel Code Review** — `/team-review src/ --reviewers security,performance,architecture`
+- **Hypothesis-Driven Debugging** — `/team-debug "API returns 500" --hypotheses 3`
+- **Parallel Feature Development** — `/team-feature "Add OAuth2 auth" --plan-first`
+- **Research Teams** — Parallel investigation across codebase and web sources
+- **Security Audits** — 4 reviewers covering OWASP, auth, dependencies, and secrets
+- **Migration Support** — Coordinated migration with parallel streams and correctness verification
+
+Includes 4 specialized agents, 7 commands, and 6 skills with reference documentation.
+
+[→ View agent-teams documentation](plugins/agent-teams/README.md)
+
+### Conductor Plugin — Context-Driven Development
+
+Transforms Claude Code into a project management tool with a structured **Context → Spec & Plan → Implement** workflow:
+
+```bash
+/plugin install conductor@claude-code-workflows
+```
+
+- **Interactive Setup** — `/conductor:setup` creates product vision, tech stack, workflow rules, and style guides
+- **Track-Based Development** — `/conductor:new-track` generates specifications and phased implementation plans
+- **TDD Workflow** — `/conductor:implement` executes tasks with verification checkpoints
+- **Semantic Revert** — `/conductor:revert` undoes work by logical unit (track, phase, or task)
+- **State Persistence** — Resume setup across sessions with persistent project context
+- **3 Skills** — Context-driven development, track management, workflow patterns
+
+[→ View Conductor documentation](plugins/conductor/README.md)
+
+### Agent Skills (146 skills across 21 plugins)
 
 Specialized knowledge packages following Anthropic's progressive disclosure architecture:
 
@@ -166,14 +203,14 @@ Strategic model assignment for optimal performance and cost:
 
 | Tier       | Model    | Agents | Use Case                                                                                        |
 | ---------- | -------- | ------ | ----------------------------------------------------------------------------------------------- |
-| **Tier 1** | Opus 4.5 | 42     | Critical architecture, security, ALL code review, production coding (language pros, frameworks) |
+| **Tier 1** | Opus 4.6 | 42     | Critical architecture, security, ALL code review, production coding (language pros, frameworks) |
 | **Tier 2** | Inherit  | 42     | Complex tasks - user chooses model (AI/ML, backend, frontend/mobile, specialized)               |
 | **Tier 3** | Sonnet   | 51     | Support with intelligence (docs, testing, debugging, network, API docs, DX, legacy, payments)   |
 | **Tier 4** | Haiku    | 18     | Fast operational tasks (SEO, deployment, simple docs, sales, content, search)                   |
 
-**Why Opus 4.5 for Critical Agents?**
+**Why Opus 4.6 for Critical Agents?**
 
-- 80.9% on SWE-bench (industry-leading)
+- 80.8% on SWE-bench (industry-leading)
 - 65% fewer tokens for complex tasks
 - Best for architecture decisions and security audits
 
@@ -181,14 +218,14 @@ Strategic model assignment for optimal performance and cost:
 Agents marked `inherit` use your session's default model, letting you balance cost and capability:
 
 - Set via `claude --model opus` or `claude --model sonnet` when starting a session
-- Falls back to Sonnet 4.5 if no default specified
+- Falls back to Sonnet 4.6 if no default specified
 - Perfect for frontend/mobile developers who want cost control
 - AI/ML engineers can choose Opus for complex model work
 
 **Cost Considerations:**
 
-- **Opus 4.5**: $5/$25 per million input/output tokens - Premium for critical work
-- **Sonnet 4.5**: $3/$15 per million tokens - Balanced performance/cost
+- **Opus 4.6**: $5/$25 per million input/output tokens - Premium for critical work
+- **Sonnet 4.6**: $3/$15 per million tokens - Balanced performance/cost
 - **Haiku 4.5**: $1/$5 per million tokens - Fast, cost-effective operations
 - Opus's 65% token reduction on complex tasks often offsets higher rate
 - Use `inherit` tier to control costs for high-volume use cases
@@ -246,13 +283,13 @@ Uses kubernetes-architect agent with 4 specialized skills for production-grade c
 
 ## Plugin Categories
 
-**23 categories, 72 plugins:**
+**24 categories, 72 plugins:**
 
 - 🎨 **Development** (4) - debugging, backend, frontend, multi-platform
 - 📚 **Documentation** (3) - code docs, API specs, diagrams, C4 architecture
-- 🔄 **Workflows** (4) - git, full-stack, TDD, **Conductor** (context-driven development)
+- 🔄 **Workflows** (5) - git, full-stack, TDD, **Conductor** (context-driven development), **Agent Teams** (multi-agent orchestration)
 - ✅ **Testing** (2) - unit testing, TDD workflows
-- 🔍 **Quality** (3) - code review, comprehensive review, performance
+- 🔍 **Quality** (2) - comprehensive review, performance
 - 🤖 **AI & ML** (4) - LLM apps, agent orchestration, context, MLOps
 - 📊 **Data** (2) - data engineering, data validation
 - 🗄️ **Database** (2) - database design, migrations
@@ -278,7 +315,7 @@ Uses kubernetes-architect agent with 4 specialized skills for production-grade c
 - **Single responsibility** - Each plugin does one thing well
 - **Minimal token usage** - Average 3.4 components per plugin
 - **Composable** - Mix and match for complex workflows
-- **100% coverage** - All 108 agents accessible across plugins
+- **100% coverage** - All 112 agents accessible across plugins
 
 ### Progressive Disclosure (Skills)
 

docs/architecture.md

@@ -334,7 +334,7 @@ Feature Development Workflow:
 1. backend-development:feature-development
 2. security-scanning:security-hardening
 3. unit-testing:test-generate
-4. code-review-ai:ai-review
+4. comprehensive-review:full-review
 5. cicd-automation:workflow-automate
 6. observability-monitoring:monitor-setup
 ```

docs/plugins.md

@@ -1,6 +1,6 @@
 # Complete Plugin Reference
 
-Browse all **72 focused, single-purpose plugins** organized by category.
+Browse all **71 focused, single-purpose plugins** organized by category.
 
 ## Quick Start - Essential Plugins
 
@@ -68,14 +68,6 @@ Multi-agent coordination from backend → frontend → testing → security →
 
 Generate pytest (Python) and Jest (JavaScript) unit tests automatically with comprehensive edge case coverage.
 
-**code-review-ai** - AI-powered code review
-
-```bash
-/plugin install code-review-ai
-```
-
-Architectural analysis, security assessment, and code quality review with actionable feedback.
-
 ### Infrastructure & Operations
 
 **cloud-infrastructure** - Cloud architecture design
@@ -150,11 +142,10 @@ Next.js, React + Vite, and Node.js project setup with pnpm and TypeScript best p
 | **unit-testing**  | Automated unit test generation (Python/JavaScript) | `/plugin install unit-testing`  |
 | **tdd-workflows** | Test-driven development methodology                | `/plugin install tdd-workflows` |
 
-### 🔍 Quality (3 plugins)
+### 🔍 Quality (2 plugins)
 
 | Plugin                         | Description                                   | Install                                      |
 | ------------------------------ | --------------------------------------------- | -------------------------------------------- |
-| **code-review-ai**             | AI-powered architectural review               | `/plugin install code-review-ai`             |
 | **comprehensive-review**       | Multi-perspective code analysis               | `/plugin install comprehensive-review`       |
 | **performance-testing-review** | Performance analysis and test coverage review | `/plugin install performance-testing-review` |
 

docs/usage.md

@@ -70,7 +70,6 @@ Claude Code automatically selects and coordinates the appropriate agents based o
 
 | Command                             | Description                |
 | ----------------------------------- | -------------------------- |
-| `/code-review-ai:ai-review`         | AI-powered code review     |
 | `/comprehensive-review:full-review` | Multi-perspective analysis |
 | `/comprehensive-review:pr-enhance`  | Enhance pull requests      |
 
@@ -361,7 +360,7 @@ Compose multiple plugins for complex scenarios:
 /unit-testing:test-generate
 
 # 4. Review the implementation
-/code-review-ai:ai-review
+/comprehensive-review:full-review
 
 # 5. Set up CI/CD
 /cicd-automation:workflow-automate

plugins/accessibility-compliance/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "accessibility-compliance",
+  "version": "1.2.2",
+  "description": "WCAG accessibility auditing, compliance validation, UI testing for screen readers, keyboard navigation, and inclusive design",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/accessibility-compliance/skills/screen-reader-testing/SKILL.md

@@ -536,10 +536,3 @@ function logAccessibleName(element) {
 - **Don't test only happy path** - Test error states
 - **Don't skip dynamic content** - Most common issues
 - **Don't rely on visual testing** - Different experience
-
-## Resources
-
-- [VoiceOver User Guide](https://support.apple.com/guide/voiceover/welcome/mac)
-- [NVDA User Guide](https://www.nvaccess.org/files/nvda/documentation/userGuide.html)
-- [JAWS Documentation](https://support.freedomscientific.com/Products/Blindness/JAWS)
-- [WebAIM Screen Reader Survey](https://webaim.org/projects/screenreadersurvey/)

plugins/accessibility-compliance/skills/wcag-audit-patterns/SKILL.md

@@ -546,10 +546,3 @@ class AccessibleDropdown extends HTMLElement {
 - **Don't hide focus outlines** - Keyboard users need them
 - **Don't disable zoom** - Users need to resize
 - **Don't use color alone** - Multiple indicators needed
-
-## Resources
-
-- [WCAG 2.2 Guidelines](https://www.w3.org/TR/WCAG22/)
-- [WebAIM](https://webaim.org/)
-- [A11y Project Checklist](https://www.a11yproject.com/checklist/)
-- [axe DevTools](https://www.deque.com/axe/)

plugins/agent-orchestration/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "agent-orchestration",
+  "version": "1.2.1",
+  "description": "Multi-agent system optimization, agent improvement workflows, and context management",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/agent-orchestration/commands/multi-agent-optimize.md

@@ -146,7 +146,7 @@ class CostOptimizer:
         self.token_budget = 100000  # Monthly budget
         self.token_usage = 0
         self.model_costs = {
-            'gpt-5': 0.03,
+            'gpt-5.2': 0.03,
             'claude-4-sonnet': 0.015,
             'claude-4-haiku': 0.0025
         }

plugins/agent-teams/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "agent-teams",
+  "version": "1.0.2",
+  "description": "Orchestrate multi-agent teams for parallel code review, hypothesis-driven debugging, and coordinated feature development using Claude Code's Agent Teams",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/agent-teams/README.md

@@ -0,0 +1,153 @@
+# Agent Teams Plugin
+
+Orchestrate multi-agent teams for parallel code review, hypothesis-driven debugging, and coordinated feature development using Claude Code's experimental [Agent Teams](https://code.claude.com/docs/en/agent-teams) feature.
+
+## Setup
+
+### Prerequisites
+
+1. Enable the experimental Agent Teams feature:
+
+```bash
+export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
+```
+
+2. Configure teammate display mode in your `~/.claude/settings.json`:
+
+```json
+{
+  "teammateMode": "tmux"
+}
+```
+
+Available display modes:
+
+- `"tmux"` — Each teammate runs in a tmux pane (recommended)
+- `"iterm2"` — Each teammate gets an iTerm2 tab (macOS only)
+- `"in-process"` — Teammates run in the same process (default)
+
+### Installation
+
+First, add the marketplace (if you haven't already):
+
+```
+/plugin marketplace add wshobson/agents
+```
+
+Then install the plugin:
+
+```
+/plugin install agent-teams@claude-code-workflows
+```
+
+## Features
+
+- **Preset Teams** — Spawn pre-configured teams for common workflows (review, debug, feature, fullstack, research, security, migration)
+- **Multi-Reviewer Code Review** — Parallel review across security, performance, architecture, testing, and accessibility dimensions
+- **Hypothesis-Driven Debugging** — Competing hypothesis investigation with evidence-based root cause analysis
+- **Parallel Feature Development** — Coordinated multi-agent implementation with file ownership boundaries
+- **Parallel Research** — Multiple Explore agents investigating different questions or codebase areas simultaneously
+- **Security Audit** — Comprehensive parallel security review across OWASP, auth, dependencies, and configuration
+- **Migration Support** — Coordinated codebase migration with parallel implementation streams and correctness verification
+- **Task Coordination** — Dependency-aware task management with workload balancing
+- **Team Communication** — Structured messaging protocols for efficient agent collaboration
+
+## Commands
+
+| Command          | Description                                                |
+| ---------------- | ---------------------------------------------------------- |
+| `/team-spawn`    | Spawn a team using presets or custom composition           |
+| `/team-status`   | Display team members, tasks, and progress                  |
+| `/team-shutdown` | Gracefully shut down a team and clean up resources         |
+| `/team-review`   | Multi-reviewer parallel code review                        |
+| `/team-debug`    | Competing hypotheses debugging with parallel investigation |
+| `/team-feature`  | Parallel feature development with file ownership           |
+| `/team-delegate` | Task delegation dashboard and workload management          |
+
+## Agents
+
+| Agent              | Role                                                                              | Color  |
+| ------------------ | --------------------------------------------------------------------------------- | ------ |
+| `team-lead`        | Team orchestrator — decomposes work, manages lifecycle, synthesizes results       | Blue   |
+| `team-reviewer`    | Multi-dimensional code reviewer — operates on assigned review dimension           | Green  |
+| `team-debugger`    | Hypothesis investigator — gathers evidence to confirm/falsify assigned hypothesis | Red    |
+| `team-implementer` | Parallel builder — implements within strict file ownership boundaries             | Yellow |
+
+## Skills
+
+| Skill                          | Description                                                              |
+| ------------------------------ | ------------------------------------------------------------------------ |
+| `team-composition-patterns`    | Team sizing heuristics, preset compositions, agent type selection        |
+| `task-coordination-strategies` | Task decomposition, dependency graphs, workload monitoring               |
+| `parallel-debugging`           | Hypothesis generation, evidence collection, result arbitration           |
+| `multi-reviewer-patterns`      | Review dimension allocation, finding deduplication, severity calibration |
+| `parallel-feature-development` | File ownership strategies, conflict avoidance, integration patterns      |
+| `team-communication-protocols` | Message type selection, plan approval workflow, shutdown protocol        |
+
+## Quick Start
+
+### Multi-Reviewer Code Review
+
+```
+/team-review src/ --reviewers security,performance,architecture
+```
+
+Spawns 3 reviewers, each analyzing the codebase from their assigned dimension, then consolidates findings into a prioritized report.
+
+### Hypothesis-Driven Debugging
+
+```
+/team-debug "API returns 500 on POST /users with valid payload" --hypotheses 3
+```
+
+Generates 3 competing hypotheses, spawns investigators for each, collects evidence, and presents the most likely root cause with a fix.
+
+### Parallel Feature Development
+
+```
+/team-feature "Add user authentication with OAuth2" --team-size 3 --plan-first
+```
+
+Decomposes the feature into work streams with file ownership boundaries, gets your approval, then spawns implementers to build in parallel.
+
+### Parallel Research
+
+```
+/team-spawn research --name codebase-research
+```
+
+Spawns 3 researchers to investigate different aspects in parallel — across your codebase (Grep/Read) and the web (WebSearch/WebFetch). Each reports findings with citations.
+
+### Security Audit
+
+```
+/team-spawn security
+```
+
+Spawns 4 security reviewers covering OWASP vulnerabilities, auth/access control, dependency supply chain, and secrets/configuration. Produces a consolidated security report.
+
+### Codebase Migration
+
+```
+/team-spawn migration --name react-hooks-migration
+```
+
+Spawns a lead to plan the migration, 2 implementers to migrate code in parallel streams, and a reviewer to verify correctness of the migrated code.
+
+### Custom Team
+
+```
+/team-spawn custom --name my-team --members 4
+```
+
+Interactively configure team composition with custom roles and agent types.
+
+## Best Practices
+
+1. **Start with presets** — Use `/team-spawn review`, `/team-spawn debug`, or `/team-spawn feature` before building custom teams
+2. **Use `--plan-first`** — For feature development, always review the decomposition before spawning implementers
+3. **File ownership is critical** — Never assign the same file to multiple implementers; use interface contracts at boundaries
+4. **Monitor with `/team-status`** — Check progress regularly and use `/team-delegate --rebalance` if work is uneven
+5. **Graceful shutdown** — Always use `/team-shutdown` rather than killing processes manually
+6. **Keep teams small** — 2-4 teammates is optimal; larger teams increase coordination overhead
+7. **Use Shift+Tab** — Claude Code's built-in delegate mode (Shift+Tab) complements these commands for ad-hoc delegation

plugins/agent-teams/agents/team-debugger.md

@@ -0,0 +1,83 @@
+---
+name: team-debugger
+description: Hypothesis-driven debugging investigator that investigates one assigned hypothesis, gathering evidence to confirm or falsify it with file:line citations and confidence levels. Use when debugging complex issues with multiple potential root causes.
+tools: Read, Glob, Grep, Bash
+model: opus
+color: red
+---
+
+You are a hypothesis-driven debugging investigator. You are assigned one specific hypothesis about a bug's root cause and must gather evidence to confirm or falsify it.
+
+## Core Mission
+
+Investigate your assigned hypothesis systematically. Collect concrete evidence from the codebase, logs, and runtime behavior. Report your findings with confidence levels and causal chains so the team lead can compare hypotheses and determine the true root cause.
+
+## Investigation Protocol
+
+### Step 1: Understand the Hypothesis
+
+- Parse the assigned hypothesis statement
+- Identify what would need to be true for this hypothesis to be correct
+- List the observable consequences if this hypothesis is the root cause
+
+### Step 2: Define Evidence Criteria
+
+- What evidence would CONFIRM this hypothesis? (necessary conditions)
+- What evidence would FALSIFY this hypothesis? (contradicting observations)
+- What evidence would be AMBIGUOUS? (consistent with multiple hypotheses)
+
+### Step 3: Gather Primary Evidence
+
+- Search for the specific code paths, data flows, or configurations implied by the hypothesis
+- Read relevant source files and trace execution paths
+- Check git history for recent changes in suspected areas
+
+### Step 4: Gather Supporting Evidence
+
+- Look for related error messages, log patterns, or stack traces
+- Check for similar bugs in the codebase or issue tracker
+- Examine test coverage for the suspected area
+
+### Step 5: Test the Hypothesis
+
+- If possible, construct a minimal reproduction scenario
+- Identify the exact conditions under which the hypothesis predicts failure
+- Check if those conditions match the reported behavior
+
+### Step 6: Assess Confidence
+
+- Rate confidence: High (>80%), Medium (50-80%), Low (<50%)
+- List confirming evidence with file:line citations
+- List contradicting evidence with file:line citations
+- Note any gaps in evidence that prevent higher confidence
+
+### Step 7: Report Findings
+
+- Deliver structured report to team lead
+- Include causal chain if hypothesis is confirmed
+- Suggest specific fix if root cause is established
+- Recommend additional investigation if confidence is low
+
+## Evidence Standards
+
+1. **Always cite file:line** — Every claim must reference a specific location in the codebase
+2. **Show the causal chain** — Connect the hypothesis to the symptom through a chain of cause and effect
+3. **Report confidence honestly** — Do not overstate certainty; distinguish confirmed from suspected
+4. **Include contradicting evidence** — Report evidence that weakens your hypothesis, not just evidence that supports it
+5. **Scope your claims** — Be precise about what you've verified vs what you're inferring
+
+## Scope Discipline
+
+- Stay focused on your assigned hypothesis — do not investigate other potential causes
+- If you discover evidence pointing to a different root cause, report it but do not change your investigation focus
+- Do not propose fixes for issues outside your hypothesis scope
+- Communicate scope concerns to the team lead via message
+
+## Behavioral Traits
+
+- Methodical and evidence-driven — never jumps to conclusions
+- Honest about uncertainty — reports low confidence when evidence is insufficient
+- Focused on assigned hypothesis — resists the urge to chase tangential leads
+- Cites every claim with specific file:line references
+- Distinguishes correlation from causation
+- Reports negative results (falsified hypotheses) as valuable findings

plugins/agent-teams/agents/team-implementer.md

@@ -0,0 +1,85 @@
+---
+name: team-implementer
+description: Parallel feature builder that implements components within strict file ownership boundaries, coordinating at integration points via messaging. Use when building features in parallel across multiple agents with file ownership coordination.
+tools: Read, Write, Edit, Glob, Grep, Bash
+model: opus
+color: yellow
+---
+
+You are a parallel feature builder. You implement components within your assigned file ownership boundaries, coordinating with other implementers at integration points.
+
+## Core Mission
+
+Build your assigned component or feature slice within strict file ownership boundaries. Write clean, tested code that integrates with other teammates' work through well-defined interfaces. Communicate proactively at integration points.
+
+## File Ownership Protocol
+
+1. **Only modify files assigned to you** — Check your task description for the explicit list of owned files/directories
+2. **Never touch shared files** — If you need changes to a shared file, message the team lead
+3. **Create new files only within your ownership boundary** — New files in your assigned directories are fine
+4. **Interface contracts are immutable** — Do not change agreed-upon interfaces without team lead approval
+5. **If in doubt, ask** — Message the team lead before touching any file not explicitly in your ownership list
+
+## Implementation Workflow
+
+### Phase 1: Understand Assignment
+
+- Read your task description thoroughly
+- Identify owned files and directories
+- Review interface contracts with adjacent components
+- Understand acceptance criteria
+
+### Phase 2: Plan Implementation
+
+- Design your component's internal architecture
+- Identify integration points with other teammates' components
+- Plan your implementation sequence (dependencies first)
+- Note any blockers or questions for the team lead
+
+### Phase 3: Build
+
+- Implement core functionality within owned files
+- Follow existing codebase patterns and conventions
+- Write code that satisfies the interface contracts
+- Keep changes minimal and focused
+
+### Phase 4: Verify
+
+- Ensure your code compiles/passes linting
+- Test integration points match the agreed interfaces
+- Verify acceptance criteria are met
+- Run any applicable tests
+
+### Phase 5: Report
+
+- Mark your task as completed via TaskUpdate
+- Message the team lead with a summary of changes
+- Note any integration concerns for other teammates
+- Flag any deviations from the original plan
+
+## Integration Points
+
+When your component interfaces with another teammate's component:
+
+1. **Reference the contract** — Use the types/interfaces defined in the shared contract
+2. **Don't implement their side** — Stub or mock their component during development
+3. **Message on completion** — Notify the teammate when your side of the interface is ready
+4. **Report mismatches** — If the contract seems wrong or incomplete, message the team lead immediately
+
+## Quality Standards
+
+- Match existing codebase style and patterns
+- Keep changes minimal — implement exactly what's specified
+- No scope creep — if you see improvements outside your assignment, note them but don't implement
+- Prefer simple, readable code over clever solutions
+- Preserve existing comments and formatting in modified files
+- Ensure your code works with the existing build system
+
+## Behavioral Traits
+
+- Respects file ownership boundaries absolutely — never modifies unassigned files
+- Communicates proactively at integration points
+- Asks for clarification rather than making assumptions about unclear requirements
+- Reports blockers immediately rather than trying to work around them
+- Focuses on assigned work — does not refactor or improve code outside scope
+- Delivers working code that satisfies the interface contract

plugins/agent-teams/agents/team-lead.md

@@ -0,0 +1,91 @@
+---
+name: team-lead
+description: Team orchestrator that decomposes work into parallel tasks with file ownership boundaries, manages team lifecycle, and synthesizes results. Use when coordinating multi-agent teams, decomposing complex tasks, or managing parallel workstreams.
+tools: Read, Glob, Grep, Bash
+model: opus
+color: blue
+---
+
+You are an expert team orchestrator specializing in decomposing complex software engineering tasks into parallel workstreams with clear ownership boundaries.
+
+## Core Mission
+
+Lead multi-agent teams through structured workflows: analyze requirements, decompose work into independent tasks with file ownership, spawn and coordinate teammates, monitor progress, synthesize results, and manage graceful shutdown.
+
+## Capabilities
+
+### Team Composition
+
+- Select optimal team size based on task complexity (2-5 teammates)
+- Choose appropriate agent types for each role (read-only vs full-capability)
+- Match preset team compositions to workflow requirements
+- Configure display modes (tmux, iTerm2, in-process)
+
+### Task Decomposition
+
+- Break complex tasks into independent, parallelizable work units
+- Define clear acceptance criteria for each task
+- Estimate relative complexity to balance workloads
+- Identify shared dependencies and integration points
+
+### File Ownership Management
+
+- Assign exclusive file ownership to each teammate
+- Define interface contracts at ownership boundaries
+- Prevent conflicts by ensuring no file has multiple owners
+- Create shared type definitions or interfaces when teammates need coordination
+
+### Dependency Management
+
+- Build dependency graphs using blockedBy/blocks relationships
+- Minimize dependency chain depth to maximize parallelism
+- Identify and resolve circular dependencies
+- Sequence tasks along the critical path
+
+### Result Synthesis
+
+- Collect and merge outputs from all teammates
+- Resolve conflicting findings or recommendations
+- Generate consolidated reports with clear prioritization
+- Identify gaps in coverage across teammate outputs
+
+### Conflict Resolution
+
+- Detect overlapping file modifications across teammates
+- Mediate disagreements in approach or findings
+- Establish tiebreaking criteria for conflicting recommendations
+- Ensure consistency across parallel workstreams
+
+## File Ownership Rules
+
+1. **One owner per file** — Never assign the same file to multiple teammates
+2. **Explicit boundaries** — List owned files/directories in each task description
+3. **Interface contracts** — When teammates share boundaries, define the contract (types, APIs) before work begins
+4. **Shared files** — If a file must be touched by multiple teammates, the lead owns it and applies changes sequentially
+
+## Communication Protocols
+
+1. Use `message` for direct teammate communication (default)
+2. Use `broadcast` only for critical team-wide announcements
+3. Never send structured JSON status messages — use TaskUpdate instead
+4. Read team config from `~/.claude/teams/{team-name}/config.json` for teammate discovery
+5. Refer to teammates by NAME, never by UUID
+
+## Team Lifecycle Protocol
+
+1. **Spawn** — Create team with Teammate tool, spawn teammates with Task tool
+2. **Assign** — Create tasks with TaskCreate, assign with TaskUpdate
+3. **Monitor** — Check TaskList periodically, respond to teammate messages
+4. **Collect** — Gather results as teammates complete tasks
+5. **Synthesize** — Merge results into consolidated output
+6. **Shutdown** — Send shutdown_request to each teammate, wait for responses
+7. **Cleanup** — Call Teammate cleanup to remove team resources
+
+## Behavioral Traits
+
+- Decomposes before delegating — never assigns vague or overlapping tasks
+- Monitors progress without micromanaging — checks in at milestones, not every step
+- Synthesizes results with clear attribution to source teammates
+- Escalates blockers to the user promptly rather than letting teammates spin
+- Maintains a bias toward smaller teams with clearer ownership
+- Communicates task boundaries and expectations upfront

plugins/agent-teams/agents/team-reviewer.md

@@ -0,0 +1,102 @@
+---
+name: team-reviewer
+description: Multi-dimensional code reviewer that operates on one assigned review dimension (security, performance, architecture, testing, or accessibility) with structured finding format. Use when performing parallel code reviews across multiple quality dimensions.
+tools: Read, Glob, Grep, Bash
+model: opus
+color: green
+---
+
+You are a specialized code reviewer focused on one assigned review dimension, producing structured findings with file:line citations, severity ratings, and actionable fixes.
+
+## Core Mission
+
+Perform deep, focused code review on your assigned dimension. Produce findings in a consistent structured format that can be merged with findings from other reviewers into a consolidated report.
+
+## Review Dimensions
+
+### Security
+
+- Input validation and sanitization
+- Authentication and authorization checks
+- SQL injection, XSS, CSRF vulnerabilities
+- Secrets and credential exposure
+- Dependency vulnerabilities (known CVEs)
+- Insecure cryptographic usage
+- Access control bypass vectors
+- API security (rate limiting, input bounds)
+
+### Performance
+
+- Database query efficiency (N+1, missing indexes, full scans)
+- Memory allocation patterns and potential leaks
+- Unnecessary computation or redundant operations
+- Caching opportunities and cache invalidation
+- Async/concurrent programming correctness
+- Resource cleanup and connection management
+- Algorithm complexity (time and space)
+- Bundle size and lazy loading opportunities
+
+### Architecture
+
+- SOLID principle adherence
+- Separation of concerns and layer boundaries
+- Dependency direction and circular dependencies
+- API contract design and versioning
+- Error handling strategy consistency
+- Configuration management patterns
+- Abstraction appropriateness (over/under-engineering)
+- Module cohesion and coupling analysis
+
+### Testing
+
+- Test coverage gaps for critical paths
+- Test isolation and determinism
+- Mock/stub appropriateness and accuracy
+- Edge case and boundary condition coverage
+- Integration test completeness
+- Test naming and documentation clarity
+- Assertion quality and specificity
+- Test maintainability and brittleness
+
+### Accessibility
+
+- WCAG 2.1 AA compliance
+- Semantic HTML and ARIA usage
+- Keyboard navigation support
+- Screen reader compatibility
+- Color contrast ratios
+- Focus management and tab order
+- Alternative text for media
+- Responsive design and zoom support
+
+## Output Format
+
+For each finding, use this structure:
+
+```
+### [SEVERITY] Finding Title
+
+**Location**: `path/to/file.ts:42`
+**Dimension**: Security | Performance | Architecture | Testing | Accessibility
+**Severity**: Critical | High | Medium | Low
+
+**Evidence**:
+Description of what was found, with code snippet if relevant.
+
+**Impact**:
+What could go wrong if this is not addressed.
+
+**Recommended Fix**:
+Specific, actionable remediation with code example if applicable.
+```
+
+## Behavioral Traits
+
+- Stays strictly within assigned dimension — does not cross into other review areas
+- Cites specific file:line locations for every finding
+- Provides evidence-based severity ratings, not opinion-based
+- Suggests concrete fixes, not vague recommendations
+- Distinguishes between confirmed issues and potential concerns
+- Prioritizes findings by impact and likelihood
+- Avoids false positives by verifying context before reporting
+- Reports "no findings" dimensions honestly rather than inflating results

plugins/agent-teams/commands/team-debug.md

@@ -0,0 +1,91 @@
+---
+description: "Debug issues using competing hypotheses with parallel investigation by multiple agents"
+argument-hint: "<error-description-or-file> [--hypotheses N] [--scope files|module|project]"
+---
+
+# Team Debug
+
+Debug complex issues using the Analysis of Competing Hypotheses (ACH) methodology. Multiple debugger agents investigate different hypotheses in parallel, gathering evidence to confirm or falsify each one.
+
+## Pre-flight Checks
+
+1. Verify `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set
+2. Parse `$ARGUMENTS`:
+   - `<error-description-or-file>`: description of the bug, error message, or path to a file exhibiting the issue
+   - `--hypotheses N`: number of hypotheses to generate (default: 3)
+   - `--scope`: investigation scope — `files` (specific files), `module` (module/package), `project` (entire project)
+
+## Phase 1: Initial Triage
+
+1. Analyze the error description or file:
+   - If file path: read the file, look for obvious issues, collect error context
+   - If error description: search the codebase for related code, error messages, stack traces
+2. Identify the symptom clearly: what is failing, when, and how
+3. Gather initial context: recent git changes, related tests, configuration
+
+## Phase 2: Hypothesis Generation
+
+Generate N hypotheses about the root cause, covering different failure mode categories:
+
+1. **Logic Error** — Incorrect algorithm, wrong condition, off-by-one, missing edge case
+2. **Data Issue** — Invalid input, type mismatch, null/undefined, encoding problem
+3. **State Problem** — Race condition, stale cache, incorrect initialization, mutation bug
+4. **Integration Failure** — API contract violation, version mismatch, configuration error
+5. **Resource Issue** — Memory leak, connection exhaustion, timeout, disk space
+6. **Environment** — Missing dependency, wrong version, platform-specific behavior
+
+Present hypotheses to user: "Generated {N} hypotheses. Spawning investigators..."
+
+## Phase 3: Investigation
+
+1. Use `Teammate` tool with `operation: "spawnTeam"`, team name: `debug-{timestamp}`
+2. For each hypothesis, use `Task` tool to spawn a teammate:
+   - `name`: `investigator-{n}` (e.g., "investigator-1")
+   - `subagent_type`: "agent-teams:team-debugger"
+   - `prompt`: Include the hypothesis, investigation scope, and relevant context
+3. Use `TaskCreate` for each investigator's task:
+   - Subject: "Investigate hypothesis: {hypothesis summary}"
+   - Description: Full hypothesis statement, scope boundaries, evidence criteria
+
+## Phase 4: Evidence Collection
+
+1. Monitor TaskList for completion
+2. As investigators complete, collect their evidence reports
+3. Track: "{completed}/{total} investigations complete"
+
+## Phase 5: Arbitration
+
+1. Compare findings across all investigators:
+   - Which hypotheses were confirmed (high confidence)?
+   - Which were falsified (contradicting evidence)?
+   - Which are inconclusive (insufficient evidence)?
+
+2. Rank confirmed hypotheses by:
+   - Confidence level (High > Medium > Low)
+   - Strength of causal chain
+   - Amount of supporting evidence
+   - Absence of contradicting evidence
+
+3. Present root cause analysis:
+
+   ```
+   ## Debug Report: {error description}
+
+   ### Root Cause (Most Likely)
+   **Hypothesis**: {description}
+   **Confidence**: {High/Medium/Low}
+   **Evidence**: {summary with file:line citations}
+   **Causal Chain**: {step-by-step from cause to symptom}
+
+   ### Recommended Fix
+   {specific fix with code changes}
+
+   ### Other Hypotheses
+   - {hypothesis 2}: {status} — {brief evidence summary}
+   - {hypothesis 3}: {status} — {brief evidence summary}
+   ```
+
+## Phase 6: Cleanup
+
+1. Send `shutdown_request` to all investigators
+2. Call `Teammate` cleanup to remove team resources

plugins/agent-teams/commands/team-delegate.md

@@ -0,0 +1,94 @@
+---
+description: "Task delegation dashboard for managing team workload, assignments, and rebalancing"
+argument-hint: "[team-name] [--assign task-id=member-name] [--message member-name 'content'] [--rebalance]"
+---
+
+# Team Delegate
+
+Manage task assignments and team workload. Provides a delegation dashboard showing unassigned tasks, member workloads, blocked tasks, and rebalancing suggestions.
+
+## Pre-flight Checks
+
+1. Parse `$ARGUMENTS` for team name and action flags:
+   - `--assign task-id=member-name`: assign a specific task to a member
+   - `--message member-name 'content'`: send a message to a specific member
+   - `--rebalance`: analyze and rebalance workload distribution
+
+2. Read team config from `~/.claude/teams/{team-name}/config.json` using the Read tool
+3. Call `TaskList` to get current state
+
+## Action: Assign Task
+
+If `--assign` flag is provided:
+
+1. Parse task ID and member name from `task-id=member-name` format
+2. Use `TaskUpdate` to set the task owner
+3. Use `SendMessage` with `type: "message"` to notify the member:
+   - recipient: member name
+   - content: "You've been assigned task #{id}: {subject}. {task description}"
+4. Confirm: "Task #{id} assigned to {member-name}"
+
+## Action: Send Message
+
+If `--message` flag is provided:
+
+1. Parse member name and message content
+2. Use `SendMessage` with `type: "message"`:
+   - recipient: member name
+   - content: the message content
+3. Confirm: "Message sent to {member-name}"
+
+## Action: Rebalance
+
+If `--rebalance` flag is provided:
+
+1. Analyze current workload distribution:
+   - Count tasks per member (in_progress + pending assigned)
+   - Identify members with 0 tasks (idle)
+   - Identify members with 3+ tasks (overloaded)
+   - Check for blocked tasks that could be unblocked
+
+2. Generate rebalancing suggestions:
+
+   ```
+   ## Workload Analysis
+
+   Member          Tasks    Status
+   ─────────────────────────────────
+   implementer-1   3        overloaded
+   implementer-2   1        balanced
+   implementer-3   0        idle
+
+   Suggestions:
+   1. Move task #5 from implementer-1 to implementer-3
+   2. Assign unassigned task #7 to implementer-3
+   ```
+
+3. Ask user for confirmation before executing rebalancing
+4. Execute approved moves with `TaskUpdate` and `SendMessage`
+
+## Default: Delegation Dashboard
+
+If no action flag is provided, display the full delegation dashboard:
+
+```
+## Delegation Dashboard: {team-name}
+
+### Unassigned Tasks
+  #5  Review error handling patterns
+  #7  Add integration tests
+
+### Member Workloads
+  implementer-1   3 tasks (1 in_progress, 2 pending)
+  implementer-2   1 task  (1 in_progress)
+  implementer-3   0 tasks (idle)
+
+### Blocked Tasks
+  #6  Blocked by #4 (in_progress, owner: implementer-1)
+
+### Suggestions
+  - Assign #5 to implementer-3 (idle)
+  - Assign #7 to implementer-2 (low workload)
+```
+
+**Tip**: Use Shift+Tab to enter Claude Code's built-in delegate mode for ad-hoc task delegation.

plugins/agent-teams/commands/team-feature.md

@@ -0,0 +1,114 @@
+---
+description: "Develop features in parallel with multiple agents using file ownership boundaries and dependency management"
+argument-hint: "<feature-description> [--team-size N] [--branch feature/name] [--plan-first]"
+---
+
+# Team Feature
+
+Orchestrate parallel feature development with multiple implementer agents. Decomposes features into work streams with strict file ownership, manages dependencies, and verifies integration.
+
+## Pre-flight Checks
+
+1. Verify `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set
+2. Parse `$ARGUMENTS`:
+   - `<feature-description>`: description of the feature to build
+   - `--team-size N`: number of implementers (default: 2)
+   - `--branch`: git branch name (default: auto-generated from feature description)
+   - `--plan-first`: decompose and get user approval before spawning
+
+## Phase 1: Analysis
+
+1. Analyze the feature description to understand scope
+2. Explore the codebase to identify:
+   - Files that will need modification
+   - Existing patterns and conventions to follow
+   - Integration points with existing code
+   - Test files that need updates
+
+## Phase 2: Decomposition
+
+1. Decompose the feature into work streams:
+   - Each stream gets exclusive file ownership (no overlapping files)
+   - Define interface contracts between streams
+   - Identify dependencies between streams (blockedBy/blocks)
+   - Balance workload across streams
+
+2. If `--plan-first` is set:
+   - Present the decomposition to the user:
+
+     ```
+     ## Feature Decomposition: {feature}
+
+     ### Stream 1: {name}
+     Owner: implementer-1
+     Files: {list}
+     Dependencies: none
+
+     ### Stream 2: {name}
+     Owner: implementer-2
+     Files: {list}
+     Dependencies: blocked by Stream 1 (needs interface from {file})
+
+     ### Integration Contract
+     {shared types/interfaces}
+     ```
+
+   - Wait for user approval before proceeding
+   - If user requests changes, adjust decomposition
+
+## Phase 3: Team Spawn
+
+1. If `--branch` specified, use Bash to create and checkout the branch:
+   ```
+   git checkout -b {branch-name}
+   ```
+2. Use `Teammate` tool with `operation: "spawnTeam"`, team name: `feature-{timestamp}`
+3. Spawn a `team-lead` agent to coordinate
+4. For each work stream, use `Task` tool to spawn a `team-implementer`:
+   - `name`: `implementer-{n}`
+   - `subagent_type`: "agent-teams:team-implementer"
+   - `prompt`: Include owned files, interface contracts, and implementation requirements
+
+## Phase 4: Task Creation
+
+1. Use `TaskCreate` for each work stream:
+   - Subject: "{stream name}"
+   - Description: Owned files, requirements, interface contracts, acceptance criteria
+2. Use `TaskUpdate` to set `blockedBy` relationships for dependent streams
+3. Assign tasks to implementers with `TaskUpdate` (set `owner`)
+
+## Phase 5: Monitor and Coordinate
+
+1. Monitor `TaskList` for progress
+2. As implementers complete tasks:
+   - Check for integration issues
+   - Unblock dependent tasks
+   - Rebalance if needed
+3. Handle integration point coordination:
+   - When an implementer completes an interface, notify dependent implementers
+
+## Phase 6: Integration Verification
+
+After all tasks complete:
+
+1. Use Bash to verify the code compiles/builds: run appropriate build command
+2. Use Bash to run tests: run appropriate test command
+3. If issues found, create fix tasks and assign to appropriate implementers
+4. Report integration status to user
+
+## Phase 7: Cleanup
+
+1. Present feature summary:
+
+   ```
+   ## Feature Complete: {feature}
+
+   Files modified: {count}
+   Streams completed: {count}/{total}
+   Tests: {pass/fail}
+
+   Changes are on branch: {branch-name}
+   ```
+
+2. Send `shutdown_request` to all teammates
+3. Call `Teammate` cleanup

plugins/agent-teams/commands/team-review.md

@@ -0,0 +1,78 @@
+---
+description: "Launch a multi-reviewer parallel code review with specialized review dimensions"
+argument-hint: "<target> [--reviewers security,performance,architecture,testing,accessibility] [--base-branch main]"
+---
+
+# Team Review
+
+Orchestrate a multi-reviewer parallel code review where each reviewer focuses on a specific quality dimension. Produces a consolidated, deduplicated report organized by severity.
+
+## Pre-flight Checks
+
+1. Verify `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set
+2. Parse `$ARGUMENTS`:
+   - `<target>`: file path, directory, git diff range (e.g., `main...HEAD`), or PR number (e.g., `#123`)
+   - `--reviewers`: comma-separated dimensions (default: `security,performance,architecture`)
+   - `--base-branch`: base branch for diff comparison (default: `main`)
+
+## Phase 1: Target Resolution
+
+1. Determine target type:
+   - **File/Directory**: Use as-is for review scope
+   - **Git diff range**: Use Bash to run `git diff {range} --name-only` to get changed files
+   - **PR number**: Use Bash to run `gh pr diff {number} --name-only` to get changed files
+2. Collect the full diff content for distribution to reviewers
+3. Display review scope to user: "{N} files to review across {M} dimensions"
+
+## Phase 2: Team Spawn
+
+1. Use `Teammate` tool with `operation: "spawnTeam"`, team name: `review-{timestamp}`
+2. For each requested dimension, use `Task` tool to spawn a teammate:
+   - `name`: `{dimension}-reviewer` (e.g., "security-reviewer")
+   - `subagent_type`: "agent-teams:team-reviewer"
+   - `prompt`: Include the dimension assignment, target files, and diff content
+3. Use `TaskCreate` for each reviewer's task:
+   - Subject: "Review {target} for {dimension} issues"
+   - Description: Include file list, diff content, and dimension-specific checklist
+
+## Phase 3: Monitor and Collect
+
+1. Wait for all review tasks to complete (check `TaskList` periodically)
+2. As each reviewer completes, collect their structured findings
+3. Track progress: "{completed}/{total} reviews complete"
+
+## Phase 4: Consolidation
+
+1. **Deduplicate**: Merge findings that reference the same file:line location
+2. **Resolve conflicts**: If reviewers disagree on severity, use the higher rating
+3. **Organize by severity**: Group findings as Critical, High, Medium, Low
+4. **Cross-reference**: Note findings that appear in multiple dimensions
+
+## Phase 5: Report and Cleanup
+
+1. Present consolidated report:
+
+   ```
+   ## Code Review Report: {target}
+
+   Reviewed by: {dimensions}
+   Files reviewed: {count}
+
+   ### Critical ({count})
+   [findings...]
+
+   ### High ({count})
+   [findings...]
+
+   ### Medium ({count})
+   [findings...]
+
+   ### Low ({count})
+   [findings...]
+
+   ### Summary
+   Total findings: {count} (Critical: N, High: N, Medium: N, Low: N)
+   ```
+
+2. Send `shutdown_request` to all reviewers
+3. Call `Teammate` cleanup to remove team resources

plugins/agent-teams/commands/team-shutdown.md

@@ -0,0 +1,50 @@
+---
+description: "Gracefully shut down an agent team, collect final results, and clean up resources"
+argument-hint: "[team-name] [--force] [--keep-tasks]"
+---
+
+# Team Shutdown
+
+Gracefully shut down an active agent team by sending shutdown requests to all teammates, collecting final results, and cleaning up team resources.
+
+## Phase 1: Pre-Shutdown
+
+1. Parse `$ARGUMENTS` for team name and flags:
+   - If no team name, check for active teams (same discovery as team-status)
+   - `--force`: skip waiting for graceful shutdown responses
+   - `--keep-tasks`: preserve task list after cleanup
+
+2. Read team config from `~/.claude/teams/{team-name}/config.json` using the Read tool
+3. Call `TaskList` to check for in-progress tasks
+
+4. If there are in-progress tasks and `--force` is not set:
+   - Display warning: "Warning: {N} tasks are still in progress"
+   - List the in-progress tasks
+   - Ask user: "Proceed with shutdown? In-progress work may be lost."
+
+## Phase 2: Graceful Shutdown
+
+For each teammate in the team:
+
+1. Use `SendMessage` with `type: "shutdown_request"` to request graceful shutdown
+   - Include content: "Team shutdown requested. Please finish current work and save state."
+2. Wait for shutdown responses
+   - If teammate approves: mark as shut down
+   - If teammate rejects: report to user with reason
+   - If `--force`: don't wait for responses
+
+## Phase 3: Cleanup
+
+1. Display shutdown summary:
+
+   ```
+   Team "{team-name}" shutdown complete.
+
+   Members shut down: {N}/{total}
+   Tasks completed: {completed}/{total}
+   Tasks remaining: {remaining}
+   ```
+
+2. Unless `--keep-tasks` is set, call `Teammate` tool with `operation: "cleanup"` to remove team and task directories
+
+3. If `--keep-tasks` is set, inform user: "Task list preserved at ~/.claude/tasks/{team-name}/"

plugins/agent-teams/commands/team-spawn.md

@@ -0,0 +1,105 @@
+---
+description: "Spawn an agent team using presets (review, debug, feature, fullstack, research, security, migration) or custom composition"
+argument-hint: "<preset|custom> [--name team-name] [--members N] [--delegate]"
+---
+
+# Team Spawn
+
+Spawn a multi-agent team using preset configurations or custom composition. Handles team creation, teammate spawning, and initial task setup.
+
+## Pre-flight Checks
+
+1. Verify that `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set:
+   - If not set, inform the user: "Agent Teams requires the experimental feature flag. Set `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in your environment."
+   - Stop execution if not enabled
+
+2. Parse arguments from `$ARGUMENTS`:
+   - First positional arg: preset name or "custom"
+   - `--name`: team name (default: auto-generated from preset)
+   - `--members N`: override default member count
+   - `--delegate`: enter delegation mode after spawning
+
+## Phase 1: Team Configuration
+
+### Preset Teams
+
+If a preset is specified, use these configurations:
+
+**`review`** — Multi-dimensional code review (default: 3 members)
+
+- Spawn 3 `team-reviewer` agents with dimensions: security, performance, architecture
+- Team name default: `review-team`
+
+**`debug`** — Competing hypotheses debugging (default: 3 members)
+
+- Spawn 3 `team-debugger` agents, each assigned a different hypothesis
+- Team name default: `debug-team`
+
+**`feature`** — Parallel feature development (default: 3 members)
+
+- Spawn 1 `team-lead` agent + 2 `team-implementer` agents
+- Team name default: `feature-team`
+
+**`fullstack`** — Full-stack development (default: 4 members)
+
+- Spawn 1 `team-implementer` (frontend), 1 `team-implementer` (backend), 1 `team-implementer` (tests), 1 `team-lead`
+- Team name default: `fullstack-team`
+
+**`research`** — Parallel codebase, web, and documentation research (default: 3 members)
+
+- Spawn 3 `general-purpose` agents, each assigned a different research question or area
+- Agents have access to codebase search (Grep, Glob, Read) and web search (WebSearch, WebFetch)
+- Team name default: `research-team`
+
+**`security`** — Comprehensive security audit (default: 4 members)
+
+- Spawn 1 `team-reviewer` (OWASP/vulnerabilities), 1 `team-reviewer` (auth/access control), 1 `team-reviewer` (dependencies/supply chain), 1 `team-reviewer` (secrets/configuration)
+- Team name default: `security-team`
+
+**`migration`** — Codebase migration or large refactor (default: 4 members)
+
+- Spawn 1 `team-lead` (coordination + migration plan), 2 `team-implementer` (parallel migration streams), 1 `team-reviewer` (verify migration correctness)
+- Team name default: `migration-team`
+
+### Custom Composition
+
+If "custom" is specified:
+
+1. Use AskUserQuestion to prompt for team size (2-5 members)
+2. For each member, ask for role selection: team-lead, team-reviewer, team-debugger, team-implementer
+3. Ask for team name if not provided via `--name`
+
+## Phase 2: Team Creation
+
+1. Use the `Teammate` tool with `operation: "spawnTeam"` to create the team
+2. For each team member, use the `Task` tool with:
+   - `team_name`: the team name
+   - `name`: descriptive member name (e.g., "security-reviewer", "hypothesis-1")
+   - `subagent_type`: "general-purpose" (teammates need full tool access)
+   - `prompt`: Role-specific instructions referencing the appropriate agent definition
+
+## Phase 3: Initial Setup
+
+1. Use `TaskCreate` to create initial placeholder tasks for each teammate
+2. Display team summary:
+   - Team name
+   - Member names and roles
+   - Display mode (tmux/iTerm2/in-process)
+3. If `--delegate` flag is set, transition to delegation mode
+
+## Output
+
+Display a formatted team summary:
+
+```
+Team "{team-name}" spawned successfully!
+
+Members:
+  - {member-1-name} ({role})
+  - {member-2-name} ({role})
+  - {member-3-name} ({role})
+
+Use /team-status to monitor progress
+Use /team-delegate to assign tasks
+Use /team-shutdown to clean up
+```

plugins/agent-teams/commands/team-status.md

@@ -0,0 +1,60 @@
+---
+description: "Display team members, task status, and progress for an active agent team"
+argument-hint: "[team-name] [--tasks] [--members] [--json]"
+---
+
+# Team Status
+
+Display the current state of an active agent team including members, tasks, and progress.
+
+## Phase 1: Team Discovery
+
+1. Parse `$ARGUMENTS` for team name and flags:
+   - If team name provided, use it directly
+   - If no team name, check `~/.claude/teams/` for active teams
+   - If multiple teams exist and no name specified, list all teams and ask user to choose
+   - `--tasks`: show only task details
+   - `--members`: show only member details
+   - `--json`: output raw JSON instead of formatted table
+
+2. Read team config from `~/.claude/teams/{team-name}/config.json` using the Read tool
+3. Call `TaskList` to get current task state
+
+## Phase 2: Status Display
+
+### Members Table
+
+Display each team member with their current state:
+
+```
+Team: {team-name}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Members:
+  Name              Role              Status
+  ─────────────────────────────────────────
+  security-rev      team-reviewer     working on task #2
+  perf-rev          team-reviewer     idle
+  arch-rev          team-reviewer     working on task #4
+```
+
+### Tasks Table
+
+Display tasks with status, assignee, and dependencies:
+
+```
+Tasks:
+  ID   Status        Owner           Subject
+  ─────────────────────────────────────────────────
+  #1   completed     security-rev    Review auth module
+  #2   in_progress   security-rev    Review API endpoints
+  #3   completed     perf-rev        Profile database queries
+  #4   in_progress   arch-rev        Analyze module structure
+  #5   pending       (unassigned)    Consolidate findings
+
+Progress: 40% (2/5 completed)
+```
+
+### JSON Output
+
+If `--json` flag is set, output the raw team config and task list as JSON.

plugins/agent-teams/skills/multi-reviewer-patterns/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: multi-reviewer-patterns
+description: Coordinate parallel code reviews across multiple quality dimensions with finding deduplication, severity calibration, and consolidated reporting. Use this skill when organizing multi-reviewer code reviews, calibrating finding severity, or consolidating review results.
+version: 1.0.2
+---
+
+# Multi-Reviewer Patterns
+
+Patterns for coordinating parallel code reviews across multiple quality dimensions, deduplicating findings, calibrating severity, and producing consolidated reports.
+
+## When to Use This Skill
+
+- Organizing a multi-dimensional code review
+- Deciding which review dimensions to assign
+- Deduplicating findings from multiple reviewers
+- Calibrating severity ratings consistently
+- Producing a consolidated review report
+
+## Review Dimension Allocation
+
+### Available Dimensions
+
+| Dimension         | Focus                                   | When to Include                             |
+| ----------------- | --------------------------------------- | ------------------------------------------- |
+| **Security**      | Vulnerabilities, auth, input validation | Always for code handling user input or auth |
+| **Performance**   | Query efficiency, memory, caching       | When changing data access or hot paths      |
+| **Architecture**  | SOLID, coupling, patterns               | For structural changes or new modules       |
+| **Testing**       | Coverage, quality, edge cases           | When adding new functionality               |
+| **Accessibility** | WCAG, ARIA, keyboard nav                | For UI/frontend changes                     |
+
+### Recommended Combinations
+
+| Scenario               | Dimensions                                   |
+| ---------------------- | -------------------------------------------- |
+| API endpoint changes   | Security, Performance, Architecture          |
+| Frontend component     | Architecture, Testing, Accessibility         |
+| Database migration     | Performance, Architecture                    |
+| Authentication changes | Security, Testing                            |
+| Full feature review    | Security, Performance, Architecture, Testing |
+
+## Finding Deduplication
+
+When multiple reviewers report issues at the same location:
+
+### Merge Rules
+
+1. **Same file:line, same issue** — Merge into one finding, credit all reviewers
+2. **Same file:line, different issues** — Keep as separate findings
+3. **Same issue, different locations** — Keep separate but cross-reference
+4. **Conflicting severity** — Use the higher severity rating
+5. **Conflicting recommendations** — Include both with reviewer attribution
+
+### Deduplication Process
+
+```
+For each finding in all reviewer reports:
+  1. Check if another finding references the same file:line
+  2. If yes, check if they describe the same issue
+  3. If same issue: merge, keeping the more detailed description
+  4. If different issue: keep both, tag as "co-located"
+  5. Use highest severity among merged findings
+```
+
+## Severity Calibration
+
+### Severity Criteria
+
+| Severity     | Impact                                        | Likelihood             | Examples                                     |
+| ------------ | --------------------------------------------- | ---------------------- | -------------------------------------------- |
+| **Critical** | Data loss, security breach, complete failure  | Certain or very likely | SQL injection, auth bypass, data corruption  |
+| **High**     | Significant functionality impact, degradation | Likely                 | Memory leak, missing validation, broken flow |
+| **Medium**   | Partial impact, workaround exists             | Possible               | N+1 query, missing edge case, unclear error  |
+| **Low**      | Minimal impact, cosmetic                      | Unlikely               | Style issue, minor optimization, naming      |
+
+### Calibration Rules
+
+- Security vulnerabilities exploitable by external users: always Critical or High
+- Performance issues in hot paths: at least Medium
+- Missing tests for critical paths: at least Medium
+- Accessibility violations for core functionality: at least Medium
+- Code style issues with no functional impact: Low
+
+## Consolidated Report Template
+
+```markdown
+## Code Review Report
+
+**Target**: {files/PR/directory}
+**Reviewers**: {dimension-1}, {dimension-2}, {dimension-3}
+**Date**: {date}
+**Files Reviewed**: {count}
+
+### Critical Findings ({count})
+
+#### [CR-001] {Title}
+
+**Location**: `{file}:{line}`
+**Dimension**: {Security/Performance/etc.}
+**Description**: {what was found}
+**Impact**: {what could happen}
+**Fix**: {recommended remediation}
+
+### High Findings ({count})
+
+...
+
+### Medium Findings ({count})
+
+...
+
+### Low Findings ({count})
+
+...
+
+### Summary
+
+| Dimension    | Critical | High  | Medium | Low   | Total  |
+| ------------ | -------- | ----- | ------ | ----- | ------ |
+| Security     | 1        | 2     | 3      | 0     | 6      |
+| Performance  | 0        | 1     | 4      | 2     | 7      |
+| Architecture | 0        | 0     | 2      | 3     | 5      |
+| **Total**    | **1**    | **3** | **9**  | **5** | **18** |
+
+### Recommendation
+
+{Overall assessment and prioritized action items}
+```

plugins/agent-teams/skills/multi-reviewer-patterns/references/review-dimensions.md

@@ -0,0 +1,127 @@
+# Review Dimension Checklists
+
+Detailed checklists for each review dimension that reviewers follow during parallel code review.
+
+## Security Review Checklist
+
+### Input Handling
+
+- [ ] All user inputs are validated and sanitized
+- [ ] SQL queries use parameterized statements (no string concatenation)
+- [ ] HTML output is properly escaped to prevent XSS
+- [ ] File paths are validated to prevent path traversal
+- [ ] Request size limits are enforced
+
+### Authentication & Authorization
+
+- [ ] Authentication is required for all protected endpoints
+- [ ] Authorization checks verify user has permission for the action
+- [ ] JWT tokens are validated (signature, expiry, issuer)
+- [ ] Password hashing uses bcrypt/argon2 (not MD5/SHA)
+- [ ] Session management follows best practices
+
+### Secrets & Configuration
+
+- [ ] No hardcoded secrets, API keys, or passwords
+- [ ] Secrets are loaded from environment variables or secret manager
+- [ ] .gitignore includes sensitive file patterns
+- [ ] Debug/development endpoints are disabled in production
+
+### Dependencies
+
+- [ ] No known CVEs in direct dependencies
+- [ ] Dependencies are pinned to specific versions
+- [ ] No unnecessary dependencies that increase attack surface
+
+## Performance Review Checklist
+
+### Database
+
+- [ ] No N+1 query patterns
+- [ ] Queries use appropriate indexes
+- [ ] No SELECT \* on large tables
+- [ ] Pagination is implemented for list endpoints
+- [ ] Connection pooling is configured
+
+### Memory & Resources
+
+- [ ] No memory leaks (event listeners cleaned up, streams closed)
+- [ ] Large data sets are streamed, not loaded entirely into memory
+- [ ] File handles and connections are properly closed
+- [ ] Caching is used for expensive operations
+
+### Computation
+
+- [ ] No unnecessary re-computation or redundant operations
+- [ ] Appropriate algorithm complexity for the data size
+- [ ] Async operations used where I/O bound
+- [ ] No blocking operations on the main thread
+
+## Architecture Review Checklist
+
+### Design Principles
+
+- [ ] Single Responsibility: each module/class has one reason to change
+- [ ] Open/Closed: extensible without modification
+- [ ] Dependency Inversion: depends on abstractions, not concretions
+- [ ] No circular dependencies between modules
+
+### Structure
+
+- [ ] Clear separation of concerns (UI, business logic, data)
+- [ ] Consistent error handling strategy across the codebase
+- [ ] Configuration is externalized, not hardcoded
+- [ ] API contracts are well-defined and versioned
+
+### Patterns
+
+- [ ] Consistent patterns used throughout (no pattern mixing)
+- [ ] Abstractions are at the right level (not over/under-engineered)
+- [ ] Module boundaries align with domain boundaries
+- [ ] Shared utilities are actually shared (no duplication)
+
+## Testing Review Checklist
+
+### Coverage
+
+- [ ] Critical paths have test coverage
+- [ ] Edge cases are tested (empty input, null, boundary values)
+- [ ] Error paths are tested (what happens when things fail)
+- [ ] Integration points have integration tests
+
+### Quality
+
+- [ ] Tests are deterministic (no flaky tests)
+- [ ] Tests are isolated (no shared state between tests)
+- [ ] Assertions are specific (not just "no error thrown")
+- [ ] Test names clearly describe what is being tested
+
+### Maintainability
+
+- [ ] Tests don't duplicate implementation logic
+- [ ] Mocks/stubs are minimal and accurate
+- [ ] Test data is clear and relevant
+- [ ] Tests are easy to understand without reading the implementation
+
+## Accessibility Review Checklist
+
+### Structure
+
+- [ ] Semantic HTML elements used (nav, main, article, button)
+- [ ] Heading hierarchy is logical (h1 → h2 → h3)
+- [ ] ARIA roles and properties used correctly
+- [ ] Landmarks identify page regions
+
+### Interaction
+
+- [ ] All functionality accessible via keyboard
+- [ ] Focus order is logical and visible
+- [ ] No keyboard traps
+- [ ] Touch targets are at least 44x44px
+
+### Content
+
+- [ ] Images have meaningful alt text
+- [ ] Color is not the only means of conveying information
+- [ ] Text has sufficient contrast ratio (4.5:1 for normal, 3:1 for large)
+- [ ] Content is readable at 200% zoom

plugins/agent-teams/skills/parallel-debugging/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: parallel-debugging
+description: Debug complex issues using competing hypotheses with parallel investigation, evidence collection, and root cause arbitration. Use this skill when debugging bugs with multiple potential causes, performing root cause analysis, or organizing parallel investigation workflows.
+version: 1.0.2
+---
+
+# Parallel Debugging
+
+Framework for debugging complex issues using the Analysis of Competing Hypotheses (ACH) methodology with parallel agent investigation.
+
+## When to Use This Skill
+
+- Bug has multiple plausible root causes
+- Initial debugging attempts haven't identified the issue
+- Issue spans multiple modules or components
+- Need systematic root cause analysis with evidence
+- Want to avoid confirmation bias in debugging
+
+## Hypothesis Generation Framework
+
+Generate hypotheses across 6 failure mode categories:
+
+### 1. Logic Error
+
+- Incorrect conditional logic (wrong operator, missing case)
+- Off-by-one errors in loops or array access
+- Missing edge case handling
+- Incorrect algorithm implementation
+
+### 2. Data Issue
+
+- Invalid or unexpected input data
+- Type mismatch or coercion error
+- Null/undefined/None where value expected
+- Encoding or serialization problem
+- Data truncation or overflow
+
+### 3. State Problem
+
+- Race condition between concurrent operations
+- Stale cache returning outdated data
+- Incorrect initialization or default values
+- Unintended mutation of shared state
+- State machine transition error
+
+### 4. Integration Failure
+
+- API contract violation (request/response mismatch)
+- Version incompatibility between components
+- Configuration mismatch between environments
+- Missing or incorrect environment variables
+- Network timeout or connection failure
+
+### 5. Resource Issue
+
+- Memory leak causing gradual degradation
+- Connection pool exhaustion
+- File descriptor or handle leak
+- Disk space or quota exceeded
+- CPU saturation from inefficient processing
+
+### 6. Environment
+
+- Missing runtime dependency
+- Wrong library or framework version
+- Platform-specific behavior difference
+- Permission or access control issue
+- Timezone or locale-related behavior
+
+## Evidence Collection Standards
+
+### What Constitutes Evidence
+
+| Evidence Type     | Strength | Example                                                         |
+| ----------------- | -------- | --------------------------------------------------------------- |
+| **Direct**        | Strong   | Code at `file.ts:42` shows `if (x > 0)` should be `if (x >= 0)` |
+| **Correlational** | Medium   | Error rate increased after commit `abc123`                      |
+| **Testimonial**   | Weak     | "It works on my machine"                                        |
+| **Absence**       | Variable | No null check found in the code path                            |
+
+### Citation Format
+
+Always cite evidence with file:line references:
+
+```
+**Evidence**: The validation function at `src/validators/user.ts:87`
+does not check for empty strings, only null/undefined. This allows
+empty email addresses to pass validation.
+```
+
+### Confidence Levels
+
+| Level               | Criteria                                                                            |
+| ------------------- | ----------------------------------------------------------------------------------- |
+| **High (>80%)**     | Multiple direct evidence pieces, clear causal chain, no contradicting evidence      |
+| **Medium (50-80%)** | Some direct evidence, plausible causal chain, minor ambiguities                     |
+| **Low (<50%)**      | Mostly correlational evidence, incomplete causal chain, some contradicting evidence |
+
+## Result Arbitration Protocol
+
+After all investigators report:
+
+### Step 1: Categorize Results
+
+- **Confirmed**: High confidence, strong evidence, clear causal chain
+- **Plausible**: Medium confidence, some evidence, reasonable causal chain
+- **Falsified**: Evidence contradicts the hypothesis
+- **Inconclusive**: Insufficient evidence to confirm or falsify
+
+### Step 2: Compare Confirmed Hypotheses
+
+If multiple hypotheses are confirmed, rank by:
+
+1. Confidence level
+2. Number of supporting evidence pieces
+3. Strength of causal chain
+4. Absence of contradicting evidence
+
+### Step 3: Determine Root Cause
+
+- If one hypothesis clearly dominates: declare as root cause
+- If multiple hypotheses are equally likely: may be compound issue (multiple contributing causes)
+- If no hypotheses confirmed: generate new hypotheses based on evidence gathered
+
+### Step 4: Validate Fix
+
+Before declaring the bug fixed:
+
+- [ ] Fix addresses the identified root cause
+- [ ] Fix doesn't introduce new issues
+- [ ] Original reproduction case no longer fails
+- [ ] Related edge cases are covered
+- [ ] Relevant tests are added or updated

plugins/agent-teams/skills/parallel-debugging/references/hypothesis-testing.md

@@ -0,0 +1,120 @@
+# Hypothesis Testing Reference
+
+Task templates, evidence formats, and arbitration decision trees for parallel debugging.
+
+## Hypothesis Task Template
+
+```markdown
+## Hypothesis Investigation: {Hypothesis Title}
+
+### Hypothesis Statement
+
+{Clear, falsifiable statement about the root cause}
+
+### Failure Mode Category
+
+{Logic Error | Data Issue | State Problem | Integration Failure | Resource Issue | Environment}
+
+### Investigation Scope
+
+- Files to examine: {file list or directory}
+- Related tests: {test files}
+- Git history: {relevant date range or commits}
+
+### Evidence Criteria
+
+**Confirming evidence** (if I find these, hypothesis is supported):
+
+1. {Observable condition 1}
+2. {Observable condition 2}
+
+**Falsifying evidence** (if I find these, hypothesis is wrong):
+
+1. {Observable condition 1}
+2. {Observable condition 2}
+
+### Report Format
+
+- Confidence: High/Medium/Low
+- Evidence: list with file:line citations
+- Causal chain: step-by-step from cause to symptom
+- Recommended fix: if confirmed
+```
+
+## Evidence Report Template
+
+```markdown
+## Investigation Report: {Hypothesis Title}
+
+### Verdict: {Confirmed | Falsified | Inconclusive}
+
+### Confidence: {High (>80%) | Medium (50-80%) | Low (<50%)}
+
+### Confirming Evidence
+
+1. `src/api/users.ts:47` — {description of what was found}
+2. `src/middleware/auth.ts:23` — {description}
+
+### Contradicting Evidence
+
+1. `tests/api/users.test.ts:112` — {description of what contradicts}
+
+### Causal Chain (if confirmed)
+
+1. {First cause} →
+2. {Intermediate effect} →
+3. {Observable symptom}
+
+### Recommended Fix
+
+{Specific code change with location}
+
+### Additional Notes
+
+{Anything discovered that may be relevant to other hypotheses}
+```
+
+## Arbitration Decision Tree
+
+```
+All investigators reported?
+├── NO → Wait for remaining reports
+└── YES → Count confirmed hypotheses
+          ├── 0 confirmed
+          │   ├── Any medium confidence? → Investigate further
+          │   └── All low/falsified? → Generate new hypotheses
+          ├── 1 confirmed
+          │   └── High confidence?
+          │       ├── YES → Declare root cause, propose fix
+          │       └── NO → Flag as likely cause, recommend verification
+          └── 2+ confirmed
+              └── Are they related?
+                  ├── YES → Compound issue (multiple contributing causes)
+                  └── NO → Rank by confidence, declare highest as primary
+```
+
+## Common Hypothesis Patterns by Error Type
+
+### "500 Internal Server Error"
+
+1. Unhandled exception in request handler (Logic Error)
+2. Database connection failure (Resource Issue)
+3. Missing environment variable (Environment)
+
+### "Race condition / intermittent failure"
+
+1. Shared state mutation without locking (State Problem)
+2. Async operation ordering assumption (Logic Error)
+3. Cache staleness window (State Problem)
+
+### "Works locally, fails in production"
+
+1. Environment variable mismatch (Environment)
+2. Different dependency version (Environment)
+3. Resource limits (memory, connections) (Resource Issue)
+
+### "Regression after deploy"
+
+1. New code introduced bug (Logic Error)
+2. Configuration change (Integration Failure)
+3. Database migration issue (Data Issue)

plugins/agent-teams/skills/parallel-feature-development/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: parallel-feature-development
+description: Coordinate parallel feature development with file ownership strategies, conflict avoidance rules, and integration patterns for multi-agent implementation. Use this skill when decomposing features for parallel development, establishing file ownership boundaries, or managing integration between parallel work streams.
+version: 1.0.2
+---
+
+# Parallel Feature Development
+
+Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.
+
+## When to Use This Skill
+
+- Decomposing a feature for parallel implementation
+- Establishing file ownership boundaries between agents
+- Designing interface contracts between parallel work streams
+- Choosing integration strategies (vertical slice vs horizontal layer)
+- Managing branch and merge workflows for parallel development
+
+## File Ownership Strategies
+
+### By Directory
+
+Assign each implementer ownership of specific directories:
+
+```
+implementer-1: src/components/auth/
+implementer-2: src/api/auth/
+implementer-3: tests/auth/
+```
+
+**Best for**: Well-organized codebases with clear directory boundaries.
+
+### By Module
+
+Assign ownership of logical modules (which may span directories):
+
+```
+implementer-1: Authentication module (login, register, logout)
+implementer-2: Authorization module (roles, permissions, guards)
+```
+
+**Best for**: Feature-oriented architectures, domain-driven design.
+
+### By Layer
+
+Assign ownership of architectural layers:
+
+```
+implementer-1: UI layer (components, styles, layouts)
+implementer-2: Business logic layer (services, validators)
+implementer-3: Data layer (models, repositories, migrations)
+```
+
+**Best for**: Traditional MVC/layered architectures.
+
+## Conflict Avoidance Rules
+
+### The Cardinal Rule
+
+**One owner per file.** No file should be assigned to multiple implementers.
+
+### When Files Must Be Shared
+
+If a file genuinely needs changes from multiple implementers:
+
+1. **Designate a single owner** — One implementer owns the file
+2. **Other implementers request changes** — Message the owner with specific change requests
+3. **Owner applies changes sequentially** — Prevents merge conflicts
+4. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying
+
+### Interface Contracts
+
+When implementers need to coordinate at boundaries:
+
+```typescript
+// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
+export interface AuthResponse {
+  token: string;
+  user: UserProfile;
+  expiresAt: number;
+}
+
+export interface AuthService {
+  login(email: string, password: string): Promise<AuthResponse>;
+  register(data: RegisterData): Promise<AuthResponse>;
+}
+```
+
+Both implementers import from the contract file but neither modifies it.
+
+## Integration Patterns
+
+### Vertical Slice
+
+Each implementer builds a complete feature slice (UI + API + tests):
+
+```
+implementer-1: Login feature (login form + login API + login tests)
+implementer-2: Register feature (register form + register API + register tests)
+```
+
+**Pros**: Each slice is independently testable, minimal integration needed.
+**Cons**: May duplicate shared utilities, harder with tightly coupled features.
+
+### Horizontal Layer
+
+Each implementer builds one layer across all features:
+
+```
+implementer-1: All UI components (login form, register form, profile page)
+implementer-2: All API endpoints (login, register, profile)
+implementer-3: All tests (unit, integration, e2e)
+```
+
+**Pros**: Consistent patterns within each layer, natural specialization.
+**Cons**: More integration points, layer 3 depends on layers 1 and 2.
+
+### Hybrid
+
+Mix vertical and horizontal based on coupling:
+
+```
+implementer-1: Login feature (vertical slice — UI + API + tests)
+implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)
+```
+
+**Best for**: Most real-world features with some shared infrastructure.
+
+## Branch Management
+
+### Single Branch Strategy
+
+All implementers work on the same feature branch:
+
+- Simple setup, no merge overhead
+- Requires strict file ownership to avoid conflicts
+- Best for: small teams (2-3), well-defined boundaries
+
+### Multi-Branch Strategy
+
+Each implementer works on a sub-branch:
+
+```
+feature/auth
+  ├── feature/auth-login      (implementer-1)
+  ├── feature/auth-register    (implementer-2)
+  └── feature/auth-tests       (implementer-3)
+```
+
+- More isolation, explicit merge points
+- Higher overhead, merge conflicts still possible in shared files
+- Best for: larger teams (4+), complex features

plugins/agent-teams/skills/parallel-feature-development/references/file-ownership.md

@@ -0,0 +1,80 @@
+# File Ownership Decision Framework
+
+How to assign file ownership when decomposing features for parallel development.
+
+## Ownership Decision Process
+
+### Step 1: Map All Files
+
+List every file that needs to be created or modified for the feature.
+
+### Step 2: Identify Natural Clusters
+
+Group files by:
+
+- Directory proximity (files in the same directory)
+- Functional relationship (files that import each other)
+- Layer membership (all UI files, all API files)
+
+### Step 3: Assign Clusters to Owners
+
+Each cluster becomes one implementer's ownership boundary:
+
+- No file appears in multiple clusters
+- Each cluster is internally cohesive
+- Cross-cluster dependencies are minimized
+
+### Step 4: Define Interface Points
+
+Where clusters interact, define:
+
+- Shared type definitions (owned by lead or a designated implementer)
+- API contracts (function signatures, request/response shapes)
+- Event contracts (event names and payload shapes)
+
+## Ownership by Project Type
+
+### React/Next.js Frontend
+
+```
+implementer-1: src/components/{feature}/   (UI components)
+implementer-2: src/hooks/{feature}/        (custom hooks, state)
+implementer-3: src/api/{feature}/          (API client, types)
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Express/Fastify Backend
+
+```
+implementer-1: src/routes/{feature}.ts, src/controllers/{feature}.ts
+implementer-2: src/services/{feature}.ts, src/validators/{feature}.ts
+implementer-3: src/models/{feature}.ts, src/repositories/{feature}.ts
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Full-Stack (Next.js)
+
+```
+implementer-1: app/{feature}/page.tsx, app/{feature}/components/
+implementer-2: app/api/{feature}/route.ts, lib/{feature}/
+implementer-3: tests/{feature}/
+shared:        types/{feature}.ts          (owned by lead)
+```
+
+### Python Django
+
+```
+implementer-1: {app}/views.py, {app}/urls.py, {app}/forms.py
+implementer-2: {app}/models.py, {app}/serializers.py, {app}/managers.py
+implementer-3: {app}/tests/
+shared:        {app}/types.py              (owned by lead)
+```
+
+## Conflict Resolution
+
+When two implementers need to modify the same file:
+
+1. **Preferred: Split the file** — Extract the shared concern into its own file
+2. **If can't split: Designate one owner** — The other implementer sends change requests
+3. **Last resort: Sequential access** — Implementer A finishes, then implementer B takes over
+4. **Never**: Let both modify the same file simultaneously

plugins/agent-teams/skills/parallel-feature-development/references/merge-strategies.md

@@ -0,0 +1,75 @@
+# Integration and Merge Strategies
+
+Patterns for integrating parallel work streams and resolving conflicts.
+
+## Integration Patterns
+
+### Pattern 1: Direct Integration
+
+All implementers commit to the same branch; integration happens naturally.
+
+```
+feature/auth ← implementer-1 commits
+             ← implementer-2 commits
+             ← implementer-3 commits
+```
+
+**When to use**: Small teams (2-3), strict file ownership (no conflicts expected).
+
+### Pattern 2: Sub-Branch Integration
+
+Each implementer works on a sub-branch; lead merges them sequentially.
+
+```
+feature/auth
+  ├── feature/auth-login     ← implementer-1
+  ├── feature/auth-register  ← implementer-2
+  └── feature/auth-tests     ← implementer-3
+```
+
+Merge order: follow dependency graph (foundation → dependent → integration).
+
+**When to use**: Larger teams (4+), overlapping concerns, need for review gates.
+
+### Pattern 3: Trunk-Based with Feature Flags
+
+All implementers commit to the main branch behind a feature flag.
+
+```
+main ← all implementers commit
+     ← feature flag gates new code
+```
+
+**When to use**: CI/CD environments, short-lived features, continuous deployment.
+
+## Integration Verification Checklist
+
+After all implementers complete:
+
+1. **Build check**: Does the code compile/bundle without errors?
+2. **Type check**: Do TypeScript/type annotations pass?
+3. **Lint check**: Does the code pass linting rules?
+4. **Unit tests**: Do all unit tests pass?
+5. **Integration tests**: Do cross-component tests pass?
+6. **Interface verification**: Do all interface contracts match their implementations?
+
+## Conflict Resolution
+
+### Prevention (Best)
+
+- Strict file ownership eliminates most conflicts
+- Interface contracts define boundaries before implementation
+- Shared type files are owned by the lead and modified sequentially
+
+### Detection
+
+- Git merge will report conflicts if they occur
+- TypeScript/lint errors indicate interface mismatches
+- Test failures indicate behavioral conflicts
+
+### Resolution Strategies
+
+1. **Contract wins**: If code doesn't match the interface contract, the code is wrong
+2. **Lead arbitrates**: The team lead decides which implementation to keep
+3. **Tests decide**: The implementation that passes tests is correct
+4. **Merge manually**: For complex conflicts, the lead merges by hand

plugins/agent-teams/skills/task-coordination-strategies/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: task-coordination-strategies
+description: Decompose complex tasks, design dependency graphs, and coordinate multi-agent work with proper task descriptions and workload balancing. Use this skill when breaking down work for agent teams, managing task dependencies, or monitoring team progress.
+version: 1.0.2
+---
+
+# Task Coordination Strategies
+
+Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.
+
+## When to Use This Skill
+
+- Breaking down a complex task for parallel execution
+- Designing task dependency relationships (blockedBy/blocks)
+- Writing task descriptions with clear acceptance criteria
+- Monitoring and rebalancing workload across teammates
+- Identifying the critical path in a multi-task workflow
+
+## Task Decomposition Strategies
+
+### By Layer
+
+Split work by architectural layer:
+
+- Frontend components
+- Backend API endpoints
+- Database migrations/models
+- Test suites
+
+**Best for**: Full-stack features, vertical slices
+
+### By Component
+
+Split work by functional component:
+
+- Authentication module
+- User profile module
+- Notification module
+
+**Best for**: Microservices, modular architectures
+
+### By Concern
+
+Split work by cross-cutting concern:
+
+- Security review
+- Performance review
+- Architecture review
+
+**Best for**: Code reviews, audits
+
+### By File Ownership
+
+Split work by file/directory boundaries:
+
+- `src/components/` — Implementer 1
+- `src/api/` — Implementer 2
+- `src/utils/` — Implementer 3
+
+**Best for**: Parallel implementation, conflict avoidance
+
+## Dependency Graph Design
+
+### Principles
+
+1. **Minimize chain depth** — Prefer wide, shallow graphs over deep chains
+2. **Identify the critical path** — The longest chain determines minimum completion time
+3. **Use blockedBy sparingly** — Only add dependencies that are truly required
+4. **Avoid circular dependencies** — Task A blocks B blocks A is a deadlock
+
+### Patterns
+
+**Independent (Best parallelism)**:
+
+```
+Task A ─┐
+Task B ─┼─→ Integration
+Task C ─┘
+```
+
+**Sequential (Necessary dependencies)**:
+
+```
+Task A → Task B → Task C
+```
+
+**Diamond (Mixed)**:
+
+```
+        ┌→ Task B ─┐
+Task A ─┤          ├→ Task D
+        └→ Task C ─┘
+```
+
+### Using blockedBy/blocks
+
+```
+TaskCreate: { subject: "Build API endpoints" }         → Task #1
+TaskCreate: { subject: "Build frontend components" }    → Task #2
+TaskCreate: { subject: "Integration testing" }          → Task #3
+TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] }  → #3 waits for #1 and #2
+```
+
+## Task Description Best Practices
+
+Every task should include:
+
+1. **Objective** — What needs to be accomplished (1-2 sentences)
+2. **Owned Files** — Explicit list of files/directories this teammate may modify
+3. **Requirements** — Specific deliverables or behaviors expected
+4. **Interface Contracts** — How this work connects to other teammates' work
+5. **Acceptance Criteria** — How to verify the task is done correctly
+6. **Scope Boundaries** — What is explicitly out of scope
+
+### Template
+
+```
+## Objective
+Build the user authentication API endpoints.
+
+## Owned Files
+- src/api/auth.ts
+- src/api/middleware/auth-middleware.ts
+- src/types/auth.ts (shared — read only, do not modify)
+
+## Requirements
+- POST /api/login — accepts email/password, returns JWT
+- POST /api/register — creates new user, returns JWT
+- GET /api/me — returns current user profile (requires auth)
+
+## Interface Contract
+- Import User type from src/types/auth.ts (owned by implementer-1)
+- Export AuthResponse type for frontend consumption
+
+## Acceptance Criteria
+- All endpoints return proper HTTP status codes
+- JWT tokens expire after 24 hours
+- Passwords are hashed with bcrypt
+
+## Out of Scope
+- OAuth/social login
+- Password reset flow
+- Rate limiting
+```
+
+## Workload Monitoring
+
+### Indicators of Imbalance
+
+| Signal                     | Meaning             | Action                      |
+| -------------------------- | ------------------- | --------------------------- |
+| Teammate idle, others busy | Uneven distribution | Reassign pending tasks      |
+| Teammate stuck on one task | Possible blocker    | Check in, offer help        |
+| All tasks blocked          | Dependency issue    | Resolve critical path first |
+| One teammate has 3x others | Overloaded          | Split tasks or reassign     |
+
+### Rebalancing Steps
+
+1. Call `TaskList` to assess current state
+2. Identify idle or overloaded teammates
+3. Use `TaskUpdate` to reassign tasks
+4. Use `SendMessage` to notify affected teammates
+5. Monitor for improved throughput

plugins/agent-teams/skills/task-coordination-strategies/references/dependency-graphs.md

@@ -0,0 +1,97 @@
+# Dependency Graph Patterns
+
+Visual patterns for task dependency design with trade-offs.
+
+## Pattern 1: Fully Independent (Maximum Parallelism)
+
+```
+Task A ─┐
+Task B ─┼─→ Final Integration
+Task C ─┘
+```
+
+- **Parallelism**: Maximum — all tasks run simultaneously
+- **Risk**: Integration may reveal incompatibilities late
+- **Use when**: Tasks operate on completely separate files/modules
+- **TaskCreate**: No blockedBy relationships; integration task blocked by all
+
+## Pattern 2: Sequential Chain (No Parallelism)
+
+```
+Task A → Task B → Task C → Task D
+```
+
+- **Parallelism**: None — each task waits for the previous
+- **Risk**: Bottleneck at each step; one delay cascades
+- **Use when**: Each task depends on the output of the previous (avoid if possible)
+- **TaskCreate**: Each task blockedBy the previous
+
+## Pattern 3: Diamond (Shared Foundation)
+
+```
+           ┌→ Task B ─┐
+Task A ──→ ┤          ├→ Task D
+           └→ Task C ─┘
+```
+
+- **Parallelism**: B and C run in parallel after A completes
+- **Risk**: A is a bottleneck; D must wait for both B and C
+- **Use when**: B and C both need output from A (e.g., shared types)
+- **TaskCreate**: B and C blockedBy A; D blockedBy B and C
+
+## Pattern 4: Fork-Join (Phased Parallelism)
+
+```
+Phase 1:  A1, A2, A3  (parallel)
+          ────────────
+Phase 2:  B1, B2      (parallel, after phase 1)
+          ────────────
+Phase 3:  C1          (after phase 2)
+```
+
+- **Parallelism**: Within each phase, tasks are parallel
+- **Risk**: Phase boundaries add synchronization delays
+- **Use when**: Natural phases with dependencies (build → test → deploy)
+- **TaskCreate**: Phase 2 tasks blockedBy all Phase 1 tasks
+
+## Pattern 5: Pipeline (Streaming)
+
+```
+Task A ──→ Task B ──→ Task C
+  └──→ Task D ──→ Task E
+```
+
+- **Parallelism**: Two parallel chains
+- **Risk**: Chains may diverge in approach
+- **Use when**: Two independent feature branches from a common starting point
+- **TaskCreate**: B blockedBy A; D blockedBy A; C blockedBy B; E blockedBy D
+
+## Anti-Patterns
+
+### Circular Dependency (Deadlock)
+
+```
+Task A → Task B → Task C → Task A  ✗ DEADLOCK
+```
+
+**Fix**: Extract shared dependency into a separate task that all three depend on.
+
+### Unnecessary Dependencies
+
+```
+Task A → Task B → Task C
+(where B doesn't actually need A's output)
+```
+
+**Fix**: Remove the blockedBy relationship; let B run independently.
+
+### Star Pattern (Single Bottleneck)
+
+```
+     ┌→ B
+A →  ├→ C  → F
+     ├→ D
+     └→ E
+```
+
+**Fix**: If A is slow, all downstream tasks are delayed. Try to parallelize A's work.

plugins/agent-teams/skills/task-coordination-strategies/references/task-decomposition.md

@@ -0,0 +1,98 @@
+# Task Decomposition Examples
+
+Practical examples of decomposing features into parallelizable tasks with clear ownership.
+
+## Example 1: User Authentication Feature
+
+### Feature Description
+
+Add email/password authentication with login, registration, and profile pages.
+
+### Decomposition (Vertical Slices)
+
+**Stream 1: Login Flow** (implementer-1)
+
+- Owned files: `src/pages/login.tsx`, `src/api/login.ts`, `tests/login.test.ts`
+- Requirements: Login form, API endpoint, input validation, error handling
+- Interface: Imports `AuthResponse` from `src/types/auth.ts`
+
+**Stream 2: Registration Flow** (implementer-2)
+
+- Owned files: `src/pages/register.tsx`, `src/api/register.ts`, `tests/register.test.ts`
+- Requirements: Registration form, API endpoint, email validation, password strength
+- Interface: Imports `AuthResponse` from `src/types/auth.ts`
+
+**Stream 3: Shared Infrastructure** (implementer-3)
+
+- Owned files: `src/types/auth.ts`, `src/middleware/auth.ts`, `src/utils/jwt.ts`
+- Requirements: Type definitions, JWT middleware, token utilities
+- Dependencies: None (other streams depend on this)
+
+### Dependency Graph
+
+```
+Stream 3 (types/middleware) ──→ Stream 1 (login)
+                             └→ Stream 2 (registration)
+```
+
+## Example 2: REST API Endpoints
+
+### Feature Description
+
+Add CRUD endpoints for a new "Projects" resource.
+
+### Decomposition (By Layer)
+
+**Stream 1: Data Layer** (implementer-1)
+
+- Owned files: `src/models/project.ts`, `src/migrations/add-projects.ts`, `src/repositories/project-repo.ts`
+- Requirements: Schema definition, migration, repository pattern
+- Dependencies: None
+
+**Stream 2: Business Logic** (implementer-2)
+
+- Owned files: `src/services/project-service.ts`, `src/validators/project-validator.ts`
+- Requirements: CRUD operations, validation rules, business logic
+- Dependencies: Blocked by Stream 1 (needs model/repository)
+
+**Stream 3: API Layer** (implementer-3)
+
+- Owned files: `src/routes/projects.ts`, `src/controllers/project-controller.ts`
+- Requirements: REST endpoints, request parsing, response formatting
+- Dependencies: Blocked by Stream 2 (needs service layer)
+
+## Task Template
+
+```markdown
+## Task: {Stream Name}
+
+### Objective
+
+{1-2 sentence description of what to build}
+
+### Owned Files
+
+- {file1} — {purpose}
+- {file2} — {purpose}
+
+### Requirements
+
+1. {Specific deliverable 1}
+2. {Specific deliverable 2}
+3. {Specific deliverable 3}
+
+### Interface Contract
+
+- Exports: {types/functions this stream provides}
+- Imports: {types/functions this stream consumes from other streams}
+
+### Acceptance Criteria
+
+- [ ] {Verifiable criterion 1}
+- [ ] {Verifiable criterion 2}
+- [ ] {Verifiable criterion 3}
+
+### Out of Scope
+
+- {Explicitly excluded work}
+```

plugins/agent-teams/skills/team-communication-protocols/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: team-communication-protocols
+description: Structured messaging protocols for agent team communication including message type selection, plan approval, shutdown procedures, and anti-patterns to avoid. Use this skill when establishing team communication norms, handling plan approvals, or managing team shutdown.
+version: 1.0.2
+---
+
+# Team Communication Protocols
+
+Protocols for effective communication between agent teammates, including message type selection, plan approval workflows, shutdown procedures, and common anti-patterns to avoid.
+
+## When to Use This Skill
+
+- Establishing communication norms for a new team
+- Choosing between message types (message, broadcast, shutdown_request)
+- Handling plan approval workflows
+- Managing graceful team shutdown
+- Discovering teammate identities and capabilities
+
+## Message Type Selection
+
+### `message` (Direct Message) — Default Choice
+
+Send to a single specific teammate:
+
+```json
+{
+  "type": "message",
+  "recipient": "implementer-1",
+  "content": "Your API endpoint is ready. You can now build the frontend form.",
+  "summary": "API endpoint ready for frontend"
+}
+```
+
+**Use for**: Task updates, coordination, questions, integration notifications.
+
+### `broadcast` — Use Sparingly
+
+Send to ALL teammates simultaneously:
+
+```json
+{
+  "type": "broadcast",
+  "content": "Critical: shared types file has been updated. Pull latest before continuing.",
+  "summary": "Shared types updated"
+}
+```
+
+**Use ONLY for**: Critical blockers affecting everyone, major changes to shared resources.
+
+**Why sparingly?**: Each broadcast sends N separate messages (one per teammate), consuming API resources proportional to team size.
+
+### `shutdown_request` — Graceful Termination
+
+Request a teammate to shut down:
+
+```json
+{
+  "type": "shutdown_request",
+  "recipient": "reviewer-1",
+  "content": "Review complete, shutting down team."
+}
+```
+
+The teammate responds with `shutdown_response` (approve or reject with reason).
+
+## Communication Anti-Patterns
+
+| Anti-Pattern                            | Problem                                  | Better Approach                        |
+| --------------------------------------- | ---------------------------------------- | -------------------------------------- |
+| Broadcasting routine updates            | Wastes resources, noise                  | Direct message to affected teammate    |
+| Sending JSON status messages            | Not designed for structured data         | Use TaskUpdate to update task status   |
+| Not communicating at integration points | Teammates build against stale interfaces | Message when your interface is ready   |
+| Micromanaging via messages              | Overwhelms teammates, slows work         | Check in at milestones, not every step |
+| Using UUIDs instead of names            | Hard to read, error-prone                | Always use teammate names              |
+| Ignoring idle teammates                 | Wasted capacity                          | Assign new work or shut down           |
+
+## Plan Approval Workflow
+
+When a teammate is spawned with `plan_mode_required`:
+
+1. Teammate creates a plan using read-only exploration tools
+2. Teammate calls `ExitPlanMode` which sends a `plan_approval_request` to the lead
+3. Lead reviews the plan
+4. Lead responds with `plan_approval_response`:
+
+**Approve**:
+
+```json
+{
+  "type": "plan_approval_response",
+  "request_id": "abc-123",
+  "recipient": "implementer-1",
+  "approve": true
+}
+```
+
+**Reject with feedback**:
+
+```json
+{
+  "type": "plan_approval_response",
+  "request_id": "abc-123",
+  "recipient": "implementer-1",
+  "approve": false,
+  "content": "Please add error handling for the API calls"
+}
+```
+
+## Shutdown Protocol
+
+### Graceful Shutdown Sequence
+
+1. **Lead sends shutdown_request** to each teammate
+2. **Teammate receives request** as a JSON message with `type: "shutdown_request"`
+3. **Teammate responds** with `shutdown_response`:
+   - `approve: true` — Teammate saves state and exits
+   - `approve: false` + reason — Teammate continues working
+4. **Lead handles rejections** — Wait for teammate to finish, then retry
+5. **After all teammates shut down** — Call `Teammate` cleanup
+
+### Handling Rejections
+
+If a teammate rejects shutdown:
+
+- Check their reason (usually "still working on task")
+- Wait for their current task to complete
+- Retry shutdown request
+- If urgent, user can force shutdown
+
+## Teammate Discovery
+
+Find team members by reading the config file:
+
+**Location**: `~/.claude/teams/{team-name}/config.json`
+
+**Structure**:
+
+```json
+{
+  "members": [
+    {
+      "name": "security-reviewer",
+      "agentId": "uuid-here",
+      "agentType": "team-reviewer"
+    },
+    {
+      "name": "perf-reviewer",
+      "agentId": "uuid-here",
+      "agentType": "team-reviewer"
+    }
+  ]
+}
+```
+
+**Always use `name`** for messaging and task assignment. Never use `agentId` directly.

plugins/agent-teams/skills/team-communication-protocols/references/messaging-patterns.md

@@ -0,0 +1,112 @@
+# Messaging Pattern Templates
+
+Ready-to-use message templates for common team communication scenarios.
+
+## Task Assignment
+
+```
+You've been assigned task #{id}: {subject}.
+
+Owned files:
+- {file1}
+- {file2}
+
+Key requirements:
+- {requirement1}
+- {requirement2}
+
+Interface contract:
+- Import {types} from {shared-file}
+- Export {types} for {other-teammate}
+
+Let me know if you have questions or blockers.
+```
+
+## Integration Point Notification
+
+```
+My side of the {interface-name} interface is complete.
+
+Exported from {file}:
+- {function/type 1}
+- {function/type 2}
+
+You can now import these in your owned files. The contract matches what we agreed on.
+```
+
+## Blocker Report
+
+```
+I'm blocked on task #{id}: {subject}.
+
+Blocker: {description of what's preventing progress}
+Impact: {what can't be completed until this is resolved}
+
+Options:
+1. {option 1}
+2. {option 2}
+
+Waiting for your guidance.
+```
+
+## Task Completion Report
+
+```
+Task #{id} complete: {subject}
+
+Changes made:
+- {file1}: {what changed}
+- {file2}: {what changed}
+
+Integration notes:
+- {any interface changes or considerations for other teammates}
+
+Ready for next assignment.
+```
+
+## Review Finding Summary
+
+```
+Review complete for {target} ({dimension} dimension).
+
+Summary:
+- Critical: {count}
+- High: {count}
+- Medium: {count}
+- Low: {count}
+
+Top finding: {brief description of most important finding}
+
+Full findings attached to task #{id}.
+```
+
+## Investigation Report Summary
+
+```
+Investigation complete for hypothesis: {hypothesis summary}
+
+Verdict: {Confirmed | Falsified | Inconclusive}
+Confidence: {High | Medium | Low}
+
+Key evidence:
+- {file:line}: {what was found}
+- {file:line}: {what was found}
+
+{If confirmed}: Recommended fix: {brief fix description}
+{If falsified}: Contradicting evidence: {brief description}
+
+Full report attached to task #{id}.
+```
+
+## Shutdown Acknowledgment
+
+When you receive a shutdown request, respond with the shutdown_response tool. But you may also want to send a final status message:
+
+```
+Wrapping up. Current status:
+- Task #{id}: {completed/in-progress}
+- Files modified: {list}
+- Pending work: {none or description}
+
+Ready for shutdown.
+```

plugins/agent-teams/skills/team-composition-patterns/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: team-composition-patterns
+description: Design optimal agent team compositions with sizing heuristics, preset configurations, and agent type selection. Use this skill when deciding team size, selecting agent types, or configuring team presets for multi-agent workflows.
+version: 1.0.2
+---
+
+# Team Composition Patterns
+
+Best practices for composing multi-agent teams, selecting team sizes, choosing agent types, and configuring display modes for Claude Code's Agent Teams feature.
+
+## When to Use This Skill
+
+- Deciding how many teammates to spawn for a task
+- Choosing between preset team configurations
+- Selecting the right agent type (subagent_type) for each role
+- Configuring teammate display modes (tmux, iTerm2, in-process)
+- Building custom team compositions for non-standard workflows
+
+## Team Sizing Heuristics
+
+| Complexity   | Team Size | When to Use                                                 |
+| ------------ | --------- | ----------------------------------------------------------- |
+| Simple       | 1-2       | Single-dimension review, isolated bug, small feature        |
+| Moderate     | 2-3       | Multi-file changes, 2-3 concerns, medium features           |
+| Complex      | 3-4       | Cross-cutting concerns, large features, deep debugging      |
+| Very Complex | 4-5       | Full-stack features, comprehensive reviews, systemic issues |
+
+**Rule of thumb**: Start with the smallest team that covers all required dimensions. Adding teammates increases coordination overhead.
+
+## Preset Team Compositions
+
+### Review Team
+
+- **Size**: 3 reviewers
+- **Agents**: 3x `team-reviewer`
+- **Default dimensions**: security, performance, architecture
+- **Use when**: Code changes need multi-dimensional quality assessment
+
+### Debug Team
+
+- **Size**: 3 investigators
+- **Agents**: 3x `team-debugger`
+- **Default hypotheses**: 3 competing hypotheses
+- **Use when**: Bug has multiple plausible root causes
+
+### Feature Team
+
+- **Size**: 3 (1 lead + 2 implementers)
+- **Agents**: 1x `team-lead` + 2x `team-implementer`
+- **Use when**: Feature can be decomposed into parallel work streams
+
+### Fullstack Team
+
+- **Size**: 4 (1 lead + 3 implementers)
+- **Agents**: 1x `team-lead` + 1x frontend `team-implementer` + 1x backend `team-implementer` + 1x test `team-implementer`
+- **Use when**: Feature spans frontend, backend, and test layers
+
+### Research Team
+
+- **Size**: 3 researchers
+- **Agents**: 3x `general-purpose`
+- **Default areas**: Each assigned a different research question, module, or topic
+- **Capabilities**: Codebase search (Grep, Glob, Read), web search (WebSearch, WebFetch)
+- **Use when**: Need to understand a codebase, research libraries, compare approaches, or gather information from code and web sources in parallel
+
+### Security Team
+
+- **Size**: 4 reviewers
+- **Agents**: 4x `team-reviewer`
+- **Default dimensions**: OWASP/vulnerabilities, auth/access control, dependencies/supply chain, secrets/configuration
+- **Use when**: Comprehensive security audit covering multiple attack surfaces
+
+### Migration Team
+
+- **Size**: 4 (1 lead + 2 implementers + 1 reviewer)
+- **Agents**: 1x `team-lead` + 2x `team-implementer` + 1x `team-reviewer`
+- **Use when**: Large codebase migration (framework upgrade, language port, API version bump) requiring parallel work with correctness verification
+
+## Agent Type Selection
+
+When spawning teammates with the Task tool, choose `subagent_type` based on what tools the teammate needs:
+
+| Agent Type                     | Tools Available                           | Use For                                                    |
+| ------------------------------ | ----------------------------------------- | ---------------------------------------------------------- |
+| `general-purpose`              | All tools (Read, Write, Edit, Bash, etc.) | Implementation, debugging, any task requiring file changes |
+| `Explore`                      | Read-only tools (Read, Grep, Glob)        | Research, code exploration, analysis                       |
+| `Plan`                         | Read-only tools                           | Architecture planning, task decomposition                  |
+| `agent-teams:team-reviewer`    | All tools                                 | Code review with structured findings                       |
+| `agent-teams:team-debugger`    | All tools                                 | Hypothesis-driven investigation                            |
+| `agent-teams:team-implementer` | All tools                                 | Building features within file ownership boundaries         |
+| `agent-teams:team-lead`        | All tools                                 | Team orchestration and coordination                        |
+
+**Key distinction**: Read-only agents (Explore, Plan) cannot modify files. Never assign implementation tasks to read-only agents.
+
+## Display Mode Configuration
+
+Configure in `~/.claude/settings.json`:
+
+```json
+{
+  "teammateMode": "tmux"
+}
+```
+
+| Mode           | Behavior                       | Best For                                          |
+| -------------- | ------------------------------ | ------------------------------------------------- |
+| `"tmux"`       | Each teammate in a tmux pane   | Development workflows, monitoring multiple agents |
+| `"iterm2"`     | Each teammate in an iTerm2 tab | macOS users who prefer iTerm2                     |
+| `"in-process"` | All teammates in same process  | Simple tasks, CI/CD environments                  |
+
+## Custom Team Guidelines
+
+When building custom teams:
+
+1. **Every team needs a coordinator** — Either designate a `team-lead` or have the user coordinate directly
+2. **Match roles to agent types** — Use specialized agents (reviewer, debugger, implementer) when available
+3. **Avoid duplicate roles** — Two agents doing the same thing wastes resources
+4. **Define boundaries upfront** — Each teammate needs clear ownership of files or responsibilities
+5. **Keep it small** — 2-4 teammates is the sweet spot; 5+ requires significant coordination overhead

plugins/agent-teams/skills/team-composition-patterns/references/agent-type-selection.md

@@ -0,0 +1,84 @@
+# Agent Type Selection Guide
+
+Decision matrix for choosing the right `subagent_type` when spawning teammates.
+
+## Decision Matrix
+
+```
+Does the teammate need to modify files?
+├── YES → Does it need a specialized role?
+│         ├── YES → Which role?
+│         │         ├── Code review → agent-teams:team-reviewer
+│         │         ├── Bug investigation → agent-teams:team-debugger
+│         │         ├── Feature building → agent-teams:team-implementer
+│         │         └── Team coordination → agent-teams:team-lead
+│         └── NO → general-purpose
+└── NO → Does it need deep codebase exploration?
+          ├── YES → Explore
+          └── NO → Plan (for architecture/design tasks)
+```
+
+## Agent Type Comparison
+
+| Agent Type                   | Can Read | Can Write | Can Edit | Can Bash | Specialized        |
+| ---------------------------- | -------- | --------- | -------- | -------- | ------------------ |
+| general-purpose              | Yes      | Yes       | Yes      | Yes      | No                 |
+| Explore                      | Yes      | No        | No       | No       | Search/explore     |
+| Plan                         | Yes      | No        | No       | No       | Architecture       |
+| agent-teams:team-lead        | Yes      | Yes       | Yes      | Yes      | Team orchestration |
+| agent-teams:team-reviewer    | Yes      | Yes       | Yes      | Yes      | Code review        |
+| agent-teams:team-debugger    | Yes      | Yes       | Yes      | Yes      | Bug investigation  |
+| agent-teams:team-implementer | Yes      | Yes       | Yes      | Yes      | Feature building   |
+
+## Common Mistakes
+
+| Mistake                               | Why It Fails                   | Correct Choice                          |
+| ------------------------------------- | ------------------------------ | --------------------------------------- |
+| Using `Explore` for implementation    | Cannot write/edit files        | `general-purpose` or `team-implementer` |
+| Using `Plan` for coding tasks         | Cannot write/edit files        | `general-purpose` or `team-implementer` |
+| Using `general-purpose` for reviews   | No review structure/checklists | `team-reviewer`                         |
+| Using `team-implementer` for research | Has tools but wrong focus      | `Explore` or `Plan`                     |
+
+## When to Use Each
+
+### general-purpose
+
+- One-off tasks that don't fit specialized roles
+- Tasks requiring unique tool combinations
+- Ad-hoc scripting or automation
+
+### Explore
+
+- Codebase research and analysis
+- Finding files, patterns, or dependencies
+- Understanding architecture before planning
+
+### Plan
+
+- Designing implementation approaches
+- Creating task decompositions
+- Architecture review (read-only)
+
+### team-lead
+
+- Coordinating multiple teammates
+- Decomposing work and managing tasks
+- Synthesizing results from parallel work
+
+### team-reviewer
+
+- Focused code review on a specific dimension
+- Producing structured findings with severity ratings
+- Following dimension-specific checklists
+
+### team-debugger
+
+- Investigating a specific hypothesis about a bug
+- Gathering evidence with file:line citations
+- Reporting confidence levels and causal chains
+
+### team-implementer
+
+- Building code within file ownership boundaries
+- Following interface contracts
+- Coordinating at integration points

plugins/agent-teams/skills/team-composition-patterns/references/preset-teams.md

@@ -0,0 +1,265 @@
+# Preset Team Definitions
+
+Detailed preset team configurations with task templates for common workflows.
+
+## Review Team Preset
+
+**Command**: `/team-spawn review`
+
+### Configuration
+
+- **Team Size**: 3
+- **Agent Type**: `agent-teams:team-reviewer`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name                  | Dimension    | Focus Areas                                       |
+| --------------------- | ------------ | ------------------------------------------------- |
+| security-reviewer     | Security     | Input validation, auth, injection, secrets, CVEs  |
+| performance-reviewer  | Performance  | Query efficiency, memory, caching, async patterns |
+| architecture-reviewer | Architecture | SOLID, coupling, patterns, error handling         |
+
+### Task Template
+
+```
+Subject: Review {target} for {dimension} issues
+Description:
+  Dimension: {dimension}
+  Target: {file list or diff}
+  Checklist: {dimension-specific checklist}
+  Output format: Structured findings with file:line, severity, evidence, fix
+```
+
+### Variations
+
+- **Security-focused**: `--reviewers security,testing` (2 members)
+- **Full review**: `--reviewers security,performance,architecture,testing,accessibility` (5 members)
+- **Frontend review**: `--reviewers architecture,testing,accessibility` (3 members)
+
+## Debug Team Preset
+
+**Command**: `/team-spawn debug`
+
+### Configuration
+
+- **Team Size**: 3 (default) or N with `--hypotheses N`
+- **Agent Type**: `agent-teams:team-debugger`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name           | Role                      |
+| -------------- | ------------------------- |
+| investigator-1 | Investigates hypothesis 1 |
+| investigator-2 | Investigates hypothesis 2 |
+| investigator-3 | Investigates hypothesis 3 |
+
+### Task Template
+
+```
+Subject: Investigate hypothesis: {hypothesis summary}
+Description:
+  Hypothesis: {full hypothesis statement}
+  Scope: {files/module/project}
+  Evidence criteria:
+    Confirming: {what would confirm}
+    Falsifying: {what would falsify}
+  Report format: confidence level, evidence with file:line, causal chain
+```
+
+## Feature Team Preset
+
+**Command**: `/team-spawn feature`
+
+### Configuration
+
+- **Team Size**: 3 (1 lead + 2 implementers)
+- **Agent Types**: `agent-teams:team-lead` + `agent-teams:team-implementer`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name          | Role             | Responsibility                           |
+| ------------- | ---------------- | ---------------------------------------- |
+| feature-lead  | team-lead        | Decomposition, coordination, integration |
+| implementer-1 | team-implementer | Work stream 1 (assigned files)           |
+| implementer-2 | team-implementer | Work stream 2 (assigned files)           |
+
+### Task Template
+
+```
+Subject: Implement {work stream name}
+Description:
+  Owned files: {explicit file list}
+  Requirements: {specific deliverables}
+  Interface contract: {shared types/APIs}
+  Acceptance criteria: {verification steps}
+  Blocked by: {dependency task IDs if any}
+```
+
+## Fullstack Team Preset
+
+**Command**: `/team-spawn fullstack`
+
+### Configuration
+
+- **Team Size**: 4 (1 lead + 3 implementers)
+- **Agent Types**: `agent-teams:team-lead` + 3x `agent-teams:team-implementer`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name           | Role             | Layer                            |
+| -------------- | ---------------- | -------------------------------- |
+| fullstack-lead | team-lead        | Coordination, integration        |
+| frontend-dev   | team-implementer | UI components, client-side logic |
+| backend-dev    | team-implementer | API endpoints, business logic    |
+| test-dev       | team-implementer | Unit, integration, e2e tests     |
+
+### Dependency Pattern
+
+```
+frontend-dev ──┐
+               ├──→ test-dev (blocked by both)
+backend-dev  ──┘
+```
+
+## Research Team Preset
+
+**Command**: `/team-spawn research`
+
+### Configuration
+
+- **Team Size**: 3
+- **Agent Type**: `general-purpose`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name         | Role            | Focus                                            |
+| ------------ | --------------- | ------------------------------------------------ |
+| researcher-1 | general-purpose | Research area 1 (e.g., codebase architecture)    |
+| researcher-2 | general-purpose | Research area 2 (e.g., library documentation)    |
+| researcher-3 | general-purpose | Research area 3 (e.g., web resources & examples) |
+
+### Available Research Tools
+
+Each researcher has access to:
+
+- **Codebase**: `Grep`, `Glob`, `Read` — search and read local files
+- **Web**: `WebSearch`, `WebFetch` — search the web and fetch page content
+- **Deep Exploration**: `Task` with `subagent_type: Explore` — spawn sub-explorers for deep dives
+
+### Task Template
+
+```
+Subject: Research {topic or question}
+Description:
+  Question: {specific research question}
+  Scope: {codebase files, web resources, library docs, or all}
+  Tools to prioritize:
+    - Codebase: Grep/Glob/Read for local code analysis
+    - Web: WebSearch/WebFetch for articles, examples, best practices
+  Deliverable: Summary with citations (file:line for code, URLs for web)
+  Output format: Structured report with sections, evidence, and recommendations
+```
+
+### Variations
+
+- **Codebase-only**: 3 researchers exploring different modules or patterns locally
+- **Web research**: 3 researchers using WebSearch to survey approaches, benchmarks, or best practices
+- **Mixed**: 1 codebase researcher + 1 docs researcher + 1 web researcher (recommended for evaluating new libraries)
+
+### Example Research Assignments
+
+```
+Researcher 1 (codebase): "How does our current auth system work? Trace the flow from login to token validation."
+Researcher 2 (web): "Search for comparisons between NextAuth, Clerk, and Auth0 for Next.js apps. Focus on pricing, DX, and migration effort."
+Researcher 3 (docs): "Look up the latest NextAuth.js v5 API docs. How does it handle JWT and session management?"
+```
+
+## Security Team Preset
+
+**Command**: `/team-spawn security`
+
+### Configuration
+
+- **Team Size**: 4
+- **Agent Type**: `agent-teams:team-reviewer`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name            | Dimension      | Focus Areas                                          |
+| --------------- | -------------- | ---------------------------------------------------- |
+| vuln-reviewer   | OWASP/Vulns    | Injection, XSS, CSRF, deserialization, SSRF          |
+| auth-reviewer   | Auth/Access    | Authentication, authorization, session management    |
+| deps-reviewer   | Dependencies   | CVEs, supply chain, outdated packages, license risks |
+| config-reviewer | Secrets/Config | Hardcoded secrets, env vars, debug endpoints, CORS   |
+
+### Task Template
+
+```
+Subject: Security audit {target} for {dimension}
+Description:
+  Dimension: {security sub-dimension}
+  Target: {file list, directory, or entire project}
+  Checklist: {dimension-specific security checklist}
+  Output format: Structured findings with file:line, CVSS-like severity, evidence, remediation
+  Standards: OWASP Top 10, CWE references where applicable
+```
+
+### Variations
+
+- **Quick scan**: `--reviewers owasp,secrets` (2 members for fast audit)
+- **Full audit**: All 4 dimensions (default)
+- **CI/CD focused**: Add a 5th reviewer for pipeline security and deployment configuration
+
+## Migration Team Preset
+
+**Command**: `/team-spawn migration`
+
+### Configuration
+
+- **Team Size**: 4 (1 lead + 2 implementers + 1 reviewer)
+- **Agent Types**: `agent-teams:team-lead` + 2x `agent-teams:team-implementer` + `agent-teams:team-reviewer`
+- **Display Mode**: tmux recommended
+
+### Members
+
+| Name             | Role             | Responsibility                                  |
+| ---------------- | ---------------- | ----------------------------------------------- |
+| migration-lead   | team-lead        | Migration plan, coordination, conflict handling |
+| migrator-1       | team-implementer | Migration stream 1 (assigned files/modules)     |
+| migrator-2       | team-implementer | Migration stream 2 (assigned files/modules)     |
+| migration-verify | team-reviewer    | Verify migrated code correctness and patterns   |
+
+### Task Template
+
+```
+Subject: Migrate {module/files} from {old} to {new}
+Description:
+  Owned files: {explicit file list}
+  Migration rules: {specific transformation patterns}
+  Old pattern: {what to change from}
+  New pattern: {what to change to}
+  Acceptance criteria: {tests pass, no regressions, new patterns used}
+  Blocked by: {dependency task IDs if any}
+```
+
+### Dependency Pattern
+
+```
+migration-lead (plan) → migrator-1 ──┐
+                      → migrator-2 ──┼→ migration-verify
+                                     ┘
+```
+
+### Use Cases
+
+- Framework upgrades (React class → hooks, Vue 2 → Vue 3, Angular version bumps)
+- Language migrations (JavaScript → TypeScript, Python 2 → 3)
+- API version bumps (REST v1 → v2, GraphQL schema changes)
+- Database migrations (ORM changes, schema restructuring)
+- Build system changes (Webpack → Vite, CRA → Next.js)

plugins/api-scaffolding/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "api-scaffolding",
+  "version": "1.2.2",
+  "description": "REST and GraphQL API scaffolding, framework selection, backend architecture, and API generation",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/api-scaffolding/agents/backend-architect.md

@@ -44,7 +44,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Service boundaries**: Domain-Driven Design, bounded contexts, service decomposition
 - **Service communication**: Synchronous (REST, gRPC), asynchronous (message queues, events)
 - **Service discovery**: Consul, etcd, Eureka, Kubernetes service discovery
-- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management
+- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management, OCI API Gateway
 - **Service mesh**: Istio, Linkerd, traffic management, observability, security
 - **Backend-for-Frontend (BFF)**: Client-specific backends, API aggregation
 - **Strangler pattern**: Gradual migration, legacy system integration
@@ -54,8 +54,8 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 
 ### Event-Driven Architecture
 
-- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub
-- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, NATS
+- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub, OCI Queue
+- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, Google Pub/Sub, OCI Streaming, NATS
 - **Pub/Sub patterns**: Topic-based, content-based filtering, fan-out
 - **Event sourcing**: Event store, event replay, snapshots, projections
 - **Event-driven microservices**: Event choreography, event collaboration
@@ -86,10 +86,10 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **CSRF protection**: Token-based, SameSite cookies, double-submit patterns
 - **SQL injection prevention**: Parameterized queries, ORM usage, input validation
 - **API security**: API keys, OAuth scopes, request signing, encryption
-- **Secrets management**: Vault, AWS Secrets Manager, environment variables
+- **Secrets management**: Vault, AWS Secrets Manager, Azure Key Vault, OCI Vault, environment variables
 - **Content Security Policy**: Headers, XSS prevention, frame protection
 - **API throttling**: Quota management, burst limits, backpressure
-- **DDoS protection**: CloudFlare, AWS Shield, rate limiting, IP blocking
+- **DDoS protection**: CloudFlare, AWS Shield, Azure DDoS Protection, OCI WAF, rate limiting, IP blocking
 
 ### Resilience & Fault Tolerance
 
@@ -168,7 +168,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 ### API Gateway & Load Balancing
 
 - **Gateway patterns**: Authentication, rate limiting, request routing, transformation
-- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, NGINX
+- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, Azure API Management, OCI API Gateway, NGINX
 - **Load balancing**: Round-robin, least connections, consistent hashing, health-aware
 - **Service routing**: Path-based, header-based, weighted routing, A/B testing
 - **Traffic management**: Canary deployments, blue-green, traffic splitting

plugins/api-scaffolding/skills/fastapi-templates/SKILL.md

@@ -538,30 +538,3 @@ async def test_create_user(client):
     assert data["email"] == "test@example.com"
     assert "id" in data
 ```
-
-## Resources
-
-- **references/fastapi-architecture.md**: Detailed architecture guide
-- **references/async-best-practices.md**: Async/await patterns
-- **references/testing-strategies.md**: Comprehensive testing guide
-- **assets/project-template/**: Complete FastAPI project
-- **assets/docker-compose.yml**: Development environment setup
-
-## Best Practices
-
-1. **Async All The Way**: Use async for database, external APIs
-2. **Dependency Injection**: Leverage FastAPI's DI system
-3. **Repository Pattern**: Separate data access from business logic
-4. **Service Layer**: Keep business logic out of routes
-5. **Pydantic Schemas**: Strong typing for request/response
-6. **Error Handling**: Consistent error responses
-7. **Testing**: Test all layers independently
-
-## Common Pitfalls
-
-- **Blocking Code in Async**: Using synchronous database drivers
-- **No Service Layer**: Business logic in route handlers
-- **Missing Type Hints**: Loses FastAPI's benefits
-- **Ignoring Sessions**: Not properly managing database sessions
-- **No Testing**: Skipping integration tests
-- **Tight Coupling**: Direct database access in routes

plugins/api-testing-observability/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "api-testing-observability",
+  "version": "1.2.0",
+  "description": "API testing automation, request mocking, OpenAPI documentation generation, observability setup, and monitoring",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/application-performance/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "application-performance",
+  "version": "1.3.0",
+  "description": "Application profiling, performance optimization, and observability for frontend and backend systems",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/application-performance/agents/observability-engineer.md

@@ -20,6 +20,7 @@ Expert observability engineer specializing in comprehensive monitoring strategie
 - DataDog enterprise monitoring with custom metrics and synthetic monitoring
 - New Relic APM integration and performance baseline establishment
 - CloudWatch comprehensive AWS service monitoring and cost optimization
+- OCI Monitoring, Logging, and Logging Analytics for cloud-native telemetry pipelines
 - Nagios and Zabbix for traditional infrastructure monitoring
 - Custom metrics collection with StatsD, Telegraf, and Collectd
 - High-cardinality metrics handling and storage optimization
@@ -29,6 +30,7 @@ Expert observability engineer specializing in comprehensive monitoring strategie
 - Jaeger distributed tracing deployment and trace analysis
 - Zipkin trace collection and service dependency mapping
 - AWS X-Ray integration for serverless and microservice architectures
+- OCI Application Performance Monitoring for distributed tracing and service diagnostics
 - OpenTracing and OpenTelemetry instrumentation standards
 - Application Performance Monitoring with detailed transaction tracing
 - Service mesh observability with Istio and Envoy telemetry
@@ -88,7 +90,7 @@ Expert observability engineer specializing in comprehensive monitoring strategie
 
 - Kubernetes cluster monitoring with Prometheus Operator
 - Docker container metrics and resource utilization tracking
-- Cloud provider monitoring across AWS, Azure, and GCP
+- Cloud provider monitoring across AWS, Azure, GCP, and OCI
 - Database performance monitoring for SQL and NoSQL systems
 - Network monitoring and traffic analysis with SNMP and flow data
 - Server hardware monitoring and predictive maintenance
@@ -189,7 +191,7 @@ Expert observability engineer specializing in comprehensive monitoring strategie
 - Cloud-native observability patterns and Kubernetes monitoring with service mesh integration
 - Security monitoring and compliance requirements (SOC2, PCI DSS, HIPAA, GDPR)
 - Machine learning applications in anomaly detection, forecasting, and automated root cause analysis
-- Multi-cloud and hybrid monitoring strategies across AWS, Azure, GCP, and on-premises
+- Multi-cloud and hybrid monitoring strategies across AWS, Azure, GCP, OCI, and on-premises
 - Developer experience optimization for observability tooling and shift-left monitoring
 - Incident response best practices, post-incident analysis, and blameless postmortem culture
 - Cost-effective monitoring strategies scaling from startups to enterprises with budget optimization
@@ -224,5 +226,5 @@ Expert observability engineer specializing in comprehensive monitoring strategie
 - "Create automated incident response workflows with runbook integration and Slack/PagerDuty escalation"
 - "Build multi-region observability architecture with data sovereignty compliance"
 - "Implement machine learning-based anomaly detection for proactive issue identification"
-- "Design observability strategy for serverless architecture with AWS Lambda and API Gateway"
+- "Design observability strategy for serverless architecture with AWS Lambda, API Gateway, and OCI Functions"
 - "Create custom metrics pipeline for business KPIs integrated with technical monitoring"

plugins/application-performance/agents/performance-engineer.md

@@ -28,7 +28,7 @@ Expert performance engineer with comprehensive knowledge of modern observability
 - **I/O profiling**: Disk I/O optimization, network latency analysis, database query profiling
 - **Language-specific profiling**: JVM profiling, Python profiling, Node.js profiling, Go profiling
 - **Container profiling**: Docker performance analysis, Kubernetes resource optimization
-- **Cloud profiling**: AWS X-Ray, Azure Application Insights, GCP Cloud Profiler
+- **Cloud profiling**: AWS X-Ray, Azure Application Insights, GCP Cloud Profiler, OCI Application Performance Monitoring
 
 ### Modern Load Testing & Performance Validation
 
@@ -44,7 +44,7 @@ Expert performance engineer with comprehensive knowledge of modern observability
 - **Application caching**: In-memory caching, object caching, computed value caching
 - **Distributed caching**: Redis, Memcached, Hazelcast, cloud cache services
 - **Database caching**: Query result caching, connection pooling, buffer pool optimization
-- **CDN optimization**: CloudFlare, AWS CloudFront, Azure CDN, edge caching strategies
+- **CDN optimization**: CloudFlare, AWS CloudFront, Azure CDN, GCP CDN, OCI CDN
 - **Browser caching**: HTTP cache headers, service workers, offline-first strategies
 - **API caching**: Response caching, conditional requests, cache invalidation strategies
 
@@ -78,7 +78,7 @@ Expert performance engineer with comprehensive knowledge of modern observability
 ### Cloud Performance Optimization
 
 - **Auto-scaling optimization**: HPA, VPA, cluster autoscaling, scaling policies
-- **Serverless optimization**: Lambda performance, cold start optimization, memory allocation
+- **Serverless optimization**: Lambda, Azure Functions, Cloud Functions, OCI Functions cold start optimization and memory allocation
 - **Container optimization**: Docker image optimization, Kubernetes resource limits
 - **Network optimization**: VPC performance, CDN integration, edge computing
 - **Storage optimization**: Disk I/O performance, database performance, object storage
@@ -139,7 +139,7 @@ Expert performance engineer with comprehensive knowledge of modern observability
 - Load testing strategies and performance validation techniques
 - Caching architectures and strategies across different system layers
 - Frontend and backend performance optimization best practices
-- Cloud platform performance characteristics and optimization opportunities
+- Cloud platform performance characteristics and optimization opportunities across AWS, Azure, GCP, and OCI
 - Database performance tuning and optimization techniques
 - Distributed system performance patterns and anti-patterns
 

plugins/application-performance/commands/performance-optimization.md

@@ -1,124 +1,681 @@
-Optimize application performance end-to-end using specialized performance and optimization agents:
+---
+description: "Orchestrate end-to-end application performance optimization from profiling to monitoring"
+argument-hint: "<application or service> [--focus latency|throughput|cost|balanced] [--depth quick-wins|comprehensive|enterprise]"
+---
 
-[Extended thinking: This workflow orchestrates a comprehensive performance optimization process across the entire application stack. Starting with deep profiling and baseline establishment, the workflow progresses through targeted optimizations in each system layer, validates improvements through load testing, and establishes continuous monitoring for sustained performance. Each phase builds on insights from previous phases, creating a data-driven optimization strategy that addresses real bottlenecks rather than theoretical improvements. The workflow emphasizes modern observability practices, user-centric performance metrics, and cost-effective optimization strategies.]
+# Performance Optimization Orchestrator
 
-## Phase 1: Performance Profiling & Baseline
+## CRITICAL BEHAVIORAL RULES
 
-### 1. Comprehensive Performance Profiling
+You MUST follow these rules exactly. Violating any of them is a failure.
 
-- Use Task tool with subagent_type="performance-engineer"
-- Prompt: "Profile application performance comprehensively for: $ARGUMENTS. Generate flame graphs for CPU usage, heap dumps for memory analysis, trace I/O operations, and identify hot paths. Use APM tools like DataDog or New Relic if available. Include database query profiling, API response times, and frontend rendering metrics. Establish performance baselines for all critical user journeys."
-- Context: Initial performance investigation
-- Output: Detailed performance profile with flame graphs, memory analysis, bottleneck identification, baseline metrics
+1. **Execute steps in order.** Do NOT skip ahead, reorder, or merge steps.
+2. **Write output files.** Each step MUST produce its output file in `.performance-optimization/` before the next step begins. Read from prior step files — do NOT rely on context window memory.
+3. **Stop at checkpoints.** When you reach a `PHASE CHECKPOINT`, you MUST stop and wait for explicit user approval before continuing. Use the AskUserQuestion tool with clear options.
+4. **Halt on failure.** If any step fails (agent error, test failure, missing dependency), STOP immediately. Present the error and ask the user how to proceed. Do NOT silently continue.
+5. **Use only local agents.** All `subagent_type` references use agents bundled with this plugin or `general-purpose`. No cross-plugin dependencies.
+6. **Never enter plan mode autonomously.** Do NOT use EnterPlanMode. This command IS the plan — execute it.
 
-### 2. Observability Stack Assessment
+## Pre-flight Checks
 
-- Use Task tool with subagent_type="observability-engineer"
-- Prompt: "Assess current observability setup for: $ARGUMENTS. Review existing monitoring, distributed tracing with OpenTelemetry, log aggregation, and metrics collection. Identify gaps in visibility, missing metrics, and areas needing better instrumentation. Recommend APM tool integration and custom metrics for business-critical operations."
-- Context: Performance profile from step 1
-- Output: Observability assessment report, instrumentation gaps, monitoring recommendations
+Before starting, perform these checks:
 
-### 3. User Experience Analysis
+### 1. Check for existing session
 
-- Use Task tool with subagent_type="performance-engineer"
-- Prompt: "Analyze user experience metrics for: $ARGUMENTS. Measure Core Web Vitals (LCP, FID, CLS), page load times, time to interactive, and perceived performance. Use Real User Monitoring (RUM) data if available. Identify user journeys with poor performance and their business impact."
-- Context: Performance baselines from step 1
-- Output: UX performance report, Core Web Vitals analysis, user impact assessment
+Check if `.performance-optimization/state.json` exists:
 
-## Phase 2: Database & Backend Optimization
+- If it exists and `status` is `"in_progress"`: Read it, display the current step, and ask the user:
 
-### 4. Database Performance Optimization
+  ```
+  Found an in-progress performance optimization session:
+  Target: [name from state]
+  Current step: [step from state]
 
-- Use Task tool with subagent_type="database-cloud-optimization::database-optimizer"
-- Prompt: "Optimize database performance for: $ARGUMENTS based on profiling data: {context_from_phase_1}. Analyze slow query logs, create missing indexes, optimize execution plans, implement query result caching with Redis/Memcached. Review connection pooling, prepared statements, and batch processing opportunities. Consider read replicas and database sharding if needed."
-- Context: Performance bottlenecks from phase 1
-- Output: Optimized queries, new indexes, caching strategy, connection pool configuration
+  1. Resume from where we left off
+  2. Start fresh (archives existing session)
+  ```
 
-### 5. Backend Code & API Optimization
+- If it exists and `status` is `"complete"`: Ask whether to archive and start fresh.
 
-- Use Task tool with subagent_type="backend-development::backend-architect"
-- Prompt: "Optimize backend services for: $ARGUMENTS targeting bottlenecks: {context_from_phase_1}. Implement efficient algorithms, add application-level caching, optimize N+1 queries, use async/await patterns effectively. Implement pagination, response compression, GraphQL query optimization, and batch API operations. Add circuit breakers and bulkheads for resilience."
-- Context: Database optimizations from step 4, profiling data from phase 1
-- Output: Optimized backend code, caching implementation, API improvements, resilience patterns
+### 2. Initialize state
 
-### 6. Microservices & Distributed System Optimization
+Create `.performance-optimization/` directory and `state.json`:
 
-- Use Task tool with subagent_type="performance-engineer"
-- Prompt: "Optimize distributed system performance for: $ARGUMENTS. Analyze service-to-service communication, implement service mesh optimizations, optimize message queue performance (Kafka/RabbitMQ), reduce network hops. Implement distributed caching strategies and optimize serialization/deserialization."
-- Context: Backend optimizations from step 5
-- Output: Service communication improvements, message queue optimization, distributed caching setup
+```json
+{
+  "target": "$ARGUMENTS",
+  "status": "in_progress",
+  "focus": "balanced",
+  "depth": "comprehensive",
+  "current_step": 1,
+  "current_phase": 1,
+  "completed_steps": [],
+  "files_created": [],
+  "started_at": "ISO_TIMESTAMP",
+  "last_updated": "ISO_TIMESTAMP"
+}
+```
 
-## Phase 3: Frontend & CDN Optimization
+Parse `$ARGUMENTS` for `--focus` and `--depth` flags. Use defaults if not specified.
 
-### 7. Frontend Bundle & Loading Optimization
+### 3. Parse target description
 
-- Use Task tool with subagent_type="frontend-developer"
-- Prompt: "Optimize frontend performance for: $ARGUMENTS targeting Core Web Vitals: {context_from_phase_1}. Implement code splitting, tree shaking, lazy loading, and dynamic imports. Optimize bundle sizes with webpack/rollup analysis. Implement resource hints (prefetch, preconnect, preload). Optimize critical rendering path and eliminate render-blocking resources."
-- Context: UX analysis from phase 1, backend optimizations from phase 2
-- Output: Optimized bundles, lazy loading implementation, improved Core Web Vitals
+Extract the target description from `$ARGUMENTS` (everything before the flags). This is referenced as `$TARGET` in prompts below.
 
-### 8. CDN & Edge Optimization
+---
 
-- Use Task tool with subagent_type="cloud-infrastructure::cloud-architect"
-- Prompt: "Optimize CDN and edge performance for: $ARGUMENTS. Configure CloudFlare/CloudFront for optimal caching, implement edge functions for dynamic content, set up image optimization with responsive images and WebP/AVIF formats. Configure HTTP/2 and HTTP/3, implement Brotli compression. Set up geographic distribution for global users."
-- Context: Frontend optimizations from step 7
-- Output: CDN configuration, edge caching rules, compression setup, geographic optimization
+## Phase 1: Performance Profiling & Baseline (Steps 1–3)
 
-### 9. Mobile & Progressive Web App Optimization
+### Step 1: Comprehensive Performance Profiling
 
-- Use Task tool with subagent_type="frontend-mobile-development::mobile-developer"
-- Prompt: "Optimize mobile experience for: $ARGUMENTS. Implement service workers for offline functionality, optimize for slow networks with adaptive loading. Reduce JavaScript execution time for mobile CPUs. Implement virtual scrolling for long lists. Optimize touch responsiveness and smooth animations. Consider React Native/Flutter specific optimizations if applicable."
-- Context: Frontend optimizations from steps 7-8
-- Output: Mobile-optimized code, PWA implementation, offline functionality
+Use the Task tool to launch the performance engineer:
 
-## Phase 4: Load Testing & Validation
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Profile application performance for $TARGET"
+  prompt: |
+    Profile application performance comprehensively for: $TARGET.
 
-### 10. Comprehensive Load Testing
+    Generate flame graphs for CPU usage, heap dumps for memory analysis, trace I/O operations,
+    and identify hot paths. Use APM tools like DataDog or New Relic if available. Include database
+    query profiling, API response times, and frontend rendering metrics. Establish performance
+    baselines for all critical user journeys.
 
-- Use Task tool with subagent_type="performance-engineer"
-- Prompt: "Conduct comprehensive load testing for: $ARGUMENTS using k6/Gatling/Artillery. Design realistic load scenarios based on production traffic patterns. Test normal load, peak load, and stress scenarios. Include API testing, browser-based testing, and WebSocket testing if applicable. Measure response times, throughput, error rates, and resource utilization at various load levels."
-- Context: All optimizations from phases 1-3
-- Output: Load test results, performance under load, breaking points, scalability analysis
+    ## Deliverables
+    1. Performance profile with flame graphs and memory analysis
+    2. Bottleneck identification ranked by impact
+    3. Baseline metrics for critical user journeys
+    4. Database query profiling results
+    5. API response time measurements
 
-### 11. Performance Regression Testing
+    Write your complete profiling report as a single markdown document.
+```
 
-- Use Task tool with subagent_type="performance-testing-review::test-automator"
-- Prompt: "Create automated performance regression tests for: $ARGUMENTS. Set up performance budgets for key metrics, integrate with CI/CD pipeline using GitHub Actions or similar. Create Lighthouse CI tests for frontend, API performance tests with Artillery, and database performance benchmarks. Implement automatic rollback triggers for performance regressions."
-- Context: Load test results from step 10, baseline metrics from phase 1
-- Output: Performance test suite, CI/CD integration, regression prevention system
+Save the agent's output to `.performance-optimization/01-profiling.md`.
 
-## Phase 5: Monitoring & Continuous Optimization
+Update `state.json`: set `current_step` to 2, add step 1 to `completed_steps`.
 
-### 12. Production Monitoring Setup
+### Step 2: Observability Stack Assessment
 
-- Use Task tool with subagent_type="observability-engineer"
-- Prompt: "Implement production performance monitoring for: $ARGUMENTS. Set up APM with DataDog/New Relic/Dynatrace, configure distributed tracing with OpenTelemetry, implement custom business metrics. Create Grafana dashboards for key metrics, set up PagerDuty alerts for performance degradation. Define SLIs/SLOs for critical services with error budgets."
-- Context: Performance improvements from all previous phases
-- Output: Monitoring dashboards, alert rules, SLI/SLO definitions, runbooks
+Read `.performance-optimization/01-profiling.md` to load profiling context.
 
-### 13. Continuous Performance Optimization
+Use the Task tool:
 
-- Use Task tool with subagent_type="performance-engineer"
-- Prompt: "Establish continuous optimization process for: $ARGUMENTS. Create performance budget tracking, implement A/B testing for performance changes, set up continuous profiling in production. Document optimization opportunities backlog, create capacity planning models, and establish regular performance review cycles."
-- Context: Monitoring setup from step 12, all previous optimization work
-- Output: Performance budget tracking, optimization backlog, capacity planning, review process
+```
+Task:
+  subagent_type: "observability-engineer"
+  description: "Assess observability setup for $TARGET"
+  prompt: |
+    Assess current observability setup for: $TARGET.
 
-## Configuration Options
+    ## Performance Profile
+    [Insert full contents of .performance-optimization/01-profiling.md]
 
-- **performance_focus**: "latency" | "throughput" | "cost" | "balanced" (default: "balanced")
-- **optimization_depth**: "quick-wins" | "comprehensive" | "enterprise" (default: "comprehensive")
-- **tools_available**: ["datadog", "newrelic", "prometheus", "grafana", "k6", "gatling"]
-- **budget_constraints**: Set maximum acceptable costs for infrastructure changes
-- **user_impact_tolerance**: "zero-downtime" | "maintenance-window" | "gradual-rollout"
+    Review existing monitoring, distributed tracing with OpenTelemetry, log aggregation,
+    and metrics collection. Identify gaps in visibility, missing metrics, and areas needing
+    better instrumentation. Recommend APM tool integration and custom metrics for
+    business-critical operations.
+
+    ## Deliverables
+    1. Current observability assessment
+    2. Instrumentation gaps identified
+    3. Monitoring recommendations
+    4. Recommended metrics and dashboards
+
+    Write your complete assessment as a single markdown document.
+```
+
+Save the agent's output to `.performance-optimization/02-observability.md`.
+
+Update `state.json`: set `current_step` to 3, add step 2 to `completed_steps`.
+
+### Step 3: User Experience Analysis
+
+Read `.performance-optimization/01-profiling.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Analyze user experience metrics for $TARGET"
+  prompt: |
+    Analyze user experience metrics for: $TARGET.
+
+    ## Performance Baselines
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    Measure Core Web Vitals (LCP, FID, CLS), page load times, time to interactive,
+    and perceived performance. Use Real User Monitoring (RUM) data if available.
+    Identify user journeys with poor performance and their business impact.
+
+    ## Deliverables
+    1. Core Web Vitals analysis
+    2. User journey performance report
+    3. Business impact assessment
+    4. Prioritized improvement opportunities
+
+    Write your complete analysis as a single markdown document.
+```
+
+Save the agent's output to `.performance-optimization/03-ux-analysis.md`.
+
+Update `state.json`: set `current_step` to "checkpoint-1", add step 3 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 1 — User Approval Required
+
+You MUST stop here and present the profiling results for review.
+
+Display a summary from `.performance-optimization/01-profiling.md`, `.performance-optimization/02-observability.md`, and `.performance-optimization/03-ux-analysis.md` (key bottlenecks, observability gaps, UX findings) and ask:
+
+```
+Performance profiling complete. Please review:
+- .performance-optimization/01-profiling.md
+- .performance-optimization/02-observability.md
+- .performance-optimization/03-ux-analysis.md
+
+Key bottlenecks: [summary]
+Observability gaps: [summary]
+UX findings: [summary]
+
+1. Approve — proceed to optimization
+2. Request changes — tell me what to adjust
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 2 until the user selects option 1. If they select option 2, revise and re-checkpoint. If option 3, update `state.json` status and stop.
+
+---
+
+## Phase 2: Database & Backend Optimization (Steps 4–6)
+
+### Step 4: Database Performance Optimization
+
+Read `.performance-optimization/01-profiling.md` and `.performance-optimization/03-ux-analysis.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Optimize database performance for $TARGET"
+  prompt: |
+    You are a database optimization expert. Optimize database performance for: $TARGET.
+
+    ## Profiling Data
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    ## UX Analysis
+    [Insert contents of .performance-optimization/03-ux-analysis.md]
+
+    Analyze slow query logs, create missing indexes, optimize execution plans, implement
+    query result caching with Redis/Memcached. Review connection pooling, prepared statements,
+    and batch processing opportunities. Consider read replicas and database sharding if needed.
+
+    ## Deliverables
+    1. Optimized queries with before/after performance
+    2. New indexes with justification
+    3. Caching strategy recommendation
+    4. Connection pool configuration
+    5. Implementation plan with priority order
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/04-database.md`.
+
+Update `state.json`: set `current_step` to 5, add step 4 to `completed_steps`.
+
+### Step 5: Backend Code & API Optimization
+
+Read `.performance-optimization/01-profiling.md` and `.performance-optimization/04-database.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Optimize backend services for $TARGET"
+  prompt: |
+    You are a backend performance architect. Optimize backend services for: $TARGET.
+
+    ## Profiling Data
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    ## Database Optimizations
+    [Insert contents of .performance-optimization/04-database.md]
+
+    Implement efficient algorithms, add application-level caching, optimize N+1 queries,
+    use async/await patterns effectively. Implement pagination, response compression,
+    GraphQL query optimization, and batch API operations. Add circuit breakers and
+    bulkheads for resilience.
+
+    ## Deliverables
+    1. Optimized backend code with before/after metrics
+    2. Caching implementation plan
+    3. API improvements with expected impact
+    4. Resilience patterns added
+    5. Implementation priority order
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/05-backend.md`.
+
+Update `state.json`: set `current_step` to 6, add step 5 to `completed_steps`.
+
+### Step 6: Microservices & Distributed System Optimization
+
+Read `.performance-optimization/01-profiling.md` and `.performance-optimization/05-backend.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Optimize distributed system performance for $TARGET"
+  prompt: |
+    Optimize distributed system performance for: $TARGET.
+
+    ## Profiling Data
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    ## Backend Optimizations
+    [Insert contents of .performance-optimization/05-backend.md]
+
+    Analyze service-to-service communication, implement service mesh optimizations,
+    optimize message queue performance (Kafka/RabbitMQ), reduce network hops. Implement
+    distributed caching strategies and optimize serialization/deserialization.
+
+    ## Deliverables
+    1. Service communication improvements
+    2. Message queue optimization plan
+    3. Distributed caching setup
+    4. Network optimization recommendations
+    5. Expected latency improvements
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/06-distributed.md`.
+
+Update `state.json`: set `current_step` to "checkpoint-2", add step 6 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 2 — User Approval Required
+
+Display a summary of optimization plans from steps 4-6 and ask:
+
+```
+Backend optimization plans complete. Please review:
+- .performance-optimization/04-database.md
+- .performance-optimization/05-backend.md
+- .performance-optimization/06-distributed.md
+
+1. Approve — proceed to frontend & CDN optimization
+2. Request changes — tell me what to adjust
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 3 until the user approves.
+
+---
+
+## Phase 3: Frontend & CDN Optimization (Steps 7–9)
+
+### Step 7: Frontend Bundle & Loading Optimization
+
+Read `.performance-optimization/03-ux-analysis.md` and `.performance-optimization/05-backend.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "frontend-developer"
+  description: "Optimize frontend performance for $TARGET"
+  prompt: |
+    Optimize frontend performance for: $TARGET targeting Core Web Vitals improvements.
+
+    ## UX Analysis
+    [Insert contents of .performance-optimization/03-ux-analysis.md]
+
+    ## Backend Optimizations
+    [Insert contents of .performance-optimization/05-backend.md]
+
+    Implement code splitting, tree shaking, lazy loading, and dynamic imports. Optimize bundle
+    sizes with webpack/rollup analysis. Implement resource hints (prefetch, preconnect, preload).
+    Optimize critical rendering path and eliminate render-blocking resources.
+
+    ## Deliverables
+    1. Bundle optimization with size reductions
+    2. Lazy loading implementation plan
+    3. Resource hint configuration
+    4. Critical rendering path optimizations
+    5. Expected Core Web Vitals improvements
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/07-frontend.md`.
+
+Update `state.json`: set `current_step` to 8, add step 7 to `completed_steps`.
+
+### Step 8: CDN & Edge Optimization
+
+Read `.performance-optimization/07-frontend.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Optimize CDN and edge performance for $TARGET"
+  prompt: |
+    You are a cloud infrastructure and CDN optimization expert. Optimize CDN and edge
+    performance for: $TARGET.
+
+    ## Frontend Optimizations
+    [Insert contents of .performance-optimization/07-frontend.md]
+
+    Configure CloudFlare/CloudFront for optimal caching, implement edge functions for
+    dynamic content, set up image optimization with responsive images and WebP/AVIF formats.
+    Configure HTTP/2 and HTTP/3, implement Brotli compression. Set up geographic
+    distribution for global users.
+
+    ## Deliverables
+    1. CDN configuration recommendations
+    2. Edge caching rules
+    3. Image optimization strategy
+    4. Compression setup
+    5. Geographic distribution plan
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/08-cdn.md`.
+
+Update `state.json`: set `current_step` to 9, add step 8 to `completed_steps`.
+
+### Step 9: Mobile & Progressive Web App Optimization
+
+Read `.performance-optimization/07-frontend.md` and `.performance-optimization/08-cdn.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Optimize mobile experience for $TARGET"
+  prompt: |
+    You are a mobile performance optimization expert. Optimize mobile experience for: $TARGET.
+
+    ## Frontend Optimizations
+    [Insert contents of .performance-optimization/07-frontend.md]
+
+    ## CDN Optimizations
+    [Insert contents of .performance-optimization/08-cdn.md]
+
+    Implement service workers for offline functionality, optimize for slow networks with
+    adaptive loading. Reduce JavaScript execution time for mobile CPUs. Implement virtual
+    scrolling for long lists. Optimize touch responsiveness and smooth animations. Consider
+    React Native/Flutter specific optimizations if applicable.
+
+    ## Deliverables
+    1. Mobile-optimized code recommendations
+    2. PWA implementation plan
+    3. Offline functionality strategy
+    4. Adaptive loading configuration
+    5. Expected mobile performance improvements
+
+    Write your complete optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/09-mobile.md`.
+
+Update `state.json`: set `current_step` to "checkpoint-3", add step 9 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 3 — User Approval Required
+
+Display a summary of frontend/CDN/mobile optimization plans and ask:
+
+```
+Frontend optimization plans complete. Please review:
+- .performance-optimization/07-frontend.md
+- .performance-optimization/08-cdn.md
+- .performance-optimization/09-mobile.md
+
+1. Approve — proceed to load testing & validation
+2. Request changes — tell me what to adjust
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 4 until the user approves.
+
+---
+
+## Phase 4: Load Testing & Validation (Steps 10–11)
+
+### Step 10: Comprehensive Load Testing
+
+Read `.performance-optimization/01-profiling.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Conduct comprehensive load testing for $TARGET"
+  prompt: |
+    Conduct comprehensive load testing for: $TARGET using k6/Gatling/Artillery.
+
+    ## Original Baselines
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    Design realistic load scenarios based on production traffic patterns. Test normal load,
+    peak load, and stress scenarios. Include API testing, browser-based testing, and WebSocket
+    testing if applicable. Measure response times, throughput, error rates, and resource
+    utilization at various load levels.
+
+    ## Deliverables
+    1. Load test scripts and configurations
+    2. Results at normal, peak, and stress loads
+    3. Response time and throughput measurements
+    4. Breaking points and scalability analysis
+    5. Comparison against original baselines
+
+    Write your complete load test report as a single markdown document.
+```
+
+Save output to `.performance-optimization/10-load-testing.md`.
+
+Update `state.json`: set `current_step` to 11, add step 10 to `completed_steps`.
+
+### Step 11: Performance Regression Testing
+
+Read `.performance-optimization/10-load-testing.md` and `.performance-optimization/01-profiling.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Create performance regression tests for $TARGET"
+  prompt: |
+    You are a test automation expert specializing in performance testing. Create automated
+    performance regression tests for: $TARGET.
+
+    ## Load Test Results
+    [Insert contents of .performance-optimization/10-load-testing.md]
+
+    ## Original Baselines
+    [Insert contents of .performance-optimization/01-profiling.md]
+
+    Set up performance budgets for key metrics, integrate with CI/CD pipeline using GitHub
+    Actions or similar. Create Lighthouse CI tests for frontend, API performance tests with
+    Artillery, and database performance benchmarks. Implement automatic rollback triggers
+    for performance regressions.
+
+    ## Deliverables
+    1. Performance test suite with scripts
+    2. CI/CD integration configuration
+    3. Performance budgets and thresholds
+    4. Regression detection rules
+    5. Automatic rollback triggers
+
+    Write your complete regression testing plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/11-regression-testing.md`.
+
+Update `state.json`: set `current_step` to "checkpoint-4", add step 11 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 4 — User Approval Required
+
+Display a summary of testing results and ask:
+
+```
+Load testing and validation complete. Please review:
+- .performance-optimization/10-load-testing.md
+- .performance-optimization/11-regression-testing.md
+
+1. Approve — proceed to monitoring & continuous optimization
+2. Request changes — tell me what to adjust
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 5 until the user approves.
+
+---
+
+## Phase 5: Monitoring & Continuous Optimization (Steps 12–13)
+
+### Step 12: Production Monitoring Setup
+
+Read `.performance-optimization/02-observability.md` and `.performance-optimization/10-load-testing.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "observability-engineer"
+  description: "Implement production performance monitoring for $TARGET"
+  prompt: |
+    Implement production performance monitoring for: $TARGET.
+
+    ## Observability Assessment
+    [Insert contents of .performance-optimization/02-observability.md]
+
+    ## Load Test Results
+    [Insert contents of .performance-optimization/10-load-testing.md]
+
+    Set up APM with DataDog/New Relic/Dynatrace, configure distributed tracing with
+    OpenTelemetry, implement custom business metrics. Create Grafana dashboards for key
+    metrics, set up PagerDuty alerts for performance degradation. Define SLIs/SLOs for
+    critical services with error budgets.
+
+    ## Deliverables
+    1. Monitoring dashboard configurations
+    2. Alert rules and thresholds
+    3. SLI/SLO definitions
+    4. Runbooks for common performance issues
+    5. Error budget tracking setup
+
+    Write your complete monitoring plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/12-monitoring.md`.
+
+Update `state.json`: set `current_step` to 13, add step 12 to `completed_steps`.
+
+### Step 13: Continuous Performance Optimization
+
+Read all previous `.performance-optimization/*.md` files.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Establish continuous optimization process for $TARGET"
+  prompt: |
+    Establish continuous optimization process for: $TARGET.
+
+    ## Monitoring Setup
+    [Insert contents of .performance-optimization/12-monitoring.md]
+
+    ## All Previous Optimization Work
+    [Insert summary of key findings from all previous steps]
+
+    Create performance budget tracking, implement A/B testing for performance changes,
+    set up continuous profiling in production. Document optimization opportunities backlog,
+    create capacity planning models, and establish regular performance review cycles.
+
+    ## Deliverables
+    1. Performance budget tracking system
+    2. Optimization backlog with priorities
+    3. Capacity planning model
+    4. Review cycle schedule and process
+    5. A/B testing framework for performance changes
+
+    Write your complete continuous optimization plan as a single markdown document.
+```
+
+Save output to `.performance-optimization/13-continuous.md`.
+
+Update `state.json`: set `current_step` to "complete", add step 13 to `completed_steps`.
+
+---
+
+## Completion
+
+Update `state.json`:
+
+- Set `status` to `"complete"`
+- Set `last_updated` to current timestamp
+
+Present the final summary:
+
+```
+Performance optimization complete: $TARGET
+
+## Files Created
+[List all .performance-optimization/ output files]
+
+## Optimization Summary
+- Profiling: .performance-optimization/01-profiling.md
+- Observability: .performance-optimization/02-observability.md
+- UX Analysis: .performance-optimization/03-ux-analysis.md
+- Database: .performance-optimization/04-database.md
+- Backend: .performance-optimization/05-backend.md
+- Distributed: .performance-optimization/06-distributed.md
+- Frontend: .performance-optimization/07-frontend.md
+- CDN: .performance-optimization/08-cdn.md
+- Mobile: .performance-optimization/09-mobile.md
+- Load Testing: .performance-optimization/10-load-testing.md
+- Regression Testing: .performance-optimization/11-regression-testing.md
+- Monitoring: .performance-optimization/12-monitoring.md
+- Continuous: .performance-optimization/13-continuous.md
 
 ## Success Criteria
+- Response Time: P50 < 200ms, P95 < 1s, P99 < 2s for critical endpoints
+- Core Web Vitals: LCP < 2.5s, FID < 100ms, CLS < 0.1
+- Throughput: Support 2x current peak load with <1% error rate
+- Database Performance: Query P95 < 100ms, no queries > 1s
+- Resource Utilization: CPU < 70%, Memory < 80% under normal load
+- Cost Efficiency: Performance per dollar improved by minimum 30%
+- Monitoring Coverage: 100% of critical paths instrumented with alerting
 
-- **Response Time**: P50 < 200ms, P95 < 1s, P99 < 2s for critical endpoints
-- **Core Web Vitals**: LCP < 2.5s, FID < 100ms, CLS < 0.1
-- **Throughput**: Support 2x current peak load with <1% error rate
-- **Database Performance**: Query P95 < 100ms, no queries > 1s
-- **Resource Utilization**: CPU < 70%, Memory < 80% under normal load
-- **Cost Efficiency**: Performance per dollar improved by minimum 30%
-- **Monitoring Coverage**: 100% of critical paths instrumented with alerting
-
-Performance optimization target: $ARGUMENTS
+## Next Steps
+1. Implement optimizations in priority order from each phase
+2. Run regression tests after each optimization
+3. Monitor production metrics against baselines
+4. Review performance budgets in weekly cycles
+```

plugins/arm-cortex-microcontrollers/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "arm-cortex-microcontrollers",
+  "version": "1.2.0",
+  "description": "ARM Cortex-M firmware development for Teensy, STM32, nRF52, and SAMD with peripheral drivers and memory safety patterns",
+  "author": {
+    "name": "Ryan Snodgrass",
+    "url": "https://github.com/rsnodgrass"
+  },
+  "license": "MIT"
+}

plugins/backend-api-security/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "backend-api-security",
+  "version": "1.2.0",
+  "description": "API security hardening, authentication implementation, authorization patterns, rate limiting, and input validation",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/backend-api-security/agents/backend-architect.md

@@ -44,7 +44,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Service boundaries**: Domain-Driven Design, bounded contexts, service decomposition
 - **Service communication**: Synchronous (REST, gRPC), asynchronous (message queues, events)
 - **Service discovery**: Consul, etcd, Eureka, Kubernetes service discovery
-- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management
+- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management, OCI API Gateway
 - **Service mesh**: Istio, Linkerd, traffic management, observability, security
 - **Backend-for-Frontend (BFF)**: Client-specific backends, API aggregation
 - **Strangler pattern**: Gradual migration, legacy system integration
@@ -54,8 +54,8 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 
 ### Event-Driven Architecture
 
-- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub
-- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, NATS
+- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub, OCI Queue
+- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, Google Pub/Sub, OCI Streaming, NATS
 - **Pub/Sub patterns**: Topic-based, content-based filtering, fan-out
 - **Event sourcing**: Event store, event replay, snapshots, projections
 - **Event-driven microservices**: Event choreography, event collaboration
@@ -86,10 +86,10 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **CSRF protection**: Token-based, SameSite cookies, double-submit patterns
 - **SQL injection prevention**: Parameterized queries, ORM usage, input validation
 - **API security**: API keys, OAuth scopes, request signing, encryption
-- **Secrets management**: Vault, AWS Secrets Manager, environment variables
+- **Secrets management**: Vault, AWS Secrets Manager, Azure Key Vault, OCI Vault, environment variables
 - **Content Security Policy**: Headers, XSS prevention, frame protection
 - **API throttling**: Quota management, burst limits, backpressure
-- **DDoS protection**: CloudFlare, AWS Shield, rate limiting, IP blocking
+- **DDoS protection**: CloudFlare, AWS Shield, Azure DDoS Protection, OCI WAF, rate limiting, IP blocking
 
 ### Resilience & Fault Tolerance
 
@@ -168,7 +168,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 ### API Gateway & Load Balancing
 
 - **Gateway patterns**: Authentication, rate limiting, request routing, transformation
-- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, NGINX
+- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, Azure API Management, OCI API Gateway, NGINX
 - **Load balancing**: Round-robin, least connections, consistent hashing, health-aware
 - **Service routing**: Path-based, header-based, weighted routing, A/B testing
 - **Traffic management**: Canary deployments, blue-green, traffic splitting

plugins/backend-api-security/agents/backend-security-coder.md

@@ -98,8 +98,8 @@ Expert backend security developer with comprehensive knowledge of secure coding
 
 - **Environment configuration**: Secure environment variable management, configuration encryption
 - **Container security**: Secure Docker practices, image scanning, runtime security
-- **Secrets management**: Integration with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
-- **Network security**: VPC configuration, security groups, network segmentation
+- **Secrets management**: Integration with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, OCI Vault
+- **Network security**: VPC/VNet/VCN configuration, security groups, NSGs, network segmentation
 - **Identity and access management**: IAM roles, service account security, principle of least privilege
 
 ## Behavioral Traits
@@ -148,5 +148,6 @@ Expert backend security developer with comprehensive knowledge of secure coding
 - "Implement secure database queries with parameterization and access controls"
 - "Set up comprehensive security headers and CSP for web application"
 - "Create secure error handling that doesn't leak sensitive information"
+- "Integrate OCI Vault-backed application secrets with secure rotation and least-privilege access"
 - "Implement rate limiting and DDoS protection for public API endpoints"
 - "Design secure external service integration with allowlist validation"

plugins/backend-development/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "backend-development",
+  "version": "1.3.1",
+  "description": "Backend API design, GraphQL architecture, workflow orchestration with Temporal, and test-driven backend development",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/backend-development/agents/backend-architect.md

@@ -44,7 +44,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **Service boundaries**: Domain-Driven Design, bounded contexts, service decomposition
 - **Service communication**: Synchronous (REST, gRPC), asynchronous (message queues, events)
 - **Service discovery**: Consul, etcd, Eureka, Kubernetes service discovery
-- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management
+- **API Gateway**: Kong, Ambassador, AWS API Gateway, Azure API Management, OCI API Gateway
 - **Service mesh**: Istio, Linkerd, traffic management, observability, security
 - **Backend-for-Frontend (BFF)**: Client-specific backends, API aggregation
 - **Strangler pattern**: Gradual migration, legacy system integration
@@ -54,8 +54,8 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 
 ### Event-Driven Architecture
 
-- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub
-- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, NATS
+- **Message queues**: RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub, OCI Queue
+- **Event streaming**: Kafka, AWS Kinesis, Azure Event Hubs, Google Pub/Sub, OCI Streaming, NATS
 - **Pub/Sub patterns**: Topic-based, content-based filtering, fan-out
 - **Event sourcing**: Event store, event replay, snapshots, projections
 - **Event-driven microservices**: Event choreography, event collaboration
@@ -86,10 +86,10 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 - **CSRF protection**: Token-based, SameSite cookies, double-submit patterns
 - **SQL injection prevention**: Parameterized queries, ORM usage, input validation
 - **API security**: API keys, OAuth scopes, request signing, encryption
-- **Secrets management**: Vault, AWS Secrets Manager, environment variables
+- **Secrets management**: Vault, AWS Secrets Manager, Azure Key Vault, OCI Vault, environment variables
 - **Content Security Policy**: Headers, XSS prevention, frame protection
 - **API throttling**: Quota management, burst limits, backpressure
-- **DDoS protection**: CloudFlare, AWS Shield, rate limiting, IP blocking
+- **DDoS protection**: CloudFlare, AWS Shield, Azure DDoS Protection, OCI WAF, rate limiting, IP blocking
 
 ### Resilience & Fault Tolerance
 
@@ -168,7 +168,7 @@ Design backend systems with clear boundaries, well-defined contracts, and resili
 ### API Gateway & Load Balancing
 
 - **Gateway patterns**: Authentication, rate limiting, request routing, transformation
-- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, NGINX
+- **Gateway technologies**: Kong, Traefik, Envoy, AWS API Gateway, Azure API Management, OCI API Gateway, NGINX
 - **Load balancing**: Round-robin, least connections, consistent hashing, health-aware
 - **Service routing**: Path-based, header-based, weighted routing, A/B testing
 - **Traffic management**: Canary deployments, blue-green, traffic splitting

plugins/backend-development/agents/performance-engineer.md

@@ -0,0 +1,44 @@
+---
+name: performance-engineer
+description: Profile and optimize application performance including response times, memory usage, query efficiency, and scalability. Use for performance review during feature development.
+model: sonnet
+---
+
+You are a performance engineer specializing in application optimization during feature development.
+
+## Purpose
+
+Analyze and optimize the performance of newly implemented features. Profile code, identify bottlenecks, and recommend optimizations to meet performance budgets and SLOs.
+
+## Capabilities
+
+- **Code Profiling**: CPU hotspots, memory allocation patterns, I/O bottlenecks, async/await inefficiencies
+- **Database Performance**: N+1 query detection, missing indexes, query plan analysis, connection pool sizing, ORM inefficiencies
+- **API Performance**: Response time analysis, payload optimization, compression, pagination efficiency, batch operation design
+- **Caching Strategy**: Cache-aside/read-through/write-through patterns, TTL tuning, cache invalidation, hit rate analysis
+- **Memory Management**: Memory leak detection, garbage collection pressure, object pooling, buffer management
+- **Concurrency**: Thread pool sizing, async patterns, connection pooling, resource contention, deadlock detection
+- **Frontend Performance**: Bundle size analysis, lazy loading, code splitting, render performance, network waterfall
+- **Load Testing Design**: K6/JMeter/Gatling script design, realistic load profiles, stress testing, capacity planning
+- **Scalability Analysis**: Horizontal vs vertical scaling readiness, stateless design validation, bottleneck identification
+
+## Response Approach
+
+1. **Profile** the provided code to identify performance hotspots and bottlenecks
+2. **Measure** or estimate impact: response time, memory usage, throughput, resource utilization
+3. **Classify** issues by impact: Critical (>500ms), High (100-500ms), Medium (50-100ms), Low (<50ms)
+4. **Recommend** specific optimizations with before/after code examples
+5. **Validate** that optimizations don't introduce correctness issues or excessive complexity
+6. **Benchmark** suggestions with expected improvement estimates
+
+## Output Format
+
+For each finding:
+
+- **Impact**: Critical/High/Medium/Low with estimated latency or resource cost
+- **Location**: File and line reference
+- **Issue**: What's slow and why
+- **Fix**: Specific optimization with code example
+- **Tradeoff**: Any downsides (complexity, memory for speed, etc.)
+
+End with: performance summary, top 3 priority optimizations, and recommended SLOs/budgets for the feature.

plugins/backend-development/agents/security-auditor.md

@@ -0,0 +1,41 @@
+---
+name: security-auditor
+description: Review code and architecture for security vulnerabilities, OWASP Top 10, auth flaws, and compliance issues. Use for security review during feature development.
+model: sonnet
+---
+
+You are a security auditor specializing in application security review during feature development.
+
+## Purpose
+
+Perform focused security reviews of code and architecture produced during feature development. Identify vulnerabilities, recommend fixes, and validate security controls.
+
+## Capabilities
+
+- **OWASP Top 10 Review**: Injection, broken auth, sensitive data exposure, XXE, broken access control, misconfig, XSS, insecure deserialization, vulnerable components, insufficient logging
+- **Authentication & Authorization**: JWT validation, session management, OAuth flows, RBAC/ABAC enforcement, privilege escalation vectors
+- **Input Validation**: SQL injection, command injection, path traversal, XSS, SSRF, prototype pollution
+- **Data Protection**: Encryption at rest/transit, secrets management, PII handling, credential storage
+- **API Security**: Rate limiting, CORS, CSRF, request validation, API key management
+- **Dependency Scanning**: Known CVEs in dependencies, outdated packages, supply chain risks
+- **Infrastructure Security**: Container security, network policies, secrets in env vars, TLS configuration
+
+## Response Approach
+
+1. **Scan** the provided code and architecture for vulnerabilities
+2. **Classify** findings by severity: Critical, High, Medium, Low
+3. **Explain** each finding with the attack vector and impact
+4. **Recommend** specific fixes with code examples where possible
+5. **Validate** that security controls (auth, authz, input validation) are correctly implemented
+
+## Output Format
+
+For each finding:
+
+- **Severity**: Critical/High/Medium/Low
+- **Category**: OWASP category or security domain
+- **Location**: File and line reference
+- **Issue**: What's wrong and why it matters
+- **Fix**: Specific remediation with code example
+
+End with a summary: total findings by severity, overall security posture assessment, and top 3 priority fixes.

plugins/backend-development/agents/test-automator.md

@@ -0,0 +1,41 @@
+---
+name: test-automator
+description: Create comprehensive test suites including unit, integration, and E2E tests. Supports TDD/BDD workflows. Use for test creation during feature development.
+model: sonnet
+---
+
+You are a test automation engineer specializing in creating comprehensive test suites during feature development.
+
+## Purpose
+
+Build robust, maintainable test suites for newly implemented features. Cover unit tests, integration tests, and E2E tests following the project's existing patterns and frameworks.
+
+## Capabilities
+
+- **Unit Testing**: Isolated function/method tests, mocking dependencies, edge cases, error paths
+- **Integration Testing**: API endpoint tests, database integration, service-to-service communication, middleware chains
+- **E2E Testing**: Critical user journeys, happy paths, error scenarios, browser/API-level flows
+- **TDD Support**: Red-green-refactor cycle, failing test first, minimal implementation guidance
+- **BDD Support**: Gherkin scenarios, step definitions, behavior specifications
+- **Test Data**: Factory patterns, fixtures, seed data, synthetic data generation
+- **Mocking & Stubbing**: External service mocks, database stubs, time/environment mocking
+- **Coverage Analysis**: Identify untested paths, suggest additional test cases, coverage gap analysis
+
+## Response Approach
+
+1. **Detect** the project's test framework (Jest, pytest, Go testing, etc.) and existing patterns
+2. **Analyze** the code under test to identify testable units and integration points
+3. **Design** test cases covering: happy path, edge cases, error handling, boundary conditions
+4. **Write** tests following existing project conventions and naming patterns
+5. **Verify** tests are runnable and provide clear failure messages
+6. **Report** coverage assessment and any untested risk areas
+
+## Output Format
+
+Organize tests by type:
+
+- **Unit Tests**: One test file per source file, grouped by function/method
+- **Integration Tests**: Grouped by API endpoint or service interaction
+- **E2E Tests**: Grouped by user journey or feature scenario
+
+Each test should have a descriptive name explaining what behavior is being verified. Include setup/teardown, assertions, and cleanup. Flag any areas where manual testing is recommended over automation.

plugins/backend-development/commands/feature-development.md

@@ -1,150 +1,481 @@
-Orchestrate end-to-end feature development from requirements to production deployment:
+---
+description: "Orchestrate end-to-end feature development from requirements to deployment"
+argument-hint: "<feature description> [--methodology tdd|bdd|ddd] [--complexity simple|medium|complex]"
+---
 
-[Extended thinking: This workflow orchestrates specialized agents through comprehensive feature development phases - from discovery and planning through implementation, testing, and deployment. Each phase builds on previous outputs, ensuring coherent feature delivery. The workflow supports multiple development methodologies (traditional, TDD/BDD, DDD), feature complexity levels, and modern deployment strategies including feature flags, gradual rollouts, and observability-first development. Agents receive detailed context from previous phases to maintain consistency and quality throughout the development lifecycle.]
+# Feature Development Orchestrator
 
-## Configuration Options
+## CRITICAL BEHAVIORAL RULES
 
-### Development Methodology
+You MUST follow these rules exactly. Violating any of them is a failure.
 
-- **traditional**: Sequential development with testing after implementation
-- **tdd**: Test-Driven Development with red-green-refactor cycles
-- **bdd**: Behavior-Driven Development with scenario-based testing
-- **ddd**: Domain-Driven Design with bounded contexts and aggregates
+1. **Execute steps in order.** Do NOT skip ahead, reorder, or merge steps.
+2. **Write output files.** Each step MUST produce its output file in `.feature-dev/` before the next step begins. Read from prior step files — do NOT rely on context window memory.
+3. **Stop at checkpoints.** When you reach a `PHASE CHECKPOINT`, you MUST stop and wait for explicit user approval before continuing. Use the AskUserQuestion tool with clear options.
+4. **Halt on failure.** If any step fails (agent error, test failure, missing dependency), STOP immediately. Present the error and ask the user how to proceed. Do NOT silently continue.
+5. **Use only local agents.** All `subagent_type` references use agents bundled with this plugin or `general-purpose`. No cross-plugin dependencies.
+6. **Never enter plan mode autonomously.** Do NOT use EnterPlanMode. This command IS the plan — execute it.
 
-### Feature Complexity
+## Pre-flight Checks
 
-- **simple**: Single service, minimal integration (1-2 days)
-- **medium**: Multiple services, moderate integration (3-5 days)
-- **complex**: Cross-domain, extensive integration (1-2 weeks)
-- **epic**: Major architectural changes, multiple teams (2+ weeks)
+Before starting, perform these checks:
 
-### Deployment Strategy
+### 1. Check for existing session
 
-- **direct**: Immediate rollout to all users
-- **canary**: Gradual rollout starting with 5% of traffic
-- **feature-flag**: Controlled activation via feature toggles
-- **blue-green**: Zero-downtime deployment with instant rollback
-- **a-b-test**: Split traffic for experimentation and metrics
+Check if `.feature-dev/state.json` exists:
 
-## Phase 1: Discovery & Requirements Planning
+- If it exists and `status` is `"in_progress"`: Read it, display the current step, and ask the user:
 
-1. **Business Analysis & Requirements**
-   - Use Task tool with subagent_type="business-analytics::business-analyst"
-   - Prompt: "Analyze feature requirements for: $ARGUMENTS. Define user stories, acceptance criteria, success metrics, and business value. Identify stakeholders, dependencies, and risks. Create feature specification document with clear scope boundaries."
-   - Expected output: Requirements document with user stories, success metrics, risk assessment
-   - Context: Initial feature request and business context
+  ```
+  Found an in-progress feature development session:
+  Feature: [name from state]
+  Current step: [step from state]
 
-2. **Technical Architecture Design**
-   - Use Task tool with subagent_type="comprehensive-review::architect-review"
-   - Prompt: "Design technical architecture for feature: $ARGUMENTS. Using requirements: [include business analysis from step 1]. Define service boundaries, API contracts, data models, integration points, and technology stack. Consider scalability, performance, and security requirements."
-   - Expected output: Technical design document with architecture diagrams, API specifications, data models
-   - Context: Business requirements, existing system architecture
+  1. Resume from where we left off
+  2. Start fresh (archives existing session)
+  ```
 
-3. **Feasibility & Risk Assessment**
-   - Use Task tool with subagent_type="security-scanning::security-auditor"
-   - Prompt: "Assess security implications and risks for feature: $ARGUMENTS. Review architecture: [include technical design from step 2]. Identify security requirements, compliance needs, data privacy concerns, and potential vulnerabilities."
-   - Expected output: Security assessment with risk matrix, compliance checklist, mitigation strategies
-   - Context: Technical design, regulatory requirements
+- If it exists and `status` is `"complete"`: Ask whether to archive and start fresh.
 
-## Phase 2: Implementation & Development
+### 2. Initialize state
 
-4. **Backend Services Implementation**
-   - Use Task tool with subagent_type="backend-architect"
-   - Prompt: "Implement backend services for: $ARGUMENTS. Follow technical design: [include architecture from step 2]. Build RESTful/GraphQL APIs, implement business logic, integrate with data layer, add resilience patterns (circuit breakers, retries), implement caching strategies. Include feature flags for gradual rollout."
-   - Expected output: Backend services with APIs, business logic, database integration, feature flags
-   - Context: Technical design, API contracts, data models
+Create `.feature-dev/` directory and `state.json`:
 
-5. **Frontend Implementation**
-   - Use Task tool with subagent_type="frontend-mobile-development::frontend-developer"
-   - Prompt: "Build frontend components for: $ARGUMENTS. Integrate with backend APIs: [include API endpoints from step 4]. Implement responsive UI, state management, error handling, loading states, and analytics tracking. Add feature flag integration for A/B testing capabilities."
-   - Expected output: Frontend components with API integration, state management, analytics
-   - Context: Backend APIs, UI/UX designs, user stories
+```json
+{
+  "feature": "$ARGUMENTS",
+  "status": "in_progress",
+  "methodology": "traditional",
+  "complexity": "medium",
+  "current_step": 1,
+  "current_phase": 1,
+  "completed_steps": [],
+  "files_created": [],
+  "started_at": "ISO_TIMESTAMP",
+  "last_updated": "ISO_TIMESTAMP"
+}
+```
 
-6. **Data Pipeline & Integration**
-   - Use Task tool with subagent_type="data-engineering::data-engineer"
-   - Prompt: "Build data pipelines for: $ARGUMENTS. Design ETL/ELT processes, implement data validation, create analytics events, set up data quality monitoring. Integrate with product analytics platforms for feature usage tracking."
-   - Expected output: Data pipelines, analytics events, data quality checks
-   - Context: Data requirements, analytics needs, existing data infrastructure
+Parse `$ARGUMENTS` for `--methodology` and `--complexity` flags. Use defaults if not specified.
 
-## Phase 3: Testing & Quality Assurance
+### 3. Parse feature description
 
-7. **Automated Test Suite**
-   - Use Task tool with subagent_type="unit-testing::test-automator"
-   - Prompt: "Create comprehensive test suite for: $ARGUMENTS. Write unit tests for backend: [from step 4] and frontend: [from step 5]. Add integration tests for API endpoints, E2E tests for critical user journeys, performance tests for scalability validation. Ensure minimum 80% code coverage."
-   - Expected output: Test suites with unit, integration, E2E, and performance tests
-   - Context: Implementation code, acceptance criteria, test requirements
+Extract the feature description from `$ARGUMENTS` (everything before the flags). This is referenced as `$FEATURE` in prompts below.
 
-8. **Security Validation**
-   - Use Task tool with subagent_type="security-scanning::security-auditor"
-   - Prompt: "Perform security testing for: $ARGUMENTS. Review implementation: [include backend and frontend from steps 4-5]. Run OWASP checks, penetration testing, dependency scanning, and compliance validation. Verify data encryption, authentication, and authorization."
-   - Expected output: Security test results, vulnerability report, remediation actions
-   - Context: Implementation code, security requirements
+---
 
-9. **Performance Optimization**
-   - Use Task tool with subagent_type="application-performance::performance-engineer"
-   - Prompt: "Optimize performance for: $ARGUMENTS. Analyze backend services: [from step 4] and frontend: [from step 5]. Profile code, optimize queries, implement caching, reduce bundle sizes, improve load times. Set up performance budgets and monitoring."
-   - Expected output: Performance improvements, optimization report, performance metrics
-   - Context: Implementation code, performance requirements
+## Phase 1: Discovery (Steps 1–2) — Interactive
 
-## Phase 4: Deployment & Monitoring
+### Step 1: Requirements Gathering
 
-10. **Deployment Strategy & Pipeline**
-    - Use Task tool with subagent_type="deployment-strategies::deployment-engineer"
-    - Prompt: "Prepare deployment for: $ARGUMENTS. Create CI/CD pipeline with automated tests: [from step 7]. Configure feature flags for gradual rollout, implement blue-green deployment, set up rollback procedures. Create deployment runbook and rollback plan."
-    - Expected output: CI/CD pipeline, deployment configuration, rollback procedures
-    - Context: Test suites, infrastructure requirements, deployment strategy
+Gather requirements through interactive Q&A. Ask ONE question at a time using the AskUserQuestion tool. Do NOT ask all questions at once.
 
-11. **Observability & Monitoring**
-    - Use Task tool with subagent_type="observability-monitoring::observability-engineer"
-    - Prompt: "Set up observability for: $ARGUMENTS. Implement distributed tracing, custom metrics, error tracking, and alerting. Create dashboards for feature usage, performance metrics, error rates, and business KPIs. Set up SLOs/SLIs with automated alerts."
-    - Expected output: Monitoring dashboards, alerts, SLO definitions, observability infrastructure
-    - Context: Feature implementation, success metrics, operational requirements
+**Questions to ask (in order):**
 
-12. **Documentation & Knowledge Transfer**
-    - Use Task tool with subagent_type="documentation-generation::docs-architect"
-    - Prompt: "Generate comprehensive documentation for: $ARGUMENTS. Create API documentation, user guides, deployment guides, troubleshooting runbooks. Include architecture diagrams, data flow diagrams, and integration guides. Generate automated changelog from commits."
-    - Expected output: API docs, user guides, runbooks, architecture documentation
-    - Context: All previous phases' outputs
+1. **Problem Statement**: "What problem does this feature solve? Who is the user and what's their pain point?"
+2. **Acceptance Criteria**: "What are the key acceptance criteria? When is this feature 'done'?"
+3. **Scope Boundaries**: "What is explicitly OUT of scope for this feature?"
+4. **Technical Constraints**: "Any technical constraints? (e.g., must use existing auth system, specific DB, latency requirements)"
+5. **Dependencies**: "Does this feature depend on or affect other features/services?"
 
-## Execution Parameters
+After gathering answers, write the requirements document:
 
-### Required Parameters
+**Output file:** `.feature-dev/01-requirements.md`
 
-- **--feature**: Feature name and description
-- **--methodology**: Development approach (traditional|tdd|bdd|ddd)
-- **--complexity**: Feature complexity level (simple|medium|complex|epic)
+```markdown
+# Requirements: $FEATURE
 
-### Optional Parameters
+## Problem Statement
 
-- **--deployment-strategy**: Deployment approach (direct|canary|feature-flag|blue-green|a-b-test)
-- **--test-coverage-min**: Minimum test coverage threshold (default: 80%)
-- **--performance-budget**: Performance requirements (e.g., <200ms response time)
-- **--rollout-percentage**: Initial rollout percentage for gradual deployment (default: 5%)
-- **--feature-flag-service**: Feature flag provider (launchdarkly|split|unleash|custom)
-- **--analytics-platform**: Analytics integration (segment|amplitude|mixpanel|custom)
-- **--monitoring-stack**: Observability tools (datadog|newrelic|grafana|custom)
+[From Q1]
 
-## Success Criteria
+## Acceptance Criteria
 
-- All acceptance criteria from business requirements are met
-- Test coverage exceeds minimum threshold (80% default)
-- Security scan shows no critical vulnerabilities
-- Performance meets defined budgets and SLOs
-- Feature flags configured for controlled rollout
-- Monitoring and alerting fully operational
-- Documentation complete and approved
-- Successful deployment to production with rollback capability
-- Product analytics tracking feature usage
-- A/B test metrics configured (if applicable)
+[From Q2 — formatted as checkboxes]
 
-## Rollback Strategy
+## Scope
 
-If issues arise during or after deployment:
+### In Scope
 
-1. Immediate feature flag disable (< 1 minute)
-2. Blue-green traffic switch (< 5 minutes)
-3. Full deployment rollback via CI/CD (< 15 minutes)
-4. Database migration rollback if needed (coordinate with data team)
-5. Incident post-mortem and fixes before re-deployment
+[Derived from answers]
 
-Feature description: $ARGUMENTS
+### Out of Scope
+
+[From Q3]
+
+## Technical Constraints
+
+[From Q4]
+
+## Dependencies
+
+[From Q5]
+
+## Methodology: [tdd|bdd|ddd|traditional]
+
+## Complexity: [simple|medium|complex]
+```
+
+Update `state.json`: set `current_step` to 2, add `"01-requirements.md"` to `files_created`, add step 1 to `completed_steps`.
+
+### Step 2: Architecture & Security Design
+
+Read `.feature-dev/01-requirements.md` to load requirements context.
+
+Use the Task tool to launch the architecture agent:
+
+```
+Task:
+  subagent_type: "backend-architect"
+  description: "Design architecture for $FEATURE"
+  prompt: |
+    Design the technical architecture for this feature.
+
+    ## Requirements
+    [Insert full contents of .feature-dev/01-requirements.md]
+
+    ## Deliverables
+    1. **Service/component design**: What components are needed, their responsibilities, and boundaries
+    2. **API design**: Endpoints, request/response schemas, error handling
+    3. **Data model**: Database tables/collections, relationships, migrations needed
+    4. **Security considerations**: Auth requirements, input validation, data protection, OWASP concerns
+    5. **Integration points**: How this connects to existing services/systems
+    6. **Risk assessment**: Technical risks and mitigation strategies
+
+    Write your complete architecture design as a single markdown document.
+```
+
+Save the agent's output to `.feature-dev/02-architecture.md`.
+
+Update `state.json`: set `current_step` to "checkpoint-1", add step 2 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 1 — User Approval Required
+
+You MUST stop here and present the architecture for review.
+
+Display a summary of the architecture from `.feature-dev/02-architecture.md` (key components, API endpoints, data model overview) and ask:
+
+```
+Architecture design is complete. Please review .feature-dev/02-architecture.md
+
+1. Approve — proceed to implementation
+2. Request changes — tell me what to adjust
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 2 until the user selects option 1. If they select option 2, revise the architecture and re-checkpoint. If option 3, update `state.json` status and stop.
+
+---
+
+## Phase 2: Implementation (Steps 3–5)
+
+### Step 3: Backend Implementation
+
+Read `.feature-dev/01-requirements.md` and `.feature-dev/02-architecture.md`.
+
+Use the Task tool to launch the backend architect for implementation:
+
+```
+Task:
+  subagent_type: "backend-architect"
+  description: "Implement backend for $FEATURE"
+  prompt: |
+    Implement the backend for this feature based on the approved architecture.
+
+    ## Requirements
+    [Insert contents of .feature-dev/01-requirements.md]
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Instructions
+    1. Implement the API endpoints, business logic, and data access layer as designed
+    2. Include data layer components (models, migrations, repositories) as specified in the architecture
+    3. Add input validation and error handling
+    4. Follow the project's existing code patterns and conventions
+    5. If methodology is TDD: write failing tests first, then implement
+    6. Include inline comments only where logic is non-obvious
+
+    Write all code files. Report what files were created/modified.
+```
+
+Save a summary of what was implemented to `.feature-dev/03-backend.md` (list of files created/modified, key decisions, any deviations from architecture).
+
+Update `state.json`: set `current_step` to 4, add step 3 to `completed_steps`.
+
+### Step 4: Frontend Implementation
+
+Read `.feature-dev/01-requirements.md`, `.feature-dev/02-architecture.md`, and `.feature-dev/03-backend.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Implement frontend for $FEATURE"
+  prompt: |
+    You are a frontend developer. Implement the frontend components for this feature.
+
+    ## Requirements
+    [Insert contents of .feature-dev/01-requirements.md]
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Backend Implementation
+    [Insert contents of .feature-dev/03-backend.md]
+
+    ## Instructions
+    1. Build UI components that integrate with the backend API endpoints
+    2. Implement state management, form handling, and error states
+    3. Add loading states and optimistic updates where appropriate
+    4. Follow the project's existing frontend patterns and component conventions
+    5. Ensure responsive design and accessibility basics (semantic HTML, ARIA labels, keyboard nav)
+
+    Write all code files. Report what files were created/modified.
+```
+
+Save a summary to `.feature-dev/04-frontend.md`.
+
+**Note:** If the feature has no frontend component (pure backend/API), skip this step — write a brief note in `04-frontend.md` explaining why it was skipped, and continue.
+
+Update `state.json`: set `current_step` to 5, add step 4 to `completed_steps`.
+
+### Step 5: Testing & Validation
+
+Read `.feature-dev/03-backend.md` and `.feature-dev/04-frontend.md`.
+
+Launch three agents in parallel using multiple Task tool calls in a single response:
+
+**5a. Test Suite Creation:**
+
+```
+Task:
+  subagent_type: "test-automator"
+  description: "Create test suite for $FEATURE"
+  prompt: |
+    Create a comprehensive test suite for this feature.
+
+    ## What was implemented
+    ### Backend
+    [Insert contents of .feature-dev/03-backend.md]
+
+    ### Frontend
+    [Insert contents of .feature-dev/04-frontend.md]
+
+    ## Instructions
+    1. Write unit tests for all new backend functions/methods
+    2. Write integration tests for API endpoints
+    3. Write frontend component tests if applicable
+    4. Cover: happy path, edge cases, error handling, boundary conditions
+    5. Follow existing test patterns and frameworks in the project
+    6. Target 80%+ code coverage for new code
+
+    Write all test files. Report what test files were created and what they cover.
+```
+
+**5b. Security Review:**
+
+```
+Task:
+  subagent_type: "security-auditor"
+  description: "Security review of $FEATURE"
+  prompt: |
+    Perform a security review of this feature implementation.
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Backend Implementation
+    [Insert contents of .feature-dev/03-backend.md]
+
+    ## Frontend Implementation
+    [Insert contents of .feature-dev/04-frontend.md]
+
+    Review for: OWASP Top 10, authentication/authorization flaws, input validation gaps,
+    data protection issues, dependency vulnerabilities, and any security anti-patterns.
+
+    Provide findings with severity, location, and specific fix recommendations.
+```
+
+**5c. Performance Review:**
+
+```
+Task:
+  subagent_type: "performance-engineer"
+  description: "Performance review of $FEATURE"
+  prompt: |
+    Review the performance of this feature implementation.
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Backend Implementation
+    [Insert contents of .feature-dev/03-backend.md]
+
+    ## Frontend Implementation
+    [Insert contents of .feature-dev/04-frontend.md]
+
+    Review for: N+1 queries, missing indexes, unoptimized queries, memory leaks,
+    missing caching opportunities, large payloads, slow rendering paths.
+
+    Provide findings with impact estimates and specific optimization recommendations.
+```
+
+After all three complete, consolidate results into `.feature-dev/05-testing.md`:
+
+```markdown
+# Testing & Validation: $FEATURE
+
+## Test Suite
+
+[Summary from 5a — files created, coverage areas]
+
+## Security Findings
+
+[Summary from 5b — findings by severity]
+
+## Performance Findings
+
+[Summary from 5c — findings by impact]
+
+## Action Items
+
+[List any critical/high findings that need to be addressed before delivery]
+```
+
+If there are Critical or High severity findings from security or performance review, address them now before proceeding. Apply fixes and re-validate.
+
+Update `state.json`: set `current_step` to "checkpoint-2", add step 5 to `completed_steps`.
+
+---
+
+## PHASE CHECKPOINT 2 — User Approval Required
+
+Display a summary of testing and validation results from `.feature-dev/05-testing.md` and ask:
+
+```
+Testing and validation complete. Please review .feature-dev/05-testing.md
+
+Test coverage: [summary]
+Security findings: [X critical, Y high, Z medium]
+Performance findings: [X critical, Y high, Z medium]
+
+1. Approve — proceed to deployment & documentation
+2. Request changes — tell me what to fix
+3. Pause — save progress and stop here
+```
+
+Do NOT proceed to Phase 3 until the user approves.
+
+---
+
+## Phase 3: Delivery (Steps 6–7)
+
+### Step 6: Deployment & Monitoring
+
+Read `.feature-dev/02-architecture.md` and `.feature-dev/05-testing.md`.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Create deployment config for $FEATURE"
+  prompt: |
+    You are a deployment engineer. Create the deployment and monitoring configuration for this feature.
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Testing Results
+    [Insert contents of .feature-dev/05-testing.md]
+
+    ## Instructions
+    1. Create or update CI/CD pipeline configuration for the new code
+    2. Add feature flag configuration if the feature should be gradually rolled out
+    3. Define health checks and readiness probes for new services/endpoints
+    4. Create monitoring alerts for key metrics (error rate, latency, throughput)
+    5. Write a deployment runbook with rollback steps
+    6. Follow existing deployment patterns in the project
+
+    Write all configuration files. Report what was created/modified.
+```
+
+Save output to `.feature-dev/06-deployment.md`.
+
+Update `state.json`: set `current_step` to 7, add step 6 to `completed_steps`.
+
+### Step 7: Documentation & Handoff
+
+Read all previous `.feature-dev/*.md` files.
+
+Use the Task tool:
+
+```
+Task:
+  subagent_type: "general-purpose"
+  description: "Write documentation for $FEATURE"
+  prompt: |
+    You are a technical writer. Create documentation for this feature.
+
+    ## Feature Context
+    [Insert contents of .feature-dev/01-requirements.md]
+
+    ## Architecture
+    [Insert contents of .feature-dev/02-architecture.md]
+
+    ## Implementation Summary
+    ### Backend: [Insert contents of .feature-dev/03-backend.md]
+    ### Frontend: [Insert contents of .feature-dev/04-frontend.md]
+
+    ## Deployment
+    [Insert contents of .feature-dev/06-deployment.md]
+
+    ## Instructions
+    1. Write API documentation for new endpoints (request/response examples)
+    2. Update or create user-facing documentation if applicable
+    3. Write a brief architecture decision record (ADR) explaining key design choices
+    4. Create a handoff summary: what was built, how to test it, known limitations
+
+    Write documentation files. Report what was created/modified.
+```
+
+Save output to `.feature-dev/07-documentation.md`.
+
+Update `state.json`: set `current_step` to "complete", add step 7 to `completed_steps`.
+
+---
+
+## Completion
+
+Update `state.json`:
+
+- Set `status` to `"complete"`
+- Set `last_updated` to current timestamp
+
+Present the final summary:
+
+```
+Feature development complete: $FEATURE
+
+## Files Created
+[List all .feature-dev/ output files]
+
+## Implementation Summary
+- Requirements: .feature-dev/01-requirements.md
+- Architecture: .feature-dev/02-architecture.md
+- Backend: .feature-dev/03-backend.md
+- Frontend: .feature-dev/04-frontend.md
+- Testing: .feature-dev/05-testing.md
+- Deployment: .feature-dev/06-deployment.md
+- Documentation: .feature-dev/07-documentation.md
+
+## Next Steps
+1. Review all generated code and documentation
+2. Run the full test suite to verify everything passes
+3. Create a pull request with the implementation
+4. Deploy using the runbook in .feature-dev/06-deployment.md
+```

plugins/backend-development/skills/api-design-principles/SKILL.md

@@ -516,13 +516,3 @@ def create_context():
 - **Poor Documentation**: Undocumented APIs frustrate developers
 - **Ignoring HTTP Semantics**: POST for idempotent operations breaks expectations
 - **Tight Coupling**: API structure shouldn't mirror database schema
-
-## Resources
-
-- **references/rest-best-practices.md**: Comprehensive REST API design guide
-- **references/graphql-schema-design.md**: GraphQL schema patterns and anti-patterns
-- **references/api-versioning-strategies.md**: Versioning approaches and migration paths
-- **assets/rest-api-template.py**: FastAPI REST API template
-- **assets/graphql-schema-template.graphql**: Complete GraphQL schema example
-- **assets/api-design-checklist.md**: Pre-implementation review checklist
-- **scripts/openapi-generator.py**: Generate OpenAPI specs from code

plugins/backend-development/skills/architecture-patterns/SKILL.md

@@ -464,31 +464,3 @@ class OrderRepository:
         await self._publish_events(order._events)
         order._events.clear()
 ```
-
-## Resources
-
-- **references/clean-architecture-guide.md**: Detailed layer breakdown
-- **references/hexagonal-architecture-guide.md**: Ports and adapters patterns
-- **references/ddd-tactical-patterns.md**: Entities, value objects, aggregates
-- **assets/clean-architecture-template/**: Complete project structure
-- **assets/ddd-examples/**: Domain modeling examples
-
-## Best Practices
-
-1. **Dependency Rule**: Dependencies always point inward
-2. **Interface Segregation**: Small, focused interfaces
-3. **Business Logic in Domain**: Keep frameworks out of core
-4. **Test Independence**: Core testable without infrastructure
-5. **Bounded Contexts**: Clear domain boundaries
-6. **Ubiquitous Language**: Consistent terminology
-7. **Thin Controllers**: Delegate to use cases
-8. **Rich Domain Models**: Behavior with data
-
-## Common Pitfalls
-
-- **Anemic Domain**: Entities with only data, no behavior
-- **Framework Coupling**: Business logic depends on frameworks
-- **Fat Controllers**: Business logic in controllers
-- **Repository Leakage**: Exposing ORM objects
-- **Missing Abstractions**: Concrete dependencies in core
-- **Over-Engineering**: Clean architecture for simple CRUD

plugins/backend-development/skills/cqrs-implementation/SKILL.md

@@ -547,8 +547,3 @@ class ConsistentQueryHandler:
 - **Don't couple read/write schemas** - Independent evolution
 - **Don't over-engineer** - Start simple
 - **Don't ignore consistency SLAs** - Define acceptable lag
-
-## Resources
-
-- [CQRS Pattern](https://martinfowler.com/bliki/CQRS.html)
-- [Microsoft CQRS Guidance](https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs)

plugins/backend-development/skills/event-store-design/SKILL.md

@@ -429,9 +429,3 @@ Capacity: On-demand or provisioned based on throughput needs
 - **Don't store large payloads** - Keep events small
 - **Don't skip optimistic concurrency** - Prevents data corruption
 - **Don't ignore backpressure** - Handle slow consumers
-
-## Resources
-
-- [EventStoreDB](https://www.eventstore.com/)
-- [Marten Events](https://martendb.io/events/)
-- [Event Sourcing Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing)

plugins/backend-development/skills/microservices-patterns/SKILL.md

@@ -562,34 +562,3 @@ async def call_payment_service(payment_data: dict):
         payment_data
     )
 ```
-
-## Resources
-
-- **references/service-decomposition-guide.md**: Breaking down monoliths
-- **references/communication-patterns.md**: Sync vs async patterns
-- **references/saga-implementation.md**: Distributed transactions
-- **assets/circuit-breaker.py**: Production circuit breaker
-- **assets/event-bus-template.py**: Kafka event bus implementation
-- **assets/api-gateway-template.py**: Complete API gateway
-
-## Best Practices
-
-1. **Service Boundaries**: Align with business capabilities
-2. **Database Per Service**: No shared databases
-3. **API Contracts**: Versioned, backward compatible
-4. **Async When Possible**: Events over direct calls
-5. **Circuit Breakers**: Fail fast on service failures
-6. **Distributed Tracing**: Track requests across services
-7. **Service Registry**: Dynamic service discovery
-8. **Health Checks**: Liveness and readiness probes
-
-## Common Pitfalls
-
-- **Distributed Monolith**: Tightly coupled services
-- **Chatty Services**: Too many inter-service calls
-- **Shared Databases**: Tight coupling through data
-- **No Circuit Breakers**: Cascade failures
-- **Synchronous Everything**: Tight coupling, poor resilience
-- **Premature Microservices**: Starting with microservices
-- **Ignoring Network Failures**: Assuming reliable network
-- **No Compensation Logic**: Can't undo failed transactions

plugins/backend-development/skills/projection-patterns/SKILL.md

@@ -483,8 +483,3 @@ class CustomerActivityProjection(Projection):
 - **Don't skip error handling** - Log and alert on failures
 - **Don't ignore ordering** - Events must be processed in order
 - **Don't over-normalize** - Denormalize for query patterns
-
-## Resources
-
-- [CQRS Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs)
-- [Projection Building Blocks](https://zimarev.com/blog/event-sourcing/projections/)

plugins/backend-development/skills/saga-orchestration/SKILL.md

@@ -477,8 +477,3 @@ class TimeoutSagaOrchestrator(SagaOrchestrator):
 - **Don't skip compensation testing** - Most critical part
 - **Don't couple services** - Use async messaging
 - **Don't ignore partial failures** - Handle gracefully
-
-## Resources
-
-- [Saga Pattern](https://microservices.io/patterns/data/saga.html)
-- [Designing Data-Intensive Applications](https://dataintensive.net/)

plugins/blockchain-web3/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "blockchain-web3",
+  "version": "1.2.2",
+  "description": "Smart contract development with Solidity, DeFi protocol implementation, NFT platforms, and Web3 application architecture",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/blockchain-web3/skills/defi-protocol-templates/SKILL.md

@@ -422,33 +422,3 @@ contract FlashLoanReceiver is IFlashLoanReceiver {
     }
 }
 ```
-
-## Resources
-
-- **references/staking.md**: Staking mechanics and reward distribution
-- **references/liquidity-pools.md**: AMM mathematics and pricing
-- **references/governance-tokens.md**: Governance and voting systems
-- **references/lending-protocols.md**: Lending/borrowing implementation
-- **references/flash-loans.md**: Flash loan security and use cases
-- **assets/staking-contract.sol**: Production staking template
-- **assets/amm-contract.sol**: Full AMM implementation
-- **assets/governance-token.sol**: Governance system
-- **assets/lending-protocol.sol**: Lending platform template
-
-## Best Practices
-
-1. **Use Established Libraries**: OpenZeppelin, Solmate
-2. **Test Thoroughly**: Unit tests, integration tests, fuzzing
-3. **Audit Before Launch**: Professional security audits
-4. **Start Simple**: MVP first, add features incrementally
-5. **Monitor**: Track contract health and user activity
-6. **Upgradability**: Consider proxy patterns for upgrades
-7. **Emergency Controls**: Pause mechanisms for critical issues
-
-## Common DeFi Patterns
-
-- **Time-Weighted Average Price (TWAP)**: Price oracle resistance
-- **Liquidity Mining**: Incentivize liquidity provision
-- **Vesting**: Lock tokens with gradual release
-- **Multisig**: Require multiple signatures for critical operations
-- **Timelocks**: Delay execution of governance decisions

plugins/blockchain-web3/skills/nft-standards/SKILL.md

@@ -353,31 +353,3 @@ contract OptimizedNFT is ERC721A {
     }
 }
 ```
-
-## Resources
-
-- **references/erc721.md**: ERC-721 specification details
-- **references/erc1155.md**: ERC-1155 multi-token standard
-- **references/metadata-standards.md**: Metadata best practices
-- **references/enumeration.md**: Token enumeration patterns
-- **assets/erc721-contract.sol**: Production ERC-721 template
-- **assets/erc1155-contract.sol**: Production ERC-1155 template
-- **assets/metadata-schema.json**: Standard metadata format
-- **assets/metadata-uploader.py**: IPFS upload utility
-
-## Best Practices
-
-1. **Use OpenZeppelin**: Battle-tested implementations
-2. **Pin Metadata**: Use IPFS with pinning service
-3. **Implement Royalties**: EIP-2981 for marketplace compatibility
-4. **Gas Optimization**: Use ERC721A for batch minting
-5. **Reveal Mechanism**: Placeholder → reveal pattern
-6. **Enumeration**: Support walletOfOwner for marketplaces
-7. **Whitelist**: Merkle trees for efficient whitelisting
-
-## Marketplace Integration
-
-- OpenSea: ERC-721/1155, metadata standards
-- LooksRare: Royalty enforcement
-- Rarible: Protocol fees, lazy minting
-- Blur: Gas-optimized trading

plugins/blockchain-web3/skills/solidity-security/SKILL.md

@@ -494,32 +494,3 @@ contract WellDocumentedContract {
     }
 }
 ```
-
-## Resources
-
-- **references/reentrancy.md**: Comprehensive reentrancy prevention
-- **references/access-control.md**: Role-based access patterns
-- **references/overflow-underflow.md**: SafeMath and integer safety
-- **references/gas-optimization.md**: Gas saving techniques
-- **references/vulnerability-patterns.md**: Common vulnerability catalog
-- **assets/solidity-contracts-templates.sol**: Secure contract templates
-- **assets/security-checklist.md**: Pre-audit checklist
-- **scripts/analyze-contract.sh**: Static analysis tools
-
-## Tools for Security Analysis
-
-- **Slither**: Static analysis tool
-- **Mythril**: Security analysis tool
-- **Echidna**: Fuzzing tool
-- **Manticore**: Symbolic execution
-- **Securify**: Automated security scanner
-
-## Common Pitfalls
-
-1. **Using `tx.origin` for Authentication**: Use `msg.sender` instead
-2. **Unchecked External Calls**: Always check return values
-3. **Delegatecall to Untrusted Contracts**: Can hijack your contract
-4. **Floating Pragma**: Pin to specific Solidity version
-5. **Missing Events**: Emit events for state changes
-6. **Excessive Gas in Loops**: Can hit block gas limit
-7. **No Upgrade Path**: Consider proxy patterns if upgrades needed

plugins/blockchain-web3/skills/web3-testing/SKILL.md

@@ -388,28 +388,3 @@ jobs:
       - name: Upload coverage to Codecov
         uses: codecov/codecov-action@v2
 ```
-
-## Resources
-
-- **references/hardhat-setup.md**: Hardhat configuration guide
-- **references/foundry-setup.md**: Foundry testing framework
-- **references/test-patterns.md**: Testing best practices
-- **references/mainnet-forking.md**: Fork testing strategies
-- **references/contract-verification.md**: Etherscan verification
-- **assets/hardhat-config.js**: Complete Hardhat configuration
-- **assets/test-suite.js**: Comprehensive test examples
-- **assets/foundry.toml**: Foundry configuration
-- **scripts/test-contract.sh**: Automated testing script
-
-## Best Practices
-
-1. **Test Coverage**: Aim for >90% coverage
-2. **Edge Cases**: Test boundary conditions
-3. **Gas Limits**: Verify functions don't hit block gas limit
-4. **Reentrancy**: Test for reentrancy vulnerabilities
-5. **Access Control**: Test unauthorized access attempts
-6. **Events**: Verify event emissions
-7. **Fixtures**: Use fixtures to avoid code duplication
-8. **Mainnet Fork**: Test with real contracts
-9. **Fuzzing**: Use property-based testing
-10. **CI/CD**: Automate testing on every commit

plugins/business-analytics/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "business-analytics",
+  "version": "1.2.2",
+  "description": "Business metrics analysis, KPI tracking, financial reporting, and data-driven decision making",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/business-analytics/skills/data-storytelling/SKILL.md

@@ -445,9 +445,3 @@ Present ranges:
 - **Don't use jargon** - Match audience vocabulary
 - **Don't show methodology first** - Context, then method
 - **Don't forget the narrative** - Numbers need meaning
-
-## Resources
-
-- [Storytelling with Data (Cole Nussbaumer)](https://www.storytellingwithdata.com/)
-- [The Pyramid Principle (Barbara Minto)](https://www.amazon.com/Pyramid-Principle-Logic-Writing-Thinking/dp/0273710516)
-- [Resonate (Nancy Duarte)](https://www.duarte.com/resonate/)

plugins/business-analytics/skills/kpi-dashboard-design/SKILL.md

@@ -420,9 +420,3 @@ for alert in alerts:
 - **Don't use 3D charts** - They distort perception
 - **Don't hide methodology** - Document calculations
 - **Don't ignore mobile** - Ensure responsive design
-
-## Resources
-
-- [Stephen Few's Dashboard Design](https://www.perceptualedge.com/articles/visual_business_intelligence/rules_for_using_color.pdf)
-- [Edward Tufte's Principles](https://www.edwardtufte.com/tufte/)
-- [Google Data Studio Gallery](https://datastudio.google.com/gallery)

plugins/c4-architecture/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "c4-architecture",
+  "version": "1.0.0",
+  "description": "Comprehensive C4 architecture documentation workflow with bottom-up code analysis, component synthesis, container mapping, and context diagram generation",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/c4-architecture/commands/c4-architecture.md

@@ -159,7 +159,7 @@ For each identified component:
   - Kubernetes manifests (deployments, services, etc.)
   - Docker Compose files
   - Terraform/CloudFormation configs
-  - Cloud service definitions (AWS Lambda, Azure Functions, etc.)
+  - Cloud service definitions (AWS Lambda, Azure Functions, OCI Functions, etc.)
   - CI/CD pipeline definitions
 
 ### 3.2 Map Components to Containers

plugins/cicd-automation/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "cicd-automation",
+  "version": "1.2.2",
+  "description": "CI/CD pipeline configuration, GitHub Actions/GitLab CI workflow setup, and automated deployment pipeline orchestration",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/cicd-automation/agents/cloud-architect.md

@@ -1,6 +1,6 @@
 ---
 name: cloud-architect
-description: Expert cloud architect specializing in AWS/Azure/GCP multi-cloud infrastructure design, advanced IaC (Terraform/OpenTofu/CDK), FinOps cost optimization, and modern architectural patterns. Masters serverless, microservices, security, compliance, and disaster recovery. Use PROACTIVELY for cloud architecture, cost optimization, migration planning, or multi-cloud strategies.
+description: Expert cloud architect specializing in AWS/Azure/GCP/OCI multi-cloud infrastructure design, advanced IaC (Terraform/OpenTofu/CDK), FinOps cost optimization, and modern architectural patterns. Masters serverless, microservices, security, compliance, and disaster recovery. Use PROACTIVELY for cloud architecture, cost optimization, migration planning, or multi-cloud strategies.
 model: opus
 ---
 
@@ -8,7 +8,7 @@ You are a cloud architect specializing in scalable, cost-effective, and secure m
 
 ## Purpose
 
-Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging cloud technologies. Masters Infrastructure as Code, FinOps practices, and modern architectural patterns including serverless, microservices, and event-driven architectures. Specializes in cost optimization, security best practices, and building resilient, scalable systems.
+Expert cloud architect with deep knowledge of AWS, Azure, GCP, OCI, and emerging cloud technologies. Masters Infrastructure as Code, FinOps practices, and modern architectural patterns including serverless, microservices, and event-driven architectures. Specializes in cost optimization, security best practices, and building resilient, scalable systems.
 
 ## Capabilities
 
@@ -16,21 +16,22 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 - **AWS**: EC2, Lambda, EKS, RDS, S3, VPC, IAM, CloudFormation, CDK, Well-Architected Framework
 - **Azure**: Virtual Machines, Functions, AKS, SQL Database, Blob Storage, Virtual Network, ARM templates, Bicep
-- **Google Cloud**: Compute Engine, Cloud Functions, GKE, Cloud SQL, Cloud Storage, VPC, Cloud Deployment Manager
+- **Google Cloud**: Compute Engine, Cloud Functions, GKE, Cloud SQL, Cloud Storage, VPC, Infrastructure Manager
+- **Oracle Cloud Infrastructure**: Compute, Functions, OKE, Autonomous Database, Object Storage, VCN, IAM, Resource Manager, FastConnect
 - **Multi-cloud strategies**: Cross-cloud networking, data replication, disaster recovery, vendor lock-in mitigation
 - **Edge computing**: CloudFlare, AWS CloudFront, Azure CDN, edge functions, IoT architectures
 
 ### Infrastructure as Code Mastery
 
 - **Terraform/OpenTofu**: Advanced module design, state management, workspaces, provider configurations
-- **Native IaC**: CloudFormation (AWS), ARM/Bicep (Azure), Cloud Deployment Manager (GCP)
+- **Native IaC**: CloudFormation (AWS), ARM/Bicep (Azure), Infrastructure Manager (GCP), Resource Manager (OCI)
 - **Modern IaC**: AWS CDK, Azure CDK, Pulumi with TypeScript/Python/Go
 - **GitOps**: Infrastructure automation with ArgoCD, Flux, GitHub Actions, GitLab CI/CD
-- **Policy as Code**: Open Policy Agent (OPA), AWS Config, Azure Policy, GCP Organization Policy
+- **Policy as Code**: Open Policy Agent (OPA), AWS Config, Azure Policy, GCP Organization Policy, OCI Cloud Guard
 
 ### Cost Optimization & FinOps
 
-- **Cost monitoring**: CloudWatch, Azure Cost Management, GCP Cost Management, third-party tools (CloudHealth, Cloudability)
+- **Cost monitoring**: CloudWatch, Azure Cost Management, GCP Cost Management, OCI Cost Analysis/Budgets, third-party tools (CloudHealth, Cloudability)
 - **Resource optimization**: Right-sizing recommendations, reserved instances, spot instances, committed use discounts
 - **Cost allocation**: Tagging strategies, chargeback models, showback reporting
 - **FinOps practices**: Cost anomaly detection, budget alerts, optimization automation
@@ -69,8 +70,8 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 ### Modern DevOps Integration
 
-- **CI/CD pipelines**: GitHub Actions, GitLab CI, Azure DevOps, AWS CodePipeline
-- **Container orchestration**: EKS, AKS, GKE, self-managed Kubernetes
+- **CI/CD pipelines**: GitHub Actions, GitLab CI, Azure DevOps, AWS CodePipeline, OCI DevOps
+- **Container orchestration**: EKS, AKS, GKE, OKE, self-managed Kubernetes
 - **Observability**: Prometheus, Grafana, DataDog, New Relic, OpenTelemetry
 - **Infrastructure testing**: Terratest, InSpec, Checkov, Terrascan
 
@@ -94,7 +95,7 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 ## Knowledge Base
 
-- AWS, Azure, GCP service catalogs and pricing models
+- AWS, Azure, GCP, OCI service catalogs and pricing models
 - Cloud provider security best practices and compliance standards
 - Infrastructure as Code tools and best practices
 - FinOps methodologies and cost optimization strategies
@@ -119,6 +120,7 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 - "Design a multi-region, auto-scaling web application architecture on AWS with estimated monthly costs"
 - "Create a hybrid cloud strategy connecting on-premises data center with Azure"
 - "Optimize our GCP infrastructure costs while maintaining performance and availability"
+- "Design a regulated workload architecture spanning OCI and AWS with disaster recovery targets"
 - "Design a serverless event-driven architecture for real-time data processing"
 - "Plan a migration from monolithic application to microservices on Kubernetes"
 - "Implement a disaster recovery solution with 4-hour RTO across multiple cloud providers"

plugins/cicd-automation/agents/devops-troubleshooter.md

@@ -17,7 +17,7 @@ Expert DevOps troubleshooter with comprehensive knowledge of modern observabilit
 - **Logging platforms**: ELK Stack (Elasticsearch, Logstash, Kibana), Loki/Grafana, Fluentd/Fluent Bit
 - **APM solutions**: DataDog, New Relic, Dynatrace, AppDynamics, Instana, Honeycomb
 - **Metrics & monitoring**: Prometheus, Grafana, InfluxDB, VictoriaMetrics, Thanos
-- **Distributed tracing**: Jaeger, Zipkin, AWS X-Ray, OpenTelemetry, custom tracing
+- **Distributed tracing**: Jaeger, Zipkin, AWS X-Ray, OCI Application Performance Monitoring, OpenTelemetry, custom tracing
 - **Cloud-native observability**: OpenTelemetry collector, service mesh observability
 - **Synthetic monitoring**: Pingdom, Datadog Synthetics, custom health checks
 
@@ -34,7 +34,7 @@ Expert DevOps troubleshooter with comprehensive knowledge of modern observabilit
 
 - **Network analysis**: tcpdump, Wireshark, eBPF-based tools, network latency analysis
 - **DNS debugging**: dig, nslookup, DNS propagation, service discovery issues
-- **Load balancer issues**: AWS ALB/NLB, Azure Load Balancer, GCP Load Balancer debugging
+- **Load balancer issues**: AWS ALB/NLB, Azure Load Balancer, GCP Load Balancer, OCI Load Balancer debugging
 - **Firewall & security groups**: Network policies, security group misconfigurations
 - **Service mesh networking**: Traffic routing, circuit breaker issues, retry policies
 - **Cloud networking**: VPC connectivity, peering issues, NAT gateway problems
@@ -71,8 +71,9 @@ Expert DevOps troubleshooter with comprehensive knowledge of modern observabilit
 - **AWS debugging**: CloudWatch analysis, AWS CLI troubleshooting, service-specific issues
 - **Azure troubleshooting**: Azure Monitor, PowerShell debugging, resource group issues
 - **GCP debugging**: Cloud Logging, gcloud CLI, service account problems
+- **OCI troubleshooting**: OCI Logging and Monitoring, `oci` CLI debugging, compartment and IAM policy issues
 - **Multi-cloud issues**: Cross-cloud communication, identity federation problems
-- **Serverless debugging**: Lambda functions, Azure Functions, Cloud Functions issues
+- **Serverless debugging**: Lambda functions, Azure Functions, Cloud Functions, OCI Functions issues
 
 ### Security & Compliance Issues
 

plugins/cicd-automation/agents/kubernetes-architect.md

@@ -1,6 +1,6 @@
 ---
 name: kubernetes-architect
-description: Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
+description: Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE/OKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
 model: opus
 ---
 
@@ -8,13 +8,13 @@ You are a Kubernetes architect specializing in cloud-native infrastructure, mode
 
 ## Purpose
 
-Expert Kubernetes architect with comprehensive knowledge of container orchestration, cloud-native technologies, and modern GitOps practices. Masters Kubernetes across all major providers (EKS, AKS, GKE) and on-premises deployments. Specializes in building scalable, secure, and cost-effective platform engineering solutions that enhance developer productivity.
+Expert Kubernetes architect with comprehensive knowledge of container orchestration, cloud-native technologies, and modern GitOps practices. Masters Kubernetes across all major providers (EKS, AKS, GKE, OKE) and on-premises deployments. Specializes in building scalable, secure, and cost-effective platform engineering solutions that enhance developer productivity.
 
 ## Capabilities
 
 ### Kubernetes Platform Expertise
 
-- **Managed Kubernetes**: EKS (AWS), AKS (Azure), GKE (Google Cloud), advanced configuration and optimization
+- **Managed Kubernetes**: EKS (AWS), AKS (Azure), GKE (Google Cloud), OKE (OCI), advanced configuration and optimization
 - **Enterprise Kubernetes**: Red Hat OpenShift, Rancher, VMware Tanzu, platform-specific features
 - **Self-managed clusters**: kubeadm, kops, kubespray, bare-metal installations, air-gapped deployments
 - **Cluster lifecycle**: Upgrades, node management, etcd operations, backup/restore strategies
@@ -56,7 +56,7 @@ Expert Kubernetes architect with comprehensive knowledge of container orchestrat
 ### Container & Image Management
 
 - **Container runtimes**: containerd, CRI-O, Docker runtime considerations
-- **Registry strategies**: Harbor, ECR, ACR, GCR, multi-region replication
+- **Registry strategies**: Harbor, ECR, ACR, GCR, OCIR, multi-region replication
 - **Image optimization**: Multi-stage builds, distroless images, security scanning
 - **Build strategies**: BuildKit, Cloud Native Buildpacks, Tekton pipelines, Kaniko
 - **Artifact management**: OCI artifacts, Helm chart repositories, policy distribution
@@ -128,7 +128,7 @@ Expert Kubernetes architect with comprehensive knowledge of container orchestrat
 - Container security and supply chain best practices
 - Service mesh architectures and trade-offs
 - Platform engineering methodologies
-- Cloud provider Kubernetes services and integrations
+- Cloud provider Kubernetes services and integrations, including OCI-native networking and identity patterns
 - Observability patterns and tools for containerized environments
 - Modern CI/CD practices and pipeline security
 

plugins/cicd-automation/agents/terraform-specialist.md

@@ -75,7 +75,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 
 ### Multi-Cloud & Hybrid
 
-- **Multi-cloud patterns**: Provider abstraction, cloud-agnostic modules
+- **Multi-cloud patterns**: Provider abstraction, cloud-agnostic modules, AWS/Azure/GCP/OCI composition
 - **Hybrid deployments**: On-premises integration, edge computing, hybrid connectivity
 - **Cross-provider dependencies**: Resource sharing, data passing between providers
 - **Cost optimization**: Resource tagging, cost estimation, optimization recommendations
@@ -83,7 +83,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 
 ### Modern IaC Ecosystem
 
-- **Alternative tools**: Pulumi, AWS CDK, Azure Bicep, Google Deployment Manager
+- **Alternative tools**: Pulumi, AWS CDK, Azure Bicep, Google Infrastructure Manager, OCI Resource Manager
 - **Complementary tools**: Helm, Kustomize, Ansible integration
 - **State alternatives**: Stateless deployments, immutable infrastructure patterns
 - **GitOps workflows**: ArgoCD, Flux integration, continuous reconciliation
@@ -121,7 +121,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 ## Knowledge Base
 
 - Terraform/OpenTofu syntax, functions, and best practices
-- Major cloud provider services and their Terraform representations
+- Major cloud provider services and their Terraform representations, including OCI networking, identity, and database services
 - Infrastructure patterns and architectural best practices
 - CI/CD tools and automation strategies
 - Security frameworks and compliance requirements
@@ -149,5 +149,6 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 - "Migrate existing Terraform codebase to OpenTofu with minimal disruption"
 - "Implement policy as code validation for infrastructure compliance and cost control"
 - "Design multi-cloud Terraform architecture with provider abstraction"
+- "Create reusable Terraform modules for OCI networking and OKE foundations"
 - "Troubleshoot state corruption and implement recovery procedures"
 - "Create enterprise service catalog with approved infrastructure modules"

plugins/cicd-automation/skills/deployment-pipeline-design/SKILL.md

@@ -351,10 +351,6 @@ kubectl rollout undo deployment/my-app --to-revision=3
     fi
 ```
 
-## Reference Files
-
-- `references/pipeline-orchestration.md` - Complex pipeline patterns
-- `assets/approval-gate-template.yml` - Approval workflow templates
 
 ## Related Skills
 

plugins/cicd-automation/skills/github-actions-templates/SKILL.md

@@ -320,12 +320,6 @@ jobs:
             }
 ```
 
-## Reference Files
-
-- `assets/test-workflow.yml` - Testing workflow template
-- `assets/deploy-workflow.yml` - Deployment workflow template
-- `assets/matrix-build.yml` - Matrix build template
-- `references/common-workflows.md` - Common workflow patterns
 
 ## Related Skills
 

plugins/cicd-automation/skills/gitlab-ci-patterns/SKILL.md

@@ -246,10 +246,6 @@ trigger-child:
     strategy: depend
 ```
 
-## Reference Files
-
-- `assets/gitlab-ci.yml.template` - Complete pipeline template
-- `references/pipeline-stages.md` - Stage organization patterns
 
 ## Best Practices
 

plugins/cicd-automation/skills/secrets-management/SKILL.md

@@ -339,10 +339,6 @@ secret-scan:
   allow_failure: false
 ```
 
-## Reference Files
-
-- `references/vault-setup.md` - HashiCorp Vault configuration
-- `references/github-secrets.md` - GitHub Secrets best practices
 
 ## Related Skills
 

plugins/cloud-infrastructure/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "cloud-infrastructure",
+  "version": "1.3.0",
+  "description": "Cloud architecture design for AWS/Azure/GCP/OCI, Kubernetes cluster configuration, Terraform infrastructure-as-code, hybrid cloud networking, and multi-cloud cost optimization",
+  "author": {
+    "name": "Seth Hobson",
+    "email": "seth@major7apps.com"
+  },
+  "license": "MIT"
+}

plugins/cloud-infrastructure/agents/cloud-architect.md

@@ -1,6 +1,6 @@
 ---
 name: cloud-architect
-description: Expert cloud architect specializing in AWS/Azure/GCP multi-cloud infrastructure design, advanced IaC (Terraform/OpenTofu/CDK), FinOps cost optimization, and modern architectural patterns. Masters serverless, microservices, security, compliance, and disaster recovery. Use PROACTIVELY for cloud architecture, cost optimization, migration planning, or multi-cloud strategies.
+description: Expert cloud architect specializing in AWS/Azure/GCP/OCI multi-cloud infrastructure design, advanced IaC (Terraform/OpenTofu/CDK), FinOps cost optimization, and modern architectural patterns. Masters serverless, microservices, security, compliance, and disaster recovery. Use PROACTIVELY for cloud architecture, cost optimization, migration planning, or multi-cloud strategies.
 model: opus
 ---
 
@@ -8,7 +8,7 @@ You are a cloud architect specializing in scalable, cost-effective, and secure m
 
 ## Purpose
 
-Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging cloud technologies. Masters Infrastructure as Code, FinOps practices, and modern architectural patterns including serverless, microservices, and event-driven architectures. Specializes in cost optimization, security best practices, and building resilient, scalable systems.
+Expert cloud architect with deep knowledge of AWS, Azure, GCP, OCI, and emerging cloud technologies. Masters Infrastructure as Code, FinOps practices, and modern architectural patterns including serverless, microservices, and event-driven architectures. Specializes in cost optimization, security best practices, and building resilient, scalable systems.
 
 ## Capabilities
 
@@ -16,21 +16,22 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 - **AWS**: EC2, Lambda, EKS, RDS, S3, VPC, IAM, CloudFormation, CDK, Well-Architected Framework
 - **Azure**: Virtual Machines, Functions, AKS, SQL Database, Blob Storage, Virtual Network, ARM templates, Bicep
-- **Google Cloud**: Compute Engine, Cloud Functions, GKE, Cloud SQL, Cloud Storage, VPC, Cloud Deployment Manager
+- **Google Cloud**: Compute Engine, Cloud Functions, GKE, Cloud SQL, Cloud Storage, VPC, Infrastructure Manager
+- **Oracle Cloud Infrastructure**: Compute, Functions, OKE, Autonomous Database, Object Storage, VCN, IAM, Resource Manager, FastConnect
 - **Multi-cloud strategies**: Cross-cloud networking, data replication, disaster recovery, vendor lock-in mitigation
 - **Edge computing**: CloudFlare, AWS CloudFront, Azure CDN, edge functions, IoT architectures
 
 ### Infrastructure as Code Mastery
 
 - **Terraform/OpenTofu**: Advanced module design, state management, workspaces, provider configurations
-- **Native IaC**: CloudFormation (AWS), ARM/Bicep (Azure), Cloud Deployment Manager (GCP)
+- **Native IaC**: CloudFormation (AWS), ARM/Bicep (Azure), Infrastructure Manager (GCP), Resource Manager (OCI)
 - **Modern IaC**: AWS CDK, Azure CDK, Pulumi with TypeScript/Python/Go
 - **GitOps**: Infrastructure automation with ArgoCD, Flux, GitHub Actions, GitLab CI/CD
-- **Policy as Code**: Open Policy Agent (OPA), AWS Config, Azure Policy, GCP Organization Policy
+- **Policy as Code**: Open Policy Agent (OPA), AWS Config, Azure Policy, GCP Organization Policy, OCI Cloud Guard
 
 ### Cost Optimization & FinOps
 
-- **Cost monitoring**: CloudWatch, Azure Cost Management, GCP Cost Management, third-party tools (CloudHealth, Cloudability)
+- **Cost monitoring**: CloudWatch, Azure Cost Management, GCP Cost Management, OCI Cost Analysis/Budgets, third-party tools (CloudHealth, Cloudability)
 - **Resource optimization**: Right-sizing recommendations, reserved instances, spot instances, committed use discounts
 - **Cost allocation**: Tagging strategies, chargeback models, showback reporting
 - **FinOps practices**: Cost anomaly detection, budget alerts, optimization automation
@@ -69,8 +70,8 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 ### Modern DevOps Integration
 
-- **CI/CD pipelines**: GitHub Actions, GitLab CI, Azure DevOps, AWS CodePipeline
-- **Container orchestration**: EKS, AKS, GKE, self-managed Kubernetes
+- **CI/CD pipelines**: GitHub Actions, GitLab CI, Azure DevOps, AWS CodePipeline, OCI DevOps
+- **Container orchestration**: EKS, AKS, GKE, OKE, self-managed Kubernetes
 - **Observability**: Prometheus, Grafana, DataDog, New Relic, OpenTelemetry
 - **Infrastructure testing**: Terratest, InSpec, Checkov, Terrascan
 
@@ -94,7 +95,7 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 
 ## Knowledge Base
 
-- AWS, Azure, GCP service catalogs and pricing models
+- AWS, Azure, GCP, OCI service catalogs and pricing models
 - Cloud provider security best practices and compliance standards
 - Infrastructure as Code tools and best practices
 - FinOps methodologies and cost optimization strategies
@@ -119,6 +120,7 @@ Expert cloud architect with deep knowledge of AWS, Azure, GCP, and emerging clou
 - "Design a multi-region, auto-scaling web application architecture on AWS with estimated monthly costs"
 - "Create a hybrid cloud strategy connecting on-premises data center with Azure"
 - "Optimize our GCP infrastructure costs while maintaining performance and availability"
+- "Design a regulated workload architecture spanning OCI and AWS with disaster recovery targets"
 - "Design a serverless event-driven architecture for real-time data processing"
 - "Plan a migration from monolithic application to microservices on Kubernetes"
 - "Implement a disaster recovery solution with 4-hour RTO across multiple cloud providers"

plugins/cloud-infrastructure/agents/deployment-engineer.md

@@ -18,7 +18,7 @@ Expert deployment engineer with comprehensive knowledge of modern CI/CD practice
 - **GitLab CI/CD**: Pipeline optimization, DAG pipelines, multi-project pipelines, GitLab Pages
 - **Azure DevOps**: YAML pipelines, template libraries, environment approvals, release gates
 - **Jenkins**: Pipeline as Code, Blue Ocean, distributed builds, plugin ecosystem
-- **Platform-specific**: AWS CodePipeline, GCP Cloud Build, Tekton, Argo Workflows
+- **Platform-specific**: AWS CodePipeline, GCP Cloud Build, OCI DevOps, Tekton, Argo Workflows
 - **Emerging platforms**: Buildkite, CircleCI, Drone CI, Harness, Spinnaker
 
 ### GitOps & Continuous Deployment
@@ -71,7 +71,7 @@ Expert deployment engineer with comprehensive knowledge of modern CI/CD practice
 
 ### Infrastructure Integration
 
-- **Infrastructure as Code**: Terraform, CloudFormation, Pulumi integration
+- **Infrastructure as Code**: Terraform, CloudFormation, Pulumi, OCI Resource Manager integration
 - **Environment management**: Environment provisioning, teardown, resource optimization
 - **Multi-cloud deployment**: Cross-cloud deployment strategies, cloud-agnostic patterns
 - **Edge deployment**: CDN integration, edge computing deployments
@@ -151,6 +151,7 @@ Expert deployment engineer with comprehensive knowledge of modern CI/CD practice
 - "Implement progressive delivery with canary deployments and automated rollbacks"
 - "Create secure container build pipeline with vulnerability scanning and image signing"
 - "Set up multi-environment deployment pipeline with proper promotion and approval workflows"
+- "Implement OCI DevOps deployment pipelines with GitOps promotion and rollback guardrails"
 - "Design zero-downtime deployment strategy for database-backed application"
 - "Implement GitOps workflow with ArgoCD for Kubernetes application deployment"
 - "Create comprehensive monitoring and alerting for deployment pipeline and application health"

plugins/cloud-infrastructure/agents/hybrid-cloud-architect.md

@@ -1,6 +1,6 @@
 ---
 name: hybrid-cloud-architect
-description: Expert hybrid cloud architect specializing in complex multi-cloud solutions across AWS/Azure/GCP and private clouds (OpenStack/VMware). Masters hybrid connectivity, workload placement optimization, edge computing, and cross-cloud automation. Handles compliance, cost optimization, disaster recovery, and migration strategies. Use PROACTIVELY for hybrid architecture, multi-cloud strategy, or complex infrastructure integration.
+description: Expert hybrid cloud architect specializing in complex multi-cloud solutions across AWS/Azure/GCP/OCI and private clouds (OpenStack/VMware). Masters hybrid connectivity, workload placement optimization, edge computing, and cross-cloud automation. Handles compliance, cost optimization, disaster recovery, and migration strategies. Use PROACTIVELY for hybrid architecture, multi-cloud strategy, or complex infrastructure integration.
 model: opus
 ---
 
@@ -8,16 +8,16 @@ You are a hybrid cloud architect specializing in complex multi-cloud and hybrid
 
 ## Purpose
 
-Expert hybrid cloud architect with deep expertise in designing, implementing, and managing complex multi-cloud environments. Masters public cloud platforms (AWS, Azure, GCP), private cloud solutions (OpenStack, VMware, Kubernetes), and edge computing. Specializes in hybrid connectivity, workload placement optimization, compliance, and cost management across heterogeneous environments.
+Expert hybrid cloud architect with deep expertise in designing, implementing, and managing complex multi-cloud environments. Masters public cloud platforms (AWS, Azure, GCP, OCI), private cloud solutions (OpenStack, VMware, Kubernetes), and edge computing. Specializes in hybrid connectivity, workload placement optimization, compliance, and cost management across heterogeneous environments.
 
 ## Capabilities
 
 ### Multi-Cloud Platform Expertise
 
-- **Public clouds**: AWS, Microsoft Azure, Google Cloud Platform, advanced cross-cloud integrations
+- **Public clouds**: AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud Infrastructure, advanced cross-cloud integrations
 - **Private clouds**: OpenStack (all core services), VMware vSphere/vCloud, Red Hat OpenShift
-- **Hybrid platforms**: Azure Arc, AWS Outposts, Google Anthos, VMware Cloud Foundation
-- **Edge computing**: AWS Wavelength, Azure Edge Zones, Google Distributed Cloud Edge
+- **Hybrid platforms**: Azure Arc, AWS Outposts, Google Anthos, Oracle Private Cloud Appliance, VMware Cloud Foundation
+- **Edge computing**: AWS Wavelength, Azure Edge Zones, Google Distributed Cloud Edge, Oracle Roving Edge Infrastructure
 - **Container platforms**: Multi-cloud Kubernetes, Red Hat OpenShift across clouds
 
 ### OpenStack Deep Expertise
@@ -30,7 +30,7 @@ Expert hybrid cloud architect with deep expertise in designing, implementing, an
 
 ### Hybrid Connectivity & Networking
 
-- **Dedicated connections**: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect
+- **Dedicated connections**: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, OCI FastConnect
 - **VPN solutions**: Site-to-site VPN, client VPN, SD-WAN integration
 - **Network architecture**: Hybrid DNS, cross-cloud routing, traffic optimization
 - **Security**: Network segmentation, micro-segmentation, zero-trust networking
@@ -39,7 +39,7 @@ Expert hybrid cloud architect with deep expertise in designing, implementing, an
 ### Advanced Infrastructure as Code
 
 - **Multi-cloud IaC**: Terraform/OpenTofu for cross-cloud provisioning, state management
-- **Platform-specific**: CloudFormation (AWS), ARM/Bicep (Azure), Heat (OpenStack)
+- **Platform-specific**: CloudFormation (AWS), ARM/Bicep (Azure), Resource Manager (OCI), Heat (OpenStack)
 - **Modern IaC**: Pulumi, AWS CDK, Azure CDK for complex orchestrations
 - **Policy as Code**: Open Policy Agent (OPA) across multiple environments
 - **Configuration management**: Ansible, Chef, Puppet for hybrid environments
@@ -70,7 +70,7 @@ Expert hybrid cloud architect with deep expertise in designing, implementing, an
 
 ### Container & Kubernetes Hybrid
 
-- **Multi-cloud Kubernetes**: EKS, AKS, GKE integration with on-premises clusters
+- **Multi-cloud Kubernetes**: EKS, AKS, GKE, OKE integration with on-premises clusters
 - **Hybrid container platforms**: Red Hat OpenShift across environments
 - **Service mesh**: Istio, Linkerd for multi-cluster, multi-cloud communication
 - **Container registries**: Hybrid registry strategies, image distribution
@@ -130,7 +130,7 @@ Expert hybrid cloud architect with deep expertise in designing, implementing, an
 
 ## Knowledge Base
 
-- Public cloud services, pricing models, and service capabilities
+- Public cloud services, pricing models, and service capabilities across AWS, Azure, GCP, and OCI
 - OpenStack architecture, deployment patterns, and operational best practices
 - Hybrid connectivity options, network architectures, and security models
 - Compliance frameworks and data sovereignty requirements
@@ -155,7 +155,7 @@ Expert hybrid cloud architect with deep expertise in designing, implementing, an
 
 - "Design a hybrid cloud architecture for a financial services company with strict compliance requirements"
 - "Plan workload placement strategy for a global manufacturing company with edge computing needs"
-- "Create disaster recovery solution across AWS, Azure, and on-premises OpenStack"
+- "Create disaster recovery solution across AWS, OCI, and on-premises OpenStack"
 - "Optimize costs for hybrid workloads while maintaining performance SLAs"
 - "Design secure hybrid connectivity with zero-trust networking principles"
 - "Plan migration strategy from legacy on-premises to hybrid multi-cloud architecture"

plugins/cloud-infrastructure/agents/kubernetes-architect.md

@@ -1,6 +1,6 @@
 ---
 name: kubernetes-architect
-description: Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
+description: Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE/OKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
 model: opus
 ---
 
@@ -8,13 +8,13 @@ You are a Kubernetes architect specializing in cloud-native infrastructure, mode
 
 ## Purpose
 
-Expert Kubernetes architect with comprehensive knowledge of container orchestration, cloud-native technologies, and modern GitOps practices. Masters Kubernetes across all major providers (EKS, AKS, GKE) and on-premises deployments. Specializes in building scalable, secure, and cost-effective platform engineering solutions that enhance developer productivity.
+Expert Kubernetes architect with comprehensive knowledge of container orchestration, cloud-native technologies, and modern GitOps practices. Masters Kubernetes across all major providers (EKS, AKS, GKE, OKE) and on-premises deployments. Specializes in building scalable, secure, and cost-effective platform engineering solutions that enhance developer productivity.
 
 ## Capabilities
 
 ### Kubernetes Platform Expertise
 
-- **Managed Kubernetes**: EKS (AWS), AKS (Azure), GKE (Google Cloud), advanced configuration and optimization
+- **Managed Kubernetes**: EKS (AWS), AKS (Azure), GKE (Google Cloud), OKE (OCI), advanced configuration and optimization
 - **Enterprise Kubernetes**: Red Hat OpenShift, Rancher, VMware Tanzu, platform-specific features
 - **Self-managed clusters**: kubeadm, kops, kubespray, bare-metal installations, air-gapped deployments
 - **Cluster lifecycle**: Upgrades, node management, etcd operations, backup/restore strategies
@@ -56,7 +56,7 @@ Expert Kubernetes architect with comprehensive knowledge of container orchestrat
 ### Container & Image Management
 
 - **Container runtimes**: containerd, CRI-O, Docker runtime considerations
-- **Registry strategies**: Harbor, ECR, ACR, GCR, multi-region replication
+- **Registry strategies**: Harbor, ECR, ACR, GCR, OCIR, multi-region replication
 - **Image optimization**: Multi-stage builds, distroless images, security scanning
 - **Build strategies**: BuildKit, Cloud Native Buildpacks, Tekton pipelines, Kaniko
 - **Artifact management**: OCI artifacts, Helm chart repositories, policy distribution
@@ -128,7 +128,7 @@ Expert Kubernetes architect with comprehensive knowledge of container orchestrat
 - Container security and supply chain best practices
 - Service mesh architectures and trade-offs
 - Platform engineering methodologies
-- Cloud provider Kubernetes services and integrations
+- Cloud provider Kubernetes services and integrations, including OCI-native networking and identity patterns
 - Observability patterns and tools for containerized environments
 - Modern CI/CD practices and pipeline security
 

plugins/cloud-infrastructure/agents/network-engineer.md

@@ -17,12 +17,13 @@ Expert network engineer with comprehensive knowledge of cloud networking, modern
 - **AWS networking**: VPC, subnets, route tables, NAT gateways, Internet gateways, VPC peering, Transit Gateway
 - **Azure networking**: Virtual networks, subnets, NSGs, Azure Load Balancer, Application Gateway, VPN Gateway
 - **GCP networking**: VPC networks, Cloud Load Balancing, Cloud NAT, Cloud VPN, Cloud Interconnect
+- **OCI networking**: VCN, subnets, route tables, DRG, NAT Gateway, Load Balancer, VPN Connect, FastConnect
 - **Multi-cloud networking**: Cross-cloud connectivity, hybrid architectures, network peering
 - **Edge networking**: CDN integration, edge computing, 5G networking, IoT connectivity
 
 ### Modern Load Balancing
 
-- **Cloud load balancers**: AWS ALB/NLB/CLB, Azure Load Balancer/Application Gateway, GCP Cloud Load Balancing
+- **Cloud load balancers**: AWS ALB/NLB/CLB, Azure Load Balancer/Application Gateway, GCP Cloud Load Balancing, OCI Load Balancer/Network Load Balancer
 - **Software load balancers**: Nginx, HAProxy, Envoy Proxy, Traefik, Istio Gateway
 - **Layer 4/7 load balancing**: TCP/UDP load balancing, HTTP/HTTPS application load balancing
 - **Global load balancing**: Multi-region traffic distribution, geo-routing, failover strategies
@@ -30,7 +31,7 @@ Expert network engineer with comprehensive knowledge of cloud networking, modern
 
 ### DNS & Service Discovery
 
-- **DNS systems**: BIND, PowerDNS, cloud DNS services (Route 53, Azure DNS, Cloud DNS)
+- **DNS systems**: BIND, PowerDNS, cloud DNS services (Route 53, Azure DNS, Cloud DNS, OCI DNS)
 - **Service discovery**: Consul, etcd, Kubernetes DNS, service mesh service discovery
 - **DNS security**: DNSSEC, DNS over HTTPS (DoH), DNS over TLS (DoT)
 - **Traffic management**: DNS-based routing, health checks, failover, geo-routing
@@ -79,14 +80,14 @@ Expert network engineer with comprehensive knowledge of cloud networking, modern
 ### Network Troubleshooting & Analysis
 
 - **Diagnostic tools**: tcpdump, Wireshark, ss, netstat, iperf3, mtr, nmap
-- **Cloud-specific tools**: VPC Flow Logs, Azure NSG Flow Logs, GCP VPC Flow Logs
+- **Cloud-specific tools**: VPC Flow Logs, Azure NSG Flow Logs, GCP VPC Flow Logs, OCI VCN Flow Logs
 - **Application layer**: curl, wget, dig, nslookup, host, openssl s_client
 - **Performance analysis**: Network latency, throughput testing, packet loss analysis
 - **Traffic analysis**: Deep packet inspection, flow analysis, anomaly detection
 
 ### Infrastructure Integration
 
-- **Infrastructure as Code**: Network automation with Terraform, CloudFormation, Ansible
+- **Infrastructure as Code**: Network automation with Terraform, CloudFormation, OCI Resource Manager, Ansible
 - **Network automation**: Python networking (Netmiko, NAPALM), Ansible network modules
 - **CI/CD integration**: Network testing, configuration validation, automated deployment
 - **Policy as Code**: Network policy automation, compliance checking, drift detection
@@ -131,7 +132,7 @@ Expert network engineer with comprehensive knowledge of cloud networking, modern
 
 ## Knowledge Base
 
-- Cloud networking services across AWS, Azure, and GCP
+- Cloud networking services across AWS, Azure, GCP, and OCI
 - Modern networking protocols and technologies
 - Network security best practices and zero-trust architectures
 - Service mesh and container networking patterns

plugins/cloud-infrastructure/agents/terraform-specialist.md

@@ -75,7 +75,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 
 ### Multi-Cloud & Hybrid
 
-- **Multi-cloud patterns**: Provider abstraction, cloud-agnostic modules
+- **Multi-cloud patterns**: Provider abstraction, cloud-agnostic modules, AWS/Azure/GCP/OCI composition
 - **Hybrid deployments**: On-premises integration, edge computing, hybrid connectivity
 - **Cross-provider dependencies**: Resource sharing, data passing between providers
 - **Cost optimization**: Resource tagging, cost estimation, optimization recommendations
@@ -83,7 +83,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 
 ### Modern IaC Ecosystem
 
-- **Alternative tools**: Pulumi, AWS CDK, Azure Bicep, Google Deployment Manager
+- **Alternative tools**: Pulumi, AWS CDK, Azure Bicep, Google Infrastructure Manager, OCI Resource Manager
 - **Complementary tools**: Helm, Kustomize, Ansible integration
 - **State alternatives**: Stateless deployments, immutable infrastructure patterns
 - **GitOps workflows**: ArgoCD, Flux integration, continuous reconciliation
@@ -121,7 +121,7 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 ## Knowledge Base
 
 - Terraform/OpenTofu syntax, functions, and best practices
-- Major cloud provider services and their Terraform representations
+- Major cloud provider services and their Terraform representations, including OCI networking, identity, and database services
 - Infrastructure patterns and architectural best practices
 - CI/CD tools and automation strategies
 - Security frameworks and compliance requirements
@@ -149,5 +149,6 @@ Expert Infrastructure as Code specialist with comprehensive knowledge of Terrafo
 - "Migrate existing Terraform codebase to OpenTofu with minimal disruption"
 - "Implement policy as code validation for infrastructure compliance and cost control"
 - "Design multi-cloud Terraform architecture with provider abstraction"
+- "Create reusable Terraform modules for OCI networking and OKE foundations"
 - "Troubleshoot state corruption and implement recovery procedures"
 - "Create enterprise service catalog with approved infrastructure modules"

plugins/cloud-infrastructure/skills/cost-optimization/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: cost-optimization
-description: Optimize cloud costs through resource rightsizing, tagging strategies, reserved instances, and spending analysis. Use when reducing cloud expenses, analyzing infrastructure costs, or implementing cost governance policies.
+description: Optimize cloud costs across AWS, Azure, GCP, and OCI through resource rightsizing, tagging strategies, reserved instances, and spending analysis. Use when reducing cloud expenses, analyzing infrastructure costs, or implementing cost governance policies.
 ---
 
 # Cloud Cost Optimization
 
-Strategies and patterns for optimizing cloud costs across AWS, Azure, and GCP.
+Strategies and patterns for optimizing cloud costs across AWS, Azure, GCP, and OCI.
 
 ## Purpose
 
@@ -149,6 +149,26 @@ resource "aws_s3_bucket_lifecycle_configuration" "example" {
 - 24-hour maximum runtime
 - Best for batch workloads
 
+## OCI Cost Optimization
+
+### Flexible Shapes
+
+- Scale OCPUs and memory independently
+- Match instance sizing to workload demand
+- Reduce wasted capacity from fixed VM shapes
+
+### Commitments and Budgets
+
+- Use annual commitments for predictable spend
+- Set compartment-level budgets with alerts
+- Track monthly forecasts with OCI Cost Analysis
+
+### Preemptible Capacity
+
+- Use preemptible instances for batch and ephemeral workloads
+- Keep interruption-tolerant autoscaling groups
+- Mix with standard capacity for critical services
+
 ## Tagging Strategy
 
 ### AWS Tagging
@@ -208,6 +228,7 @@ resource "aws_budgets_budget" "monthly" {
 - AWS Cost Anomaly Detection
 - Azure Cost Management alerts
 - GCP Budget alerts
+- OCI Budgets and Cost Analysis
 
 ## Architecture Patterns
 
@@ -282,12 +303,9 @@ resource "aws_cloudwatch_metric_alarm" "cpu_high" {
 - **AWS:** Cost Explorer, Cost Anomaly Detection, Compute Optimizer
 - **Azure:** Cost Management, Advisor
 - **GCP:** Cost Management, Recommender
+- **OCI:** Cost Analysis, Budgets, Cloud Advisor
 - **Multi-cloud:** CloudHealth, Cloudability, Kubecost
 
-## Reference Files
-
-- `references/tagging-standards.md` - Tagging conventions
-- `assets/cost-analysis-template.xlsx` - Cost analysis spreadsheet
 
 ## Related Skills
 

plugins/cloud-infrastructure/skills/cost-optimization/references/tagging-standards.md

@@ -0,0 +1,23 @@
+# Cloud Tagging Standards
+
+## Required Tags
+
+- `Environment`: dev, staging, production
+- `Owner`: team or individual responsible for the workload
+- `CostCenter`: finance or reporting identifier
+- `Project`: product or initiative name
+- `ManagedBy`: terraform, opentofu, pulumi, or manual
+
+## Provider Notes
+
+- AWS: standardize tags for Cost Explorer, CUR, and automation policies
+- Azure: align tags with management groups, subscriptions, and Azure Policy
+- GCP: combine labels and resource hierarchy for billing attribution
+- OCI: apply defined tags at the compartment and resource level for chargeback
+
+## Best Practices
+
+1. Publish an approved tag dictionary and naming rules.
+2. Enforce tags with policy and CI validation.
+3. Inherit tags from shared modules whenever possible.
+4. Audit for missing or inconsistent tags weekly.

plugins/cloud-infrastructure/skills/hybrid-cloud-networking/SKILL.md

@@ -5,11 +5,11 @@ description: Configure secure, high-performance connectivity between on-premises
 
 # Hybrid Cloud Networking
 
-Configure secure, high-performance connectivity between on-premises and cloud environments using VPN, Direct Connect, and ExpressRoute.
+Configure secure, high-performance connectivity between on-premises and cloud environments using VPN, Direct Connect, ExpressRoute, Interconnect, and FastConnect.
 
 ## Purpose
 
-Establish secure, reliable network connectivity between on-premises data centers and cloud providers (AWS, Azure, GCP).
+Establish secure, reliable network connectivity between on-premises data centers and cloud providers (AWS, Azure, GCP, OCI).
 
 ## When to Use
 
@@ -105,6 +105,20 @@ resource "azurerm_virtual_network_gateway" "vpn" {
 - Partner (50 Mbps to 50 Gbps)
 - Lower latency than VPN
 
+### OCI Connectivity
+
+#### 1. IPSec VPN Connect
+
+- IPSec VPN with redundant tunnels
+- Dynamic routing through DRG
+- Good fit for branch offices and migration phases
+
+#### 2. OCI FastConnect
+
+- Private dedicated connectivity through Oracle or partner edge
+- Suitable for predictable throughput and lower-latency hybrid traffic
+- Commonly paired with DRG for hub-and-spoke designs
+
 ## Hybrid Network Patterns
 
 ### Pattern 1: Hub-and-Spoke
@@ -137,7 +151,8 @@ On-Premises
 On-Premises Datacenter
     ├─ Direct Connect → AWS
     ├─ ExpressRoute → Azure
-    └─ Interconnect → GCP
+    ├─ Interconnect → GCP
+    └─ FastConnect → OCI
 ```
 
 ## Routing Configuration
@@ -150,7 +165,7 @@ On-Premises Router:
 - Advertise: 10.0.0.0/8
 
 Cloud Router:
-- AS Number: 64512 (AWS), 65515 (Azure)
+- AS Number: 64512 (AWS), 65515 (Azure), provider-assigned for GCP/OCI
 - Advertise: Cloud VPC/VNet CIDRs
 ```
 
@@ -163,14 +178,14 @@ Cloud Router:
 
 ## Security Best Practices
 
-1. **Use private connectivity** (Direct Connect/ExpressRoute)
+1. **Use private connectivity** (Direct Connect/ExpressRoute/Interconnect/FastConnect)
 2. **Implement encryption** for VPN tunnels
 3. **Use VPC endpoints** to avoid internet routing
 4. **Configure network ACLs** and security groups
 5. **Enable VPC Flow Logs** for monitoring
 6. **Implement DDoS protection**
 7. **Use PrivateLink/Private Endpoints**
-8. **Monitor connections** with CloudWatch/Monitor
+8. **Monitor connections** with CloudWatch/Azure Monitor/Cloud Monitoring/OCI Monitoring
 9. **Implement redundancy** (dual tunnels)
 10. **Regular security audits**
 
@@ -219,6 +234,10 @@ aws ec2 get-vpn-connection-telemetry
 # Azure VPN
 az network vpn-connection show
 az network vpn-connection show-device-config-script
+
+# OCI IPSec VPN
+oci network ip-sec-connection list
+oci network cpe list
 ```
 
 ## Cost Optimization
@@ -227,13 +246,9 @@ az network vpn-connection show-device-config-script
 2. **Use VPN for low-bandwidth** workloads
 3. **Consolidate traffic** through fewer connections
 4. **Minimize data transfer** costs
-5. **Use Direct Connect** for high bandwidth
+5. **Use dedicated private links** for high bandwidth
 6. **Implement caching** to reduce traffic
 
-## Reference Files
-
-- `references/vpn-setup.md` - VPN configuration guide
-- `references/direct-connect.md` - Direct Connect setup
 
 ## Related Skills
 

plugins/cloud-infrastructure/skills/hybrid-cloud-networking/references/direct-connect.md

@@ -0,0 +1,17 @@
+# Dedicated Connectivity Comparison
+
+## Private Connectivity Options
+
+| Provider | Service | Typical Use |
+| -------- | ------- | ----------- |
+| AWS | Direct Connect | Private connectivity into VPCs and Transit Gateway domains |
+| Azure | ExpressRoute | Dedicated enterprise connectivity into VNets and Microsoft services |
+| GCP | Cloud Interconnect | Dedicated or partner connectivity into VPCs |
+| OCI | FastConnect | Private connectivity into VCNs through DRG attachments |
+
+## Design Guidance
+
+1. Prefer redundant circuits in separate facilities for production workloads.
+2. Terminate private links into central transit or hub networking layers.
+3. Use VPN as backup even when dedicated links are primary.
+4. Validate BGP advertisements, failover behavior, and MTU assumptions during testing.

plugins/cloud-infrastructure/skills/istio-traffic-management/SKILL.md

@@ -319,9 +319,3 @@ istioctl proxy-config endpoints deploy/my-app
 # Debug traffic
 istioctl proxy-config log deploy/my-app --level debug
 ```
-
-## Resources
-
-- [Istio Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/)
-- [Virtual Service Reference](https://istio.io/latest/docs/reference/config/networking/virtual-service/)
-- [Destination Rule Reference](https://istio.io/latest/docs/reference/config/networking/destination-rule/)

plugins/cloud-infrastructure/skills/linkerd-patterns/SKILL.md

@@ -303,9 +303,3 @@ linkerd viz tap deploy/my-app --to deploy/my-backend
 - **Don't over-configure** - Linkerd defaults are sensible
 - **Don't ignore ServiceProfiles** - They unlock advanced features
 - **Don't forget timeouts** - Set appropriate values per route
-
-## Resources
-
-- [Linkerd Documentation](https://linkerd.io/2.14/overview/)
-- [Service Profiles](https://linkerd.io/2.14/features/service-profiles/)
-- [Authorization Policy](https://linkerd.io/2.14/features/server-policy/)

plugins/cloud-infrastructure/skills/mtls-configuration/SKILL.md

@@ -340,10 +340,3 @@ linkerd viz tap deploy/my-app --to deploy/my-backend
 - **Don't ignore cert expiry** - Automate rotation
 - **Don't use self-signed certs** - Use proper CA hierarchy
 - **Don't skip verification** - Verify the full chain
-
-## Resources
-
-- [Istio Security](https://istio.io/latest/docs/concepts/security/)
-- [SPIFFE/SPIRE](https://spiffe.io/)
-- [cert-manager](https://cert-manager.io/)
-- [Zero Trust Architecture (NIST)](https://www.nist.gov/publications/zero-trust-architecture)