Reorganize: Move all skills to skills/ folder

- Created skills/ directory
- Moved 272 skills to skills/ subfolder
- Kept agents/ at root level
- Kept installation scripts and docs at root level

Repository structure:
- skills/           - All 272 skills from skills.sh
- agents/           - Agent definitions
- *.sh, *.ps1       - Installation scripts
- README.md, etc.   - Documentation

Co-Authored-By: Claude <noreply@anthropic.com>

skills/plugins/claude-delegator/rules/triggers.md

@@ -0,0 +1,147 @@
+# Delegation Triggers
+
+This file defines when to delegate to GPT experts via Codex.
+
+## IMPORTANT: Check These Triggers on EVERY Message
+
+You MUST scan incoming messages for delegation triggers. This is NOT optional.
+
+**Behavior:**
+1. **PROACTIVE**: On every user message, check if semantic triggers match → delegate automatically
+2. **REACTIVE**: If user explicitly mentions GPT/Codex → delegate immediately
+
+When a trigger matches:
+1. Identify the appropriate expert
+2. Read their prompt file from `${CLAUDE_PLUGIN_ROOT}/prompts/[expert].md`
+3. Follow the delegation flow in `rules/orchestration.md`
+
+---
+
+## Available Experts
+
+| Expert | Specialty | Use For |
+|--------|-----------|---------|
+| **Architect** | System design, tradeoffs | Architecture decisions, complex debugging |
+| **Plan Reviewer** | Plan validation | Reviewing work plans before execution |
+| **Scope Analyst** | Pre-planning analysis | Catching ambiguities before work starts |
+| **Code Reviewer** | Code quality, bugs | Reviewing code changes, finding issues |
+| **Security Analyst** | Vulnerabilities, threats | Security audits, hardening |
+
+## Explicit Triggers (Highest Priority)
+
+User explicitly requests delegation:
+
+| Phrase Pattern | Expert |
+|----------------|--------|
+| "ask GPT", "consult GPT" | Route based on context |
+| "review this architecture" | Architect |
+| "review this plan" | Plan Reviewer |
+| "analyze the scope" | Scope Analyst |
+| "review this code" | Code Reviewer |
+| "security review", "is this secure" | Security Analyst |
+
+## Semantic Triggers (Intent Matching)
+
+### Architecture & Design (→ Architect)
+
+| Intent Pattern | Example |
+|----------------|---------|
+| "how should I structure" | "How should I structure this service?" |
+| "what are the tradeoffs" | "Tradeoffs of this caching approach" |
+| "should I use [A] or [B]" | "Should I use microservices or monolith?" |
+| System design questions | "Design a notification system" |
+| After 2+ failed fix attempts | Escalation for fresh perspective |
+
+### Plan Validation (→ Plan Reviewer)
+
+| Intent Pattern | Example |
+|----------------|---------|
+| "review this plan" | "Review my migration plan" |
+| "is this plan complete" | "Is this implementation plan complete?" |
+| "validate before I start" | "Validate my approach before starting" |
+| Before significant work | Pre-execution validation |
+
+### Requirements Analysis (→ Scope Analyst)
+
+| Intent Pattern | Example |
+|----------------|---------|
+| "what am I missing" | "What am I missing in these requirements?" |
+| "clarify the scope" | "Help clarify the scope of this feature" |
+| Vague or ambiguous requests | Before planning unclear work |
+| "before we start" | Pre-planning consultation |
+
+### Code Review (→ Code Reviewer)
+
+| Intent Pattern | Example |
+|----------------|---------|
+| "review this code" | "Review this PR" |
+| "find issues in" | "Find issues in this implementation" |
+| "what's wrong with" | "What's wrong with this function?" |
+| After implementing features | Self-review before merge |
+
+### Security (→ Security Analyst)
+
+| Intent Pattern | Example |
+|----------------|---------|
+| "security implications" | "Security implications of this auth flow" |
+| "is this secure" | "Is this token handling secure?" |
+| "vulnerabilities in" | "Any vulnerabilities in this code?" |
+| "threat model" | "Threat model for this API" |
+| "harden this" | "Harden this endpoint" |
+
+## Trigger Priority
+
+1. **Explicit user request** - Always honor direct requests
+2. **Security concerns** - When handling sensitive data/auth
+3. **Architecture decisions** - System design with long-term impact
+4. **Failure escalation** - After 2+ failed attempts
+5. **Don't delegate** - Default: handle directly
+
+## When NOT to Delegate
+
+| Situation | Reason |
+|-----------|--------|
+| Simple syntax questions | Answer directly |
+| Direct file operations | No external insight needed |
+| Trivial bug fixes | Obvious solution |
+| Research/documentation | Use other tools |
+| First attempt at any fix | Try yourself first |
+
+## Advisory vs Implementation Mode
+
+Any expert can operate in two modes:
+
+| Mode | Sandbox | When to Use |
+|------|---------|-------------|
+| **Advisory** | `read-only` | Analysis, recommendations, review verdicts |
+| **Implementation** | `workspace-write` | Actually making changes, fixing issues |
+
+Set the sandbox based on what the task requires, not the expert type.
+
+**Examples:**
+
+```typescript
+// Architect analyzing (advisory)
+mcp__codex__codex({
+  prompt: "Analyze tradeoffs of Redis vs in-memory caching",
+  sandbox: "read-only"
+})
+
+// Architect implementing (implementation)
+mcp__codex__codex({
+  prompt: "Refactor the caching layer to use Redis",
+  sandbox: "workspace-write"
+})
+
+// Security Analyst reviewing (advisory)
+mcp__codex__codex({
+  prompt: "Review this auth flow for vulnerabilities",
+  sandbox: "read-only"
+})
+
+// Security Analyst hardening (implementation)
+mcp__codex__codex({
+  prompt: "Fix the SQL injection vulnerability in user.ts",
+  sandbox: "workspace-write"
+})
+```