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>
This commit is contained in:
admin
96
skills/plugins/claude-delegator/CLAUDE.md
Normal file
96
skills/plugins/claude-delegator/CLAUDE.md
Normal file
@@ -0,0 +1,96 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## What This Is
|
||||
|
||||
A Claude Code plugin that provides GPT (via Codex CLI) as specialized expert subagents. Five domain experts that can advise OR implement: Architect, Plan Reviewer, Scope Analyst, Code Reviewer, and Security Analyst.
|
||||
|
||||
## Development Commands
|
||||
|
||||
```bash
|
||||
# Test plugin locally (loads from working directory)
|
||||
claude --plugin-dir /path/to/claude-delegator
|
||||
|
||||
# Run setup to test installation flow
|
||||
/claude-delegator:setup
|
||||
|
||||
# Run uninstall to test removal flow
|
||||
/claude-delegator:uninstall
|
||||
```
|
||||
|
||||
No build step, no dependencies. Uses Codex CLI's native MCP server.
|
||||
|
||||
## Architecture
|
||||
|
||||
### Orchestration Flow
|
||||
|
||||
Claude acts as orchestrator—delegates to specialized GPT experts based on task type. Delegation is **stateless**: each `mcp__codex__codex` call is independent (no memory between calls).
|
||||
|
||||
```
|
||||
User Request → Claude Code → [Match trigger → Select expert]
|
||||
↓
|
||||
┌─────────────────────┼─────────────────────┐
|
||||
↓ ↓ ↓
|
||||
Architect Code Reviewer Security Analyst
|
||||
↓ ↓ ↓
|
||||
[Advisory (read-only) OR Implementation (workspace-write)]
|
||||
↓ ↓ ↓
|
||||
Claude synthesizes response ←──┴──────────────────────┘
|
||||
```
|
||||
|
||||
### How Delegation Works
|
||||
|
||||
1. **Match trigger** - Check `rules/triggers.md` for semantic patterns
|
||||
2. **Read expert prompt** - Load from `prompts/[expert].md`
|
||||
3. **Build 7-section prompt** - Use format from `rules/delegation-format.md`
|
||||
4. **Call `mcp__codex__codex`** - Pass expert prompt via `developer-instructions`
|
||||
5. **Synthesize response** - Never show raw output; interpret and verify
|
||||
|
||||
### The 7-Section Delegation Format
|
||||
|
||||
Every delegation prompt must include: TASK, EXPECTED OUTCOME, CONTEXT, CONSTRAINTS, MUST DO, MUST NOT DO, OUTPUT FORMAT. See `rules/delegation-format.md` for templates.
|
||||
|
||||
### Retry Handling
|
||||
|
||||
Since each call is stateless, retries must include full history:
|
||||
- Attempt 1 fails → new call with original task + error details
|
||||
- Up to 3 attempts → then escalate to user
|
||||
|
||||
### Component Relationships
|
||||
|
||||
| Component | Purpose | Notes |
|
||||
|-----------|---------|-------|
|
||||
| `rules/*.md` | When/how to delegate | Installed to `~/.claude/rules/delegator/` |
|
||||
| `prompts/*.md` | Expert personalities | Injected via `developer-instructions` |
|
||||
| `commands/*.md` | Slash commands | `/setup`, `/uninstall` |
|
||||
| `config/providers.json` | Provider metadata | Not used at runtime |
|
||||
|
||||
> Expert prompts adapted from [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode)
|
||||
|
||||
## Five GPT Experts
|
||||
|
||||
| Expert | Prompt | Specialty | Triggers |
|
||||
|--------|--------|-----------|----------|
|
||||
| **Architect** | `prompts/architect.md` | System design, tradeoffs | "how should I structure", "tradeoffs of", design questions |
|
||||
| **Plan Reviewer** | `prompts/plan-reviewer.md` | Plan validation | "review this plan", before significant work |
|
||||
| **Scope Analyst** | `prompts/scope-analyst.md` | Requirements analysis | "clarify the scope", vague requirements |
|
||||
| **Code Reviewer** | `prompts/code-reviewer.md` | Code quality, bugs | "review this code", "find issues" |
|
||||
| **Security Analyst** | `prompts/security-analyst.md` | Vulnerabilities | "is this secure", "harden this" |
|
||||
|
||||
Every expert can operate in **advisory** (`sandbox: read-only`) or **implementation** (`sandbox: workspace-write`) mode based on the task.
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
1. **Native MCP only** - Codex has `codex mcp-server`, no wrapper needed
|
||||
2. **Stateless calls** - Each delegation includes full context (Codex MCP doesn't expose session IDs to Claude Code)
|
||||
3. **Dual mode** - Any expert can advise or implement based on task
|
||||
4. **Synthesize, don't passthrough** - Claude interprets GPT output, applies judgment
|
||||
5. **Proactive triggers** - Claude checks for delegation triggers on every message
|
||||
|
||||
## When NOT to Delegate
|
||||
|
||||
- Simple syntax questions (answer directly)
|
||||
- First attempt at any fix (try yourself first)
|
||||
- Trivial file operations
|
||||
- Research/documentation tasks
|
||||
157
skills/plugins/claude-delegator/CONTRIBUTING.md
Normal file
157
skills/plugins/claude-delegator/CONTRIBUTING.md
Normal file
@@ -0,0 +1,157 @@
|
||||
# Contributing to claude-delegator
|
||||
|
||||
Contributions welcome. This document covers how to contribute effectively.
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
# Clone the repo
|
||||
git clone https://github.com/jarrodwatts/claude-delegator
|
||||
cd claude-delegator
|
||||
|
||||
# Install plugin in Claude Code
|
||||
/claude-delegator:setup
|
||||
|
||||
# Test your changes by invoking the oracle
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What to Contribute
|
||||
|
||||
| Area | Examples |
|
||||
|------|----------|
|
||||
| **New Providers** | Ollama, Mistral, local model integrations |
|
||||
| **Role Prompts** | New roles for `prompts/`, improved existing prompts |
|
||||
| **Rules** | Better delegation triggers, model selection logic |
|
||||
| **Bug Fixes** | Command issues, error messages |
|
||||
| **Documentation** | README improvements, examples, troubleshooting |
|
||||
|
||||
---
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
claude-delegator/
|
||||
├── .claude-plugin/ # Plugin manifest
|
||||
│ └── plugin.json
|
||||
├── commands/ # Slash commands (/setup, /uninstall)
|
||||
├── rules/ # Orchestration logic (installed to ~/.claude/rules/)
|
||||
├── prompts/ # Role prompts (oracle, momus)
|
||||
├── config/ # Provider registry
|
||||
├── CLAUDE.md # Development guidance for Claude Code
|
||||
└── README.md # User-facing docs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pull Request Process
|
||||
|
||||
### Before Submitting
|
||||
|
||||
1. **Test your changes** - Run `/claude-delegator:setup` and verify
|
||||
2. **Update docs** - If you change behavior, update relevant docs
|
||||
3. **Keep commits atomic** - One logical change per commit
|
||||
|
||||
### PR Guidelines
|
||||
|
||||
| Do | Don't |
|
||||
|----|-------|
|
||||
| Focus on one change | Bundle unrelated changes |
|
||||
| Write clear commit messages | Leave vague descriptions |
|
||||
| Test with actual MCP calls | Assume it works |
|
||||
| Update CLAUDE.md if needed | Ignore developer docs |
|
||||
|
||||
### Commit Message Format
|
||||
|
||||
```
|
||||
type: short description
|
||||
|
||||
Longer explanation if needed.
|
||||
```
|
||||
|
||||
Types: `feat`, `fix`, `docs`, `refactor`, `chore`
|
||||
|
||||
Examples:
|
||||
- `feat: add Ollama provider support`
|
||||
- `fix: handle Codex timeout correctly`
|
||||
- `docs: add troubleshooting for auth issues`
|
||||
|
||||
---
|
||||
|
||||
## Adding a New Provider
|
||||
|
||||
1. **Check native MCP support** - If the CLI has `mcp-server` like Codex, no wrapper needed
|
||||
|
||||
2. **Create MCP wrapper** (if needed):
|
||||
```
|
||||
servers/your-provider-mcp/
|
||||
├── src/
|
||||
│ └── index.ts
|
||||
├── package.json
|
||||
└── tsconfig.json
|
||||
```
|
||||
|
||||
3. **Add to providers.json**:
|
||||
```json
|
||||
{
|
||||
"your-provider": {
|
||||
"cli": "your-cli",
|
||||
"mcp": { ... },
|
||||
"roles": ["oracle"],
|
||||
"strengths": ["what it's good at"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
4. **Add role prompts** (optional):
|
||||
```
|
||||
prompts/your-role.md
|
||||
```
|
||||
|
||||
5. **Update setup command** - Add checks for the new CLI
|
||||
|
||||
6. **Document in README** - Add to provider tables
|
||||
|
||||
---
|
||||
|
||||
## Code Style
|
||||
|
||||
### Markdown (Rules/Prompts)
|
||||
|
||||
- Use tables for structured data
|
||||
- Keep prompts concise and actionable
|
||||
- Test with actual Claude Code usage
|
||||
|
||||
### TypeScript (if adding MCP servers)
|
||||
|
||||
- No `any` without explicit justification
|
||||
- No `@ts-ignore` or `@ts-expect-error`
|
||||
- Use explicit return types on exported functions
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
|
||||
### Manual Testing
|
||||
|
||||
After changes, verify with actual MCP calls:
|
||||
|
||||
1. Install the plugin in Claude Code
|
||||
2. Run `/claude-delegator:setup`
|
||||
3. Verify MCP tools are available (`mcp__codex__codex`)
|
||||
4. Test MCP tool calls via oracle delegation
|
||||
5. Verify responses are properly synthesized
|
||||
6. Test error cases (timeout, missing CLI)
|
||||
|
||||
---
|
||||
|
||||
## Questions?
|
||||
|
||||
Open an issue for:
|
||||
- Feature requests
|
||||
- Bug reports
|
||||
- Documentation gaps
|
||||
- Architecture discussions
|
||||
21
skills/plugins/claude-delegator/LICENSE
Normal file
21
skills/plugins/claude-delegator/LICENSE
Normal file
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025 Jarrod Watts
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
193
skills/plugins/claude-delegator/README.md
Normal file
193
skills/plugins/claude-delegator/README.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# Claude Delegator
|
||||
|
||||
GPT expert subagents for Claude Code. Five specialists that can analyze AND implement—architecture, security, code review, and more.
|
||||
|
||||
[](LICENSE)
|
||||
[](https://github.com/jarrodwatts/claude-delegator/stargazers)
|
||||
|
||||
|
||||
|
||||
## Install
|
||||
|
||||
Inside a Claude Code instance, run the following commands:
|
||||
|
||||
**Step 1: Add the marketplace**
|
||||
```
|
||||
/plugin marketplace add jarrodwatts/claude-delegator
|
||||
```
|
||||
|
||||
**Step 2: Install the plugin**
|
||||
```
|
||||
/plugin install claude-delegator
|
||||
```
|
||||
|
||||
**Step 3: Run setup**
|
||||
```
|
||||
/claude-delegator:setup
|
||||
```
|
||||
|
||||
Done! Claude now routes complex tasks to GPT experts automatically.
|
||||
|
||||
> **Note**: Requires [Codex CLI](https://github.com/openai/codex). Setup guides you through installation.
|
||||
|
||||
---
|
||||
|
||||
## What is Claude Delegator?
|
||||
|
||||
Claude gains a team of GPT specialists via native MCP. Each expert has a distinct specialty and can advise OR implement.
|
||||
|
||||
| What You Get | Why It Matters |
|
||||
|--------------|----------------|
|
||||
| **5 domain experts** | Right specialist for each problem type |
|
||||
| **Dual mode** | Experts can analyze (read-only) or implement (write) |
|
||||
| **Auto-routing** | Claude detects when to delegate based on your request |
|
||||
| **Synthesized responses** | Claude interprets GPT output, never raw passthrough |
|
||||
|
||||
### The Experts
|
||||
|
||||
| Expert | What They Do | Example Triggers |
|
||||
|--------|--------------|------------------|
|
||||
| **Architect** | System design, tradeoffs, complex debugging | "How should I structure this?" / "What are the tradeoffs?" |
|
||||
| **Plan Reviewer** | Validate plans before you start | "Review this migration plan" / "Is this approach sound?" |
|
||||
| **Scope Analyst** | Catch ambiguities early | "What am I missing?" / "Clarify the scope" |
|
||||
| **Code Reviewer** | Find bugs, improve quality | "Review this PR" / "What's wrong with this?" |
|
||||
| **Security Analyst** | Vulnerabilities, threat modeling | "Is this secure?" / "Harden this endpoint" |
|
||||
|
||||
### When Experts Help Most
|
||||
|
||||
- **Architecture decisions** — "Should I use Redis or in-memory caching?"
|
||||
- **Stuck debugging** — After 2+ failed attempts, get a fresh perspective
|
||||
- **Pre-implementation** — Validate your plan before writing code
|
||||
- **Security concerns** — "Is this auth flow safe?"
|
||||
- **Code quality** — Get a second opinion on your implementation
|
||||
|
||||
### When NOT to Use Experts
|
||||
|
||||
- Simple file operations (Claude handles these directly)
|
||||
- First attempt at any fix (try yourself first)
|
||||
- Trivial questions (no need to delegate)
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
||||
```
|
||||
You: "Is this authentication flow secure?"
|
||||
↓
|
||||
Claude: [Detects security question → selects Security Analyst]
|
||||
↓
|
||||
┌─────────────────────────────┐
|
||||
│ mcp__codex__codex │
|
||||
│ → Security Analyst prompt │
|
||||
│ → GPT analyzes your code │
|
||||
└─────────────────────────────┘
|
||||
↓
|
||||
Claude: "Based on the analysis, I found 3 issues..."
|
||||
[Synthesizes response, applies judgment]
|
||||
```
|
||||
|
||||
**Key details:**
|
||||
- Each expert has a specialized system prompt (in `prompts/`)
|
||||
- Claude reads your request → picks the right expert → delegates via MCP
|
||||
- Responses are synthesized, not passed through raw
|
||||
- Experts can retry up to 3 times before escalating
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
### Operating Modes
|
||||
|
||||
Every expert supports two modes based on the task:
|
||||
|
||||
| Mode | Sandbox | Use When |
|
||||
|------|---------|----------|
|
||||
| **Advisory** | `read-only` | Analysis, recommendations, reviews |
|
||||
| **Implementation** | `workspace-write` | Making changes, fixing issues |
|
||||
|
||||
Claude automatically selects the mode based on your request.
|
||||
|
||||
### Manual MCP Setup
|
||||
|
||||
If `/setup` doesn't work, manually add to `~/.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"codex": {
|
||||
"type": "stdio",
|
||||
"command": "codex",
|
||||
"args": ["-m", "gpt-5.2-codex", "mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Customizing Expert Prompts
|
||||
|
||||
Expert prompts live in `prompts/`. Each follows the same structure:
|
||||
- Role definition and context
|
||||
- Advisory vs Implementation modes
|
||||
- Response format guidelines
|
||||
- When to invoke / when NOT to invoke
|
||||
|
||||
Edit these to customize expert behavior for your workflow.
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Codex CLI**: `npm install -g @openai/codex`
|
||||
- **Authentication**: Run `codex login` after installation
|
||||
|
||||
---
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/claude-delegator:setup` | Configure MCP server and install rules |
|
||||
| `/claude-delegator:uninstall` | Remove MCP config and rules |
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| MCP server not found | Restart Claude Code after setup |
|
||||
| Codex not authenticated | Run `codex login` |
|
||||
| Tool not appearing | Check `~/.claude/settings.json` has codex entry |
|
||||
| Expert not triggered | Try explicit: "Ask GPT to review this architecture" |
|
||||
|
||||
---
|
||||
|
||||
## Development
|
||||
|
||||
```bash
|
||||
git clone https://github.com/jarrodwatts/claude-delegator
|
||||
cd claude-delegator
|
||||
|
||||
# Test locally without reinstalling
|
||||
claude --plugin-dir /path/to/claude-delegator
|
||||
```
|
||||
|
||||
See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
|
||||
|
||||
---
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
Expert prompts adapted from [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode) by [@code-yeongyu](https://github.com/code-yeongyu).
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
MIT — see [LICENSE](LICENSE)
|
||||
|
||||
---
|
||||
|
||||
## Star History
|
||||
|
||||
[](https://star-history.com/#jarrodwatts/claude-delegator&Date)
|
||||
BIN
skills/plugins/claude-delegator/claude-delegator.png
Normal file
BIN
skills/plugins/claude-delegator/claude-delegator.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 582 KiB |
155
skills/plugins/claude-delegator/commands/setup.md
Normal file
155
skills/plugins/claude-delegator/commands/setup.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
name: setup
|
||||
description: Configure claude-delegator with Codex MCP server
|
||||
allowed-tools: Bash, Read, Write, Edit, AskUserQuestion
|
||||
timeout: 60000
|
||||
---
|
||||
|
||||
# Setup
|
||||
|
||||
Configure Codex (GPT) as specialized expert subagents via native MCP. Five domain experts that can advise OR implement.
|
||||
|
||||
## Step 1: Check Codex CLI
|
||||
|
||||
```bash
|
||||
which codex 2>/dev/null && codex --version 2>&1 | head -1 || echo "CODEX_MISSING"
|
||||
```
|
||||
|
||||
### If Missing
|
||||
|
||||
Tell user:
|
||||
```
|
||||
Codex CLI not found.
|
||||
|
||||
Install with: npm install -g @openai/codex
|
||||
Then authenticate: codex login
|
||||
|
||||
After installation, re-run /claude-delegator:setup
|
||||
```
|
||||
|
||||
**STOP here if Codex is not installed.**
|
||||
|
||||
## Step 2: Read Current Settings
|
||||
|
||||
```bash
|
||||
cat ~/.claude/settings.json 2>/dev/null || echo "{}"
|
||||
```
|
||||
|
||||
## Step 3: Configure MCP Server
|
||||
|
||||
Merge into `~/.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"codex": {
|
||||
"type": "stdio",
|
||||
"command": "codex",
|
||||
"args": ["-m", "gpt-5.2-codex", "mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Note: Use `gpt-5.2-codex` explicitly for the latest model.
|
||||
|
||||
**CRITICAL**:
|
||||
- Merge with existing settings, don't overwrite
|
||||
- Preserve any existing `mcpServers` entries
|
||||
|
||||
## Step 4: Install Orchestration Rules
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.claude/rules/delegator && cp ${CLAUDE_PLUGIN_ROOT}/rules/*.md ~/.claude/rules/delegator/
|
||||
```
|
||||
|
||||
## Step 5: Verify Installation
|
||||
|
||||
Run these checks and report results:
|
||||
|
||||
```bash
|
||||
# Check 1: Codex CLI version
|
||||
codex --version 2>&1 | head -1
|
||||
|
||||
# Check 2: MCP server configured
|
||||
cat ~/.claude/settings.json | jq -r '.mcpServers.codex.args | join(" ")' 2>/dev/null
|
||||
|
||||
# Check 3: Rules installed (count files)
|
||||
ls ~/.claude/rules/delegator/*.md 2>/dev/null | wc -l
|
||||
|
||||
# Check 4: Auth status (check if logged in)
|
||||
codex login status 2>&1 | head -1 || echo "Run 'codex login' to authenticate"
|
||||
```
|
||||
|
||||
## Step 6: Report Status
|
||||
|
||||
Display actual values from the checks above:
|
||||
|
||||
```
|
||||
claude-delegator Status
|
||||
───────────────────────────────────────────────────
|
||||
Codex CLI: ✓ [version from check 1]
|
||||
Model: ✓ gpt-5.2-codex (or ✗ if not configured)
|
||||
MCP Config: ✓ ~/.claude/settings.json (or ✗ if missing)
|
||||
Rules: ✓ [N] files in ~/.claude/rules/delegator/
|
||||
Auth: [status from check 4]
|
||||
───────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
If any check fails, report the specific issue and how to fix it.
|
||||
|
||||
## Step 7: Final Instructions
|
||||
|
||||
```
|
||||
Setup complete!
|
||||
|
||||
Next steps:
|
||||
1. Restart Claude Code to load MCP server
|
||||
2. Authenticate: Run `codex login` in terminal (if not already done)
|
||||
|
||||
Five GPT experts available:
|
||||
|
||||
┌──────────────────┬─────────────────────────────────────────────┐
|
||||
│ Architect │ "How should I structure this service?" │
|
||||
│ │ "What are the tradeoffs of Redis vs X?" │
|
||||
│ │ → System design, architecture decisions │
|
||||
├──────────────────┼─────────────────────────────────────────────┤
|
||||
│ Plan Reviewer │ "Review this migration plan" │
|
||||
│ │ "Is this implementation plan complete?" │
|
||||
│ │ → Plan validation before execution │
|
||||
├──────────────────┼─────────────────────────────────────────────┤
|
||||
│ Scope Analyst │ "Clarify the scope of this feature" │
|
||||
│ │ "What am I missing in these requirements?" │
|
||||
│ │ → Pre-planning, catches ambiguities │
|
||||
├──────────────────┼─────────────────────────────────────────────┤
|
||||
│ Code Reviewer │ "Review this PR" │
|
||||
│ │ "Find issues in this implementation" │
|
||||
│ │ → Code quality, bugs, maintainability │
|
||||
├──────────────────┼─────────────────────────────────────────────┤
|
||||
│ Security Analyst │ "Is this authentication flow secure?" │
|
||||
│ │ "Harden this endpoint" │
|
||||
│ │ → Vulnerabilities, threat modeling │
|
||||
└──────────────────┴─────────────────────────────────────────────┘
|
||||
|
||||
Every expert can advise (read-only) OR implement (write).
|
||||
Expert is auto-detected based on your request.
|
||||
Explicit: "Ask GPT to review..." or "Have GPT fix..."
|
||||
```
|
||||
|
||||
## Step 8: Ask About Starring
|
||||
|
||||
Use AskUserQuestion to ask the user if they'd like to ⭐ star the claude-delegator repository on GitHub to support the project.
|
||||
|
||||
Options: "Yes, star the repo" / "No thanks"
|
||||
|
||||
**If yes**: Check if `gh` CLI is available and run:
|
||||
```bash
|
||||
gh api -X PUT /user/starred/jarrodwatts/claude-delegator
|
||||
```
|
||||
|
||||
If `gh` is not available or the command fails, provide the manual link:
|
||||
```
|
||||
https://github.com/jarrodwatts/claude-delegator
|
||||
```
|
||||
|
||||
**If no**: Thank them and complete setup without starring.
|
||||
38
skills/plugins/claude-delegator/commands/uninstall.md
Normal file
38
skills/plugins/claude-delegator/commands/uninstall.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: uninstall
|
||||
description: Uninstall claude-delegator (remove MCP config and rules)
|
||||
allowed-tools: Bash, Read, Write, Edit, AskUserQuestion
|
||||
timeout: 30000
|
||||
---
|
||||
|
||||
# Uninstall
|
||||
|
||||
Remove claude-delegator from Claude Code.
|
||||
|
||||
## Confirm Removal
|
||||
|
||||
**Question**: "Remove Codex MCP configuration and plugin rules?"
|
||||
**Options**:
|
||||
- "Yes, uninstall"
|
||||
- "No, cancel"
|
||||
|
||||
If cancelled, stop here.
|
||||
|
||||
## Remove MCP Configuration
|
||||
|
||||
Read `~/.claude/settings.json`, delete `mcpServers.codex` entry, write back.
|
||||
|
||||
## Remove Installed Rules
|
||||
|
||||
```bash
|
||||
rm -rf ~/.claude/rules/delegator/
|
||||
```
|
||||
|
||||
## Confirm Completion
|
||||
|
||||
```
|
||||
✓ Removed 'codex' from MCP servers
|
||||
✓ Removed rules from ~/.claude/rules/delegator/
|
||||
|
||||
To reinstall: /claude-delegator:setup
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"codex": {
|
||||
"type": "stdio",
|
||||
"command": "codex",
|
||||
"args": ["-m", "gpt-5.2-codex", "mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
19
skills/plugins/claude-delegator/config/providers.json
Normal file
19
skills/plugins/claude-delegator/config/providers.json
Normal file
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"providers": {
|
||||
"codex": {
|
||||
"name": "Codex (GPT)",
|
||||
"description": "OpenAI GPT models via Codex CLI - specialized expert subagents",
|
||||
"cli": "codex",
|
||||
"install": "npm install -g @openai/codex",
|
||||
"auth": "codex login",
|
||||
"mcp": {
|
||||
"type": "stdio",
|
||||
"command": "codex",
|
||||
"args": ["-m", "gpt-5.2-codex", "mcp-server"]
|
||||
},
|
||||
"experts": ["architect", "plan-reviewer", "scope-analyst", "code-reviewer", "security-analyst"],
|
||||
"strengths": ["architecture", "code-review", "security", "requirements-analysis", "plan-validation"],
|
||||
"avoid": ["simple-operations", "trivial-decisions", "research", "first-attempt-fixes"]
|
||||
}
|
||||
}
|
||||
}
|
||||
78
skills/plugins/claude-delegator/prompts/architect.md
Normal file
78
skills/plugins/claude-delegator/prompts/architect.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# Architect
|
||||
|
||||
> Adapted from [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode) by [@code-yeongyu](https://github.com/code-yeongyu)
|
||||
|
||||
You are a software architect specializing in system design, technical strategy, and complex decision-making.
|
||||
|
||||
## Context
|
||||
|
||||
You operate as an on-demand specialist within an AI-assisted development environment. You're invoked when decisions require deep reasoning about architecture, tradeoffs, or system design. Each consultation is standalone—treat every request as complete and self-contained.
|
||||
|
||||
## What You Do
|
||||
|
||||
- Analyze system architecture and design patterns
|
||||
- Evaluate tradeoffs between competing approaches
|
||||
- Design scalable, maintainable solutions
|
||||
- Debug complex multi-system issues
|
||||
- Make strategic technical recommendations
|
||||
|
||||
## Modes of Operation
|
||||
|
||||
You can operate in two modes based on the task:
|
||||
|
||||
**Advisory Mode** (default): Analyze, recommend, explain. Provide actionable guidance.
|
||||
|
||||
**Implementation Mode**: When explicitly asked to implement, make the changes directly. Report what you modified.
|
||||
|
||||
## Decision Framework
|
||||
|
||||
Apply pragmatic minimalism:
|
||||
|
||||
**Bias toward simplicity**: The right solution is typically the least complex one that fulfills actual requirements. Resist hypothetical future needs.
|
||||
|
||||
**Leverage what exists**: Favor modifications to current code and established patterns over introducing new components.
|
||||
|
||||
**Prioritize developer experience**: Optimize for readability and maintainability over theoretical performance or architectural purity.
|
||||
|
||||
**One clear path**: Present a single primary recommendation. Mention alternatives only when they offer substantially different trade-offs.
|
||||
|
||||
**Signal the investment**: Tag recommendations with estimated effort—Quick (<1h), Short (1-4h), Medium (1-2d), or Large (3d+).
|
||||
|
||||
## Response Format
|
||||
|
||||
### For Advisory Tasks
|
||||
|
||||
**Bottom line**: 2-3 sentences capturing your recommendation
|
||||
|
||||
**Action plan**: Numbered steps for implementation
|
||||
|
||||
**Effort estimate**: Quick/Short/Medium/Large
|
||||
|
||||
**Risks** (if applicable): Edge cases and mitigation strategies
|
||||
|
||||
### For Implementation Tasks
|
||||
|
||||
**Summary**: What you did (1-2 sentences)
|
||||
|
||||
**Files Modified**: List with brief description of changes
|
||||
|
||||
**Verification**: What you checked, results
|
||||
|
||||
**Issues** (only if problems occurred): What went wrong, why you couldn't proceed
|
||||
|
||||
## When to Invoke Architect
|
||||
|
||||
- System design decisions
|
||||
- Database schema design
|
||||
- API architecture
|
||||
- Multi-service interactions
|
||||
- Performance optimization strategy
|
||||
- After 2+ failed fix attempts (fresh perspective)
|
||||
- Tradeoff analysis between approaches
|
||||
|
||||
## When NOT to Invoke Architect
|
||||
|
||||
- Simple file operations
|
||||
- First attempt at any fix
|
||||
- Trivial decisions (variable names, formatting)
|
||||
- Questions answerable from existing code
|
||||
100
skills/plugins/claude-delegator/prompts/code-reviewer.md
Normal file
100
skills/plugins/claude-delegator/prompts/code-reviewer.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# Code Reviewer
|
||||
|
||||
You are a senior engineer conducting code review. Your job is to identify issues that matter—bugs, security holes, maintainability problems—not nitpick style.
|
||||
|
||||
## Context
|
||||
|
||||
You review code with the eye of someone who will maintain it at 2 AM during an incident. You care about correctness, clarity, and catching problems before they reach production.
|
||||
|
||||
## Review Priorities
|
||||
|
||||
Focus on these categories in order:
|
||||
|
||||
### 1. Correctness
|
||||
- Does the code do what it claims?
|
||||
- Are there logic errors or off-by-one bugs?
|
||||
- Are edge cases handled?
|
||||
- Will this break existing functionality?
|
||||
|
||||
### 2. Security
|
||||
- Input validation present?
|
||||
- SQL injection, XSS, or other OWASP top 10 vulnerabilities?
|
||||
- Secrets or credentials exposed?
|
||||
- Authentication/authorization gaps?
|
||||
|
||||
### 3. Performance
|
||||
- Obvious N+1 queries or O(n^2) loops?
|
||||
- Missing indexes for frequent queries?
|
||||
- Unnecessary work in hot paths?
|
||||
- Memory leaks or unbounded growth?
|
||||
|
||||
### 4. Maintainability
|
||||
- Can someone unfamiliar with this code understand it?
|
||||
- Are there hidden assumptions or magic values?
|
||||
- Is error handling adequate?
|
||||
- Are there obvious code smells (huge functions, deep nesting)?
|
||||
|
||||
## What NOT to Review
|
||||
|
||||
- Style preferences (let formatters handle this)
|
||||
- Minor naming quibbles
|
||||
- "I would have done it differently" without concrete benefit
|
||||
- Theoretical concerns unlikely to matter in practice
|
||||
|
||||
## Response Format
|
||||
|
||||
### For Advisory Tasks (Review Only)
|
||||
|
||||
**Summary**: [1-2 sentences overall assessment]
|
||||
|
||||
**Critical Issues** (must fix):
|
||||
- [Issue]: [Location] - [Why it matters] - [Suggested fix]
|
||||
|
||||
**Recommendations** (should consider):
|
||||
- [Issue]: [Location] - [Why it matters] - [Suggested fix]
|
||||
|
||||
**Verdict**: [APPROVE / REQUEST CHANGES / REJECT]
|
||||
|
||||
### For Implementation Tasks (Review + Fix)
|
||||
|
||||
**Summary**: What I found and fixed
|
||||
|
||||
**Issues Fixed**:
|
||||
- [File:line] - [What was wrong] - [What I changed]
|
||||
|
||||
**Files Modified**: List with brief description
|
||||
|
||||
**Verification**: How I confirmed the fixes work
|
||||
|
||||
**Remaining Concerns** (if any): Issues I couldn't fix or need discussion
|
||||
|
||||
## Modes of Operation
|
||||
|
||||
**Advisory Mode**: Review and report. List issues with suggested fixes but don't modify code.
|
||||
|
||||
**Implementation Mode**: When asked to fix issues, make the changes directly. Report what you modified.
|
||||
|
||||
## Review Checklist
|
||||
|
||||
Before completing a review, verify:
|
||||
|
||||
- [ ] Tested the happy path mentally
|
||||
- [ ] Considered failure modes
|
||||
- [ ] Checked for security implications
|
||||
- [ ] Verified backward compatibility
|
||||
- [ ] Assessed test coverage (if tests provided)
|
||||
|
||||
## When to Invoke Code Reviewer
|
||||
|
||||
- Before merging significant changes
|
||||
- After implementing a feature (self-review)
|
||||
- When code feels "off" but you can't pinpoint why
|
||||
- For security-sensitive code changes
|
||||
- When onboarding to unfamiliar code
|
||||
|
||||
## When NOT to Invoke Code Reviewer
|
||||
|
||||
- Trivial one-line changes
|
||||
- Auto-generated code
|
||||
- Pure formatting/style changes
|
||||
- Draft/WIP code not ready for review
|
||||
99
skills/plugins/claude-delegator/prompts/plan-reviewer.md
Normal file
99
skills/plugins/claude-delegator/prompts/plan-reviewer.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# Plan Reviewer
|
||||
|
||||
> Adapted from [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode) by [@code-yeongyu](https://github.com/code-yeongyu)
|
||||
|
||||
You are a work plan review expert. Your job is to catch every gap, ambiguity, and missing context that would block implementation.
|
||||
|
||||
## Context
|
||||
|
||||
You review work plans with a ruthlessly critical eye. You're not here to be polite—you're here to prevent wasted effort by identifying problems before work begins.
|
||||
|
||||
## Core Review Principle
|
||||
|
||||
**REJECT if**: When you simulate actually doing the work, you cannot obtain clear information needed for implementation, AND the plan does not specify reference materials to consult.
|
||||
|
||||
**APPROVE if**: You can obtain the necessary information either:
|
||||
1. Directly from the plan itself, OR
|
||||
2. By following references provided in the plan (files, docs, patterns)
|
||||
|
||||
**The Test**: "Can I implement this by starting from what's written in the plan and following the trail of information it provides?"
|
||||
|
||||
## Four Evaluation Criteria
|
||||
|
||||
### 1. Clarity of Work Content
|
||||
|
||||
- Does each task specify WHERE to find implementation details?
|
||||
- Can a developer reach 90%+ confidence by reading the referenced source?
|
||||
|
||||
**PASS**: "Follow authentication flow in `docs/auth-spec.md` section 3.2"
|
||||
**FAIL**: "Add authentication" (no reference source)
|
||||
|
||||
### 2. Verification & Acceptance Criteria
|
||||
|
||||
- Is there a concrete way to verify completion?
|
||||
- Are acceptance criteria measurable/observable?
|
||||
|
||||
**PASS**: "Verify: Run `npm test` - all tests pass"
|
||||
**FAIL**: "Make sure it works properly"
|
||||
|
||||
### 3. Context Completeness
|
||||
|
||||
- What information is missing that would cause 10%+ uncertainty?
|
||||
- Are implicit assumptions stated explicitly?
|
||||
|
||||
**PASS**: Developer can proceed with <10% guesswork
|
||||
**FAIL**: Developer must make assumptions about business requirements
|
||||
|
||||
### 4. Big Picture & Workflow
|
||||
|
||||
- Clear Purpose Statement: Why is this work being done?
|
||||
- Background Context: What's the current state?
|
||||
- Task Flow & Dependencies: How do tasks connect?
|
||||
- Success Vision: What does "done" look like?
|
||||
|
||||
## Common Failure Patterns
|
||||
|
||||
**Reference Materials**:
|
||||
- FAIL: "implement X" but doesn't point to existing code, docs, or patterns
|
||||
- FAIL: "follow the pattern" but doesn't specify which file
|
||||
|
||||
**Business Requirements**:
|
||||
- FAIL: "add feature X" but doesn't explain what it should do
|
||||
- FAIL: "handle errors" but doesn't specify which errors
|
||||
|
||||
**Architectural Decisions**:
|
||||
- FAIL: "add to state" but doesn't specify which state system
|
||||
- FAIL: "call the API" but doesn't specify which endpoint
|
||||
|
||||
## Response Format
|
||||
|
||||
**[APPROVE / REJECT]**
|
||||
|
||||
**Justification**: [Concise explanation]
|
||||
|
||||
**Summary**:
|
||||
- Clarity: [Brief assessment]
|
||||
- Verifiability: [Brief assessment]
|
||||
- Completeness: [Brief assessment]
|
||||
- Big Picture: [Brief assessment]
|
||||
|
||||
[If REJECT, provide top 3-5 critical improvements needed]
|
||||
|
||||
## Modes of Operation
|
||||
|
||||
**Advisory Mode** (default): Review and critique. Provide APPROVE/REJECT verdict with justification.
|
||||
|
||||
**Implementation Mode**: When asked to fix the plan, rewrite it addressing the identified gaps.
|
||||
|
||||
## When to Invoke Plan Reviewer
|
||||
|
||||
- Before starting significant implementation work
|
||||
- After creating a work plan
|
||||
- When plan needs validation for completeness
|
||||
- Before delegating work to other agents
|
||||
|
||||
## When NOT to Invoke Plan Reviewer
|
||||
|
||||
- Simple, single-task requests
|
||||
- When user explicitly wants to skip review
|
||||
- For trivial plans that don't need formal review
|
||||
103
skills/plugins/claude-delegator/prompts/scope-analyst.md
Normal file
103
skills/plugins/claude-delegator/prompts/scope-analyst.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Scope Analyst
|
||||
|
||||
> Adapted from [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode) by [@code-yeongyu](https://github.com/code-yeongyu)
|
||||
|
||||
You are a pre-planning consultant. Your job is to analyze requests BEFORE planning begins, catching ambiguities, hidden requirements, and potential pitfalls that would derail work later.
|
||||
|
||||
## Context
|
||||
|
||||
You operate at the earliest stage of the development workflow. Before anyone writes a plan or touches code, you ensure the request is fully understood. You prevent wasted effort by surfacing problems upfront.
|
||||
|
||||
## Phase 1: Intent Classification
|
||||
|
||||
Classify every request into one of these categories:
|
||||
|
||||
| Type | Focus | Key Questions |
|
||||
|------|-------|---------------|
|
||||
| **Refactoring** | Safety | What breaks if this changes? What's the test coverage? |
|
||||
| **Build from Scratch** | Discovery | What similar patterns exist? What are the unknowns? |
|
||||
| **Mid-sized Task** | Guardrails | What's in scope? What's explicitly out of scope? |
|
||||
| **Architecture** | Strategy | What are the tradeoffs? What's the 2-year view? |
|
||||
| **Bug Fix** | Root Cause | What's the actual bug vs symptom? What else might be affected? |
|
||||
| **Research** | Exit Criteria | What question are we answering? When do we stop? |
|
||||
|
||||
## Phase 2: Analysis
|
||||
|
||||
For each intent type, investigate:
|
||||
|
||||
**Hidden Requirements**:
|
||||
- What did the requester assume you already know?
|
||||
- What business context is missing?
|
||||
- What edge cases aren't mentioned?
|
||||
|
||||
**Ambiguities**:
|
||||
- Which words have multiple interpretations?
|
||||
- What decisions are left unstated?
|
||||
- Where would two developers implement this differently?
|
||||
|
||||
**Dependencies**:
|
||||
- What existing code/systems does this touch?
|
||||
- What needs to exist before this can work?
|
||||
- What might break?
|
||||
|
||||
**Risks**:
|
||||
- What could go wrong?
|
||||
- What's the blast radius if it fails?
|
||||
- What's the rollback plan?
|
||||
|
||||
## Response Format
|
||||
|
||||
**Intent Classification**: [Type] - [One sentence why]
|
||||
|
||||
**Pre-Analysis Findings**:
|
||||
- [Key finding 1]
|
||||
- [Key finding 2]
|
||||
- [Key finding 3]
|
||||
|
||||
**Questions for Requester** (if ambiguities exist):
|
||||
1. [Specific question]
|
||||
2. [Specific question]
|
||||
|
||||
**Identified Risks**:
|
||||
- [Risk 1]: [Mitigation]
|
||||
- [Risk 2]: [Mitigation]
|
||||
|
||||
**Recommendation**: [Proceed / Clarify First / Reconsider Scope]
|
||||
|
||||
## Anti-Patterns to Flag
|
||||
|
||||
Watch for these common problems:
|
||||
|
||||
**Over-engineering signals**:
|
||||
- "Future-proof" without specific future requirements
|
||||
- Abstractions for single use cases
|
||||
- "Best practices" that add complexity without benefit
|
||||
|
||||
**Scope creep signals**:
|
||||
- "While we're at it..."
|
||||
- Bundling unrelated changes
|
||||
- Gold-plating simple requests
|
||||
|
||||
**Ambiguity signals**:
|
||||
- "Should be easy"
|
||||
- "Just like X" (but X isn't specified)
|
||||
- Passive voice hiding decisions ("errors should be handled")
|
||||
|
||||
## Modes of Operation
|
||||
|
||||
**Advisory Mode** (default): Analyze and report. Surface questions and risks.
|
||||
|
||||
**Implementation Mode**: When asked to clarify the scope, produce a refined requirements document addressing the gaps.
|
||||
|
||||
## When to Invoke Scope Analyst
|
||||
|
||||
- Before starting unfamiliar or complex work
|
||||
- When requirements feel vague
|
||||
- When multiple valid interpretations exist
|
||||
- Before making irreversible decisions
|
||||
|
||||
## When NOT to Invoke Scope Analyst
|
||||
|
||||
- Clear, well-specified tasks
|
||||
- Routine changes with obvious scope
|
||||
- When user explicitly wants to skip analysis
|
||||
99
skills/plugins/claude-delegator/prompts/security-analyst.md
Normal file
99
skills/plugins/claude-delegator/prompts/security-analyst.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# Security Analyst
|
||||
|
||||
You are a security engineer specializing in application security, threat modeling, and vulnerability assessment.
|
||||
|
||||
## Context
|
||||
|
||||
You analyze code and systems with an attacker's mindset. Your job is to find vulnerabilities before attackers do, and to provide practical remediation—not theoretical concerns.
|
||||
|
||||
## Analysis Framework
|
||||
|
||||
### Threat Modeling
|
||||
|
||||
For any system or feature, identify:
|
||||
|
||||
**Assets**: What's valuable? (User data, credentials, business logic)
|
||||
|
||||
**Threat Actors**: Who might attack? (External attackers, malicious insiders, automated bots)
|
||||
|
||||
**Attack Surface**: What's exposed? (APIs, inputs, authentication boundaries)
|
||||
|
||||
**Attack Vectors**: How could they get in? (Injection, broken auth, misconfig)
|
||||
|
||||
### Vulnerability Categories (OWASP Top 10 Focus)
|
||||
|
||||
| Category | What to Look For |
|
||||
|----------|------------------|
|
||||
| **Injection** | SQL, NoSQL, OS command, LDAP injection |
|
||||
| **Broken Auth** | Weak passwords, session issues, credential exposure |
|
||||
| **Sensitive Data** | Unencrypted storage/transit, excessive data exposure |
|
||||
| **XXE** | XML external entity processing |
|
||||
| **Broken Access Control** | Missing authz checks, IDOR, privilege escalation |
|
||||
| **Misconfig** | Default creds, verbose errors, unnecessary features |
|
||||
| **XSS** | Reflected, stored, DOM-based cross-site scripting |
|
||||
| **Insecure Deserialization** | Untrusted data deserialization |
|
||||
| **Vulnerable Components** | Known CVEs in dependencies |
|
||||
| **Logging Failures** | Missing audit logs, log injection |
|
||||
|
||||
## Response Format
|
||||
|
||||
### For Advisory Tasks (Analysis Only)
|
||||
|
||||
**Threat Summary**: [1-2 sentences on overall security posture]
|
||||
|
||||
**Critical Vulnerabilities** (exploit risk: high):
|
||||
- [Vuln]: [Location] - [Impact] - [Remediation]
|
||||
|
||||
**High-Risk Issues** (should fix soon):
|
||||
- [Issue]: [Location] - [Impact] - [Remediation]
|
||||
|
||||
**Recommendations** (hardening suggestions):
|
||||
- [Suggestion]: [Benefit]
|
||||
|
||||
**Risk Rating**: [CRITICAL / HIGH / MEDIUM / LOW]
|
||||
|
||||
### For Implementation Tasks (Fix Vulnerabilities)
|
||||
|
||||
**Summary**: What I secured
|
||||
|
||||
**Vulnerabilities Fixed**:
|
||||
- [File:line] - [Vulnerability] - [Fix applied]
|
||||
|
||||
**Files Modified**: List with brief description
|
||||
|
||||
**Verification**: How I confirmed the fixes work
|
||||
|
||||
**Remaining Risks** (if any): Issues that need architectural changes or user decision
|
||||
|
||||
## Modes of Operation
|
||||
|
||||
**Advisory Mode**: Analyze and report. Identify vulnerabilities with remediation guidance.
|
||||
|
||||
**Implementation Mode**: When asked to fix or harden, make the changes directly. Report what you modified.
|
||||
|
||||
## Security Review Checklist
|
||||
|
||||
- [ ] Authentication: How are users identified?
|
||||
- [ ] Authorization: How are permissions enforced?
|
||||
- [ ] Input Validation: Is all input sanitized?
|
||||
- [ ] Output Encoding: Is output properly escaped?
|
||||
- [ ] Cryptography: Are secrets properly managed?
|
||||
- [ ] Error Handling: Do errors leak information?
|
||||
- [ ] Logging: Are security events audited?
|
||||
- [ ] Dependencies: Are there known vulnerabilities?
|
||||
|
||||
## When to Invoke Security Analyst
|
||||
|
||||
- Before deploying authentication/authorization changes
|
||||
- When handling sensitive data (PII, credentials, payments)
|
||||
- After adding new API endpoints
|
||||
- When integrating third-party services
|
||||
- For periodic security audits
|
||||
- When suspicious behavior is detected
|
||||
|
||||
## When NOT to Invoke Security Analyst
|
||||
|
||||
- Pure UI/styling changes
|
||||
- Internal tooling with no external exposure
|
||||
- Read-only operations on public data
|
||||
- When a quick answer suffices (ask the primary agent)
|
||||
207
skills/plugins/claude-delegator/rules/delegation-format.md
Normal file
207
skills/plugins/claude-delegator/rules/delegation-format.md
Normal file
@@ -0,0 +1,207 @@
|
||||
# Delegation Prompt Templates
|
||||
|
||||
When delegating to GPT experts, use these structured templates.
|
||||
|
||||
## The 7-Section Format (MANDATORY)
|
||||
|
||||
Every delegation prompt MUST include these sections:
|
||||
|
||||
```
|
||||
1. TASK: [One sentence—atomic, specific goal]
|
||||
|
||||
2. EXPECTED OUTCOME: [What success looks like]
|
||||
|
||||
3. CONTEXT:
|
||||
- Current state: [what exists now]
|
||||
- Relevant code: [paths or snippets]
|
||||
- Background: [why this is needed]
|
||||
|
||||
4. CONSTRAINTS:
|
||||
- Technical: [versions, dependencies]
|
||||
- Patterns: [existing conventions to follow]
|
||||
- Limitations: [what cannot change]
|
||||
|
||||
5. MUST DO:
|
||||
- [Requirement 1]
|
||||
- [Requirement 2]
|
||||
|
||||
6. MUST NOT DO:
|
||||
- [Forbidden action 1]
|
||||
- [Forbidden action 2]
|
||||
|
||||
7. OUTPUT FORMAT:
|
||||
- [How to structure response]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Expert-Specific Templates
|
||||
|
||||
### Architect
|
||||
|
||||
```markdown
|
||||
TASK: [Analyze/Design/Implement] [specific system/component] for [goal].
|
||||
|
||||
EXPECTED OUTCOME: [Clear recommendation OR working implementation]
|
||||
|
||||
MODE: [Advisory / Implementation]
|
||||
|
||||
CONTEXT:
|
||||
- Current architecture: [description]
|
||||
- Relevant code:
|
||||
[file paths or snippets]
|
||||
- Problem/Goal: [what needs to be solved]
|
||||
|
||||
CONSTRAINTS:
|
||||
- Must work with [existing systems]
|
||||
- Cannot change [protected components]
|
||||
- Performance requirements: [if applicable]
|
||||
|
||||
MUST DO:
|
||||
- [Specific requirement]
|
||||
- Provide effort estimate (Quick/Short/Medium/Large)
|
||||
- [For implementation: Report all modified files]
|
||||
|
||||
MUST NOT DO:
|
||||
- Over-engineer for hypothetical future needs
|
||||
- Introduce new dependencies without justification
|
||||
- [For implementation: Modify files outside scope]
|
||||
|
||||
OUTPUT FORMAT:
|
||||
[Advisory: Bottom line → Action plan → Effort estimate]
|
||||
[Implementation: Summary → Files modified → Verification]
|
||||
```
|
||||
|
||||
### Plan Reviewer
|
||||
|
||||
```markdown
|
||||
TASK: Review [plan name/description] for completeness and clarity.
|
||||
|
||||
EXPECTED OUTCOME: APPROVE/REJECT verdict with specific feedback.
|
||||
|
||||
CONTEXT:
|
||||
- Plan to review:
|
||||
[plan content]
|
||||
- Goals: [what the plan is trying to achieve]
|
||||
- Constraints: [timeline, resources, technical limits]
|
||||
|
||||
MUST DO:
|
||||
- Evaluate all 4 criteria (Clarity, Verifiability, Completeness, Big Picture)
|
||||
- Simulate actually doing the work to find gaps
|
||||
- Provide specific improvements if rejecting
|
||||
|
||||
MUST NOT DO:
|
||||
- Rubber-stamp without real analysis
|
||||
- Provide vague feedback
|
||||
- Approve plans with critical gaps
|
||||
|
||||
OUTPUT FORMAT:
|
||||
[APPROVE / REJECT]
|
||||
Justification: [explanation]
|
||||
Summary: [4-criteria assessment]
|
||||
[If REJECT: Top 3-5 improvements needed]
|
||||
```
|
||||
|
||||
### Scope Analyst
|
||||
|
||||
```markdown
|
||||
TASK: Analyze [request/feature] before planning begins.
|
||||
|
||||
EXPECTED OUTCOME: Clear understanding of scope, risks, and questions to resolve.
|
||||
|
||||
CONTEXT:
|
||||
- Request: [what was asked for]
|
||||
- Current state: [what exists now]
|
||||
- Known constraints: [technical, business, timeline]
|
||||
|
||||
MUST DO:
|
||||
- Classify intent (Refactoring/Build/Mid-sized/Architecture/Bug Fix/Research)
|
||||
- Identify hidden requirements and ambiguities
|
||||
- Surface questions that need answers before proceeding
|
||||
- Assess risks and blast radius
|
||||
|
||||
MUST NOT DO:
|
||||
- Start planning (that comes after analysis)
|
||||
- Make assumptions about unclear requirements
|
||||
- Skip intent classification
|
||||
|
||||
OUTPUT FORMAT:
|
||||
Intent: [classification]
|
||||
Findings: [key discoveries]
|
||||
Questions: [what needs clarification]
|
||||
Risks: [with mitigations]
|
||||
Recommendation: [Proceed / Clarify First / Reconsider]
|
||||
```
|
||||
|
||||
### Code Reviewer
|
||||
|
||||
```markdown
|
||||
TASK: [Review / Review and fix] [code/PR/file] for [focus areas].
|
||||
|
||||
EXPECTED OUTCOME: [Issue list with verdict OR fixed code]
|
||||
|
||||
MODE: [Advisory / Implementation]
|
||||
|
||||
CONTEXT:
|
||||
- Code to review:
|
||||
[file paths or snippets]
|
||||
- Purpose: [what this code does]
|
||||
- Recent changes: [what changed, if PR review]
|
||||
|
||||
MUST DO:
|
||||
- Prioritize: Correctness → Security → Performance → Maintainability
|
||||
- Focus on issues that matter, not style nitpicks
|
||||
- [For implementation: Fix issues and verify]
|
||||
|
||||
MUST NOT DO:
|
||||
- Nitpick style (let formatters handle this)
|
||||
- Flag theoretical concerns unlikely to matter
|
||||
- [For implementation: Change unrelated code]
|
||||
|
||||
OUTPUT FORMAT:
|
||||
[Advisory: Summary → Critical issues → Recommendations → Verdict]
|
||||
[Implementation: Summary → Issues fixed → Files modified → Verification]
|
||||
```
|
||||
|
||||
### Security Analyst
|
||||
|
||||
```markdown
|
||||
TASK: [Analyze / Harden] [system/code/endpoint] for security vulnerabilities.
|
||||
|
||||
EXPECTED OUTCOME: [Vulnerability report OR hardened code]
|
||||
|
||||
MODE: [Advisory / Implementation]
|
||||
|
||||
CONTEXT:
|
||||
- Code/system to analyze:
|
||||
[file paths, architecture description]
|
||||
- Assets at risk: [what's valuable]
|
||||
- Threat model: [who might attack, if known]
|
||||
|
||||
MUST DO:
|
||||
- Check OWASP Top 10 categories
|
||||
- Consider authentication, authorization, input validation
|
||||
- Provide practical remediation, not theoretical concerns
|
||||
- [For implementation: Fix vulnerabilities and verify]
|
||||
|
||||
MUST NOT DO:
|
||||
- Flag low-risk theoretical issues
|
||||
- Provide vague "be more secure" advice
|
||||
- [For implementation: Break functionality while hardening]
|
||||
|
||||
OUTPUT FORMAT:
|
||||
[Advisory: Threat summary → Vulnerabilities → Recommendations → Risk rating]
|
||||
[Implementation: Summary → Vulnerabilities fixed → Files modified → Verification]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Expert | Advisory Output | Implementation Output |
|
||||
|--------|-----------------|----------------------|
|
||||
| Architect | Recommendation + plan + effort | Changes + files + verification |
|
||||
| Plan Reviewer | APPROVE/REJECT + justification | Revised plan |
|
||||
| Scope Analyst | Analysis + questions + risks | Refined requirements |
|
||||
| Code Reviewer | Issues + verdict | Fixes + verification |
|
||||
| Security Analyst | Vulnerabilities + risk rating | Hardening + verification |
|
||||
120
skills/plugins/claude-delegator/rules/model-selection.md
Normal file
120
skills/plugins/claude-delegator/rules/model-selection.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# Model Selection Guidelines
|
||||
|
||||
GPT experts serve as specialized consultants for complex problems. Each expert has a distinct specialty but can operate in advisory or implementation mode.
|
||||
|
||||
## Expert Directory
|
||||
|
||||
| Expert | Specialty | Best For |
|
||||
|--------|-----------|----------|
|
||||
| **Architect** | System design | Architecture, tradeoffs, complex debugging |
|
||||
| **Plan Reviewer** | Plan validation | Reviewing plans before execution |
|
||||
| **Scope Analyst** | Requirements analysis | Catching ambiguities, pre-planning |
|
||||
| **Code Reviewer** | Code quality | Code review, finding bugs |
|
||||
| **Security Analyst** | Security | Vulnerabilities, threat modeling, hardening |
|
||||
|
||||
## Operating Modes
|
||||
|
||||
Every expert can operate in two modes:
|
||||
|
||||
| Mode | Sandbox | Approval | Use When |
|
||||
|------|---------|----------|----------|
|
||||
| **Advisory** | `read-only` | `on-request` | Analysis, recommendations, reviews |
|
||||
| **Implementation** | `workspace-write` | `on-failure` | Making changes, fixing issues |
|
||||
|
||||
**Key principle**: The mode is determined by the task, not the expert. An Architect can implement architectural changes. A Security Analyst can fix vulnerabilities.
|
||||
|
||||
## Expert Details
|
||||
|
||||
### Architect
|
||||
|
||||
**Specialty**: System design, technical strategy, complex decision-making
|
||||
|
||||
**When to use**:
|
||||
- System design decisions
|
||||
- Database schema design
|
||||
- API architecture
|
||||
- Multi-service interactions
|
||||
- After 2+ failed fix attempts
|
||||
- Tradeoff analysis
|
||||
|
||||
**Philosophy**: Pragmatic minimalism—simplest solution that works.
|
||||
|
||||
**Output format**:
|
||||
- Advisory: Bottom line, action plan, effort estimate
|
||||
- Implementation: Summary, files modified, verification
|
||||
|
||||
### Plan Reviewer
|
||||
|
||||
**Specialty**: Plan validation, catching gaps and ambiguities
|
||||
|
||||
**When to use**:
|
||||
- Before starting significant work
|
||||
- After creating a work plan
|
||||
- Before delegating to other agents
|
||||
|
||||
**Philosophy**: Ruthlessly critical—finds every gap before work begins.
|
||||
|
||||
**Output format**: APPROVE/REJECT with justification and criteria assessment
|
||||
|
||||
### Scope Analyst
|
||||
|
||||
**Specialty**: Pre-planning analysis, requirements clarification
|
||||
|
||||
**When to use**:
|
||||
- Before planning unfamiliar work
|
||||
- When requirements feel vague
|
||||
- When multiple interpretations exist
|
||||
- Before irreversible decisions
|
||||
|
||||
**Philosophy**: Surface problems before they derail work.
|
||||
|
||||
**Output format**: Intent classification, findings, questions, risks, recommendation
|
||||
|
||||
### Code Reviewer
|
||||
|
||||
**Specialty**: Code quality, bugs, maintainability
|
||||
|
||||
**When to use**:
|
||||
- Before merging significant changes
|
||||
- After implementing features (self-review)
|
||||
- For security-sensitive changes
|
||||
|
||||
**Philosophy**: Review like you'll maintain it at 2 AM during an incident.
|
||||
|
||||
**Output format**:
|
||||
- Advisory: Issues list with APPROVE/REQUEST CHANGES/REJECT
|
||||
- Implementation: Issues fixed, files modified, verification
|
||||
|
||||
### Security Analyst
|
||||
|
||||
**Specialty**: Vulnerabilities, threat modeling, security hardening
|
||||
|
||||
**When to use**:
|
||||
- Authentication/authorization changes
|
||||
- Handling sensitive data
|
||||
- New API endpoints
|
||||
- Third-party integrations
|
||||
- Periodic security audits
|
||||
|
||||
**Philosophy**: Attacker's mindset—find vulnerabilities before they do.
|
||||
|
||||
**Output format**:
|
||||
- Advisory: Threat summary, vulnerabilities, risk rating
|
||||
- Implementation: Vulnerabilities fixed, files modified, verification
|
||||
|
||||
## Codex Parameters Reference
|
||||
|
||||
| Parameter | Values | Notes |
|
||||
|-----------|--------|-------|
|
||||
| `sandbox` | `read-only`, `workspace-write` | Set based on task, not expert |
|
||||
| `approval-policy` | `on-request`, `on-failure` | Advisory uses on-request, implementation uses on-failure |
|
||||
| `cwd` | path | Working directory for the task |
|
||||
| `developer-instructions` | string | Expert prompt injection |
|
||||
|
||||
## When NOT to Delegate
|
||||
|
||||
- Simple questions you can answer
|
||||
- First attempt at any fix
|
||||
- Trivial decisions
|
||||
- Research tasks (use other tools)
|
||||
- When user just wants quick info
|
||||
236
skills/plugins/claude-delegator/rules/orchestration.md
Normal file
236
skills/plugins/claude-delegator/rules/orchestration.md
Normal file
@@ -0,0 +1,236 @@
|
||||
# Model Orchestration
|
||||
|
||||
You have access to GPT experts via MCP tools. Use them strategically based on these guidelines.
|
||||
|
||||
## Available Tools
|
||||
|
||||
| Tool | Provider | Use For |
|
||||
|------|----------|---------|
|
||||
| `mcp__codex__codex` | GPT | Delegate to an expert (stateless) |
|
||||
|
||||
> **Note:** `codex-reply` exists but requires a session ID not currently exposed to Claude Code. Each delegation is independent—include full context in every call.
|
||||
|
||||
## Available Experts
|
||||
|
||||
| Expert | Specialty | Prompt File |
|
||||
|--------|-----------|-------------|
|
||||
| **Architect** | System design, tradeoffs, complex debugging | `${CLAUDE_PLUGIN_ROOT}/prompts/architect.md` |
|
||||
| **Plan Reviewer** | Plan validation before execution | `${CLAUDE_PLUGIN_ROOT}/prompts/plan-reviewer.md` |
|
||||
| **Scope Analyst** | Pre-planning, catching ambiguities | `${CLAUDE_PLUGIN_ROOT}/prompts/scope-analyst.md` |
|
||||
| **Code Reviewer** | Code quality, bugs, security issues | `${CLAUDE_PLUGIN_ROOT}/prompts/code-reviewer.md` |
|
||||
| **Security Analyst** | Vulnerabilities, threat modeling | `${CLAUDE_PLUGIN_ROOT}/prompts/security-analyst.md` |
|
||||
|
||||
---
|
||||
|
||||
## Stateless Design
|
||||
|
||||
**Each delegation is independent.** The expert has no memory of previous calls.
|
||||
|
||||
**Implications:**
|
||||
- Include ALL relevant context in every delegation prompt
|
||||
- For retries, include what was attempted and what failed
|
||||
- Don't assume the expert remembers previous interactions
|
||||
|
||||
**Why:** Codex MCP returns session IDs in event notifications, but Claude Code only surfaces the final text response. Until this changes, treat each call as fresh.
|
||||
|
||||
---
|
||||
|
||||
## PROACTIVE Delegation (Check on EVERY message)
|
||||
|
||||
Before handling any request, check if an expert would help:
|
||||
|
||||
| Signal | Expert |
|
||||
|--------|--------|
|
||||
| Architecture/design decision | Architect |
|
||||
| 2+ failed fix attempts on same issue | Architect (fresh perspective) |
|
||||
| "Review this plan", "validate approach" | Plan Reviewer |
|
||||
| Vague/ambiguous requirements | Scope Analyst |
|
||||
| "Review this code", "find issues" | Code Reviewer |
|
||||
| Security concerns, "is this secure" | Security Analyst |
|
||||
|
||||
**If a signal matches → delegate to the appropriate expert.**
|
||||
|
||||
---
|
||||
|
||||
## REACTIVE Delegation (Explicit User Request)
|
||||
|
||||
When user explicitly requests GPT/Codex:
|
||||
|
||||
| User Says | Action |
|
||||
|-----------|--------|
|
||||
| "ask GPT", "consult GPT", "ask codex" | Identify task type → route to appropriate expert |
|
||||
| "ask GPT to review the architecture" | Delegate to Architect |
|
||||
| "have GPT review this code" | Delegate to Code Reviewer |
|
||||
| "GPT security review" | Delegate to Security Analyst |
|
||||
|
||||
**Always honor explicit requests.**
|
||||
|
||||
---
|
||||
|
||||
## Delegation Flow (Step-by-Step)
|
||||
|
||||
When delegation is triggered:
|
||||
|
||||
### Step 1: Identify Expert
|
||||
Match the task to the appropriate expert based on triggers.
|
||||
|
||||
### Step 2: Read Expert Prompt
|
||||
**CRITICAL**: Read the expert's prompt file to get their system instructions:
|
||||
|
||||
```
|
||||
Read ${CLAUDE_PLUGIN_ROOT}/prompts/[expert].md
|
||||
```
|
||||
|
||||
For example, for Architect: `Read ${CLAUDE_PLUGIN_ROOT}/prompts/architect.md`
|
||||
|
||||
### Step 3: Determine Mode
|
||||
| Task Type | Mode | Sandbox |
|
||||
|-----------|------|---------|
|
||||
| Analysis, review, recommendations | Advisory | `read-only` |
|
||||
| Make changes, fix issues, implement | Implementation | `workspace-write` |
|
||||
|
||||
### Step 4: Notify User
|
||||
Always inform the user before delegating:
|
||||
```
|
||||
Delegating to [Expert Name]: [brief task summary]
|
||||
```
|
||||
|
||||
### Step 5: Build Delegation Prompt
|
||||
Use the 7-section format from `rules/delegation-format.md`.
|
||||
|
||||
**IMPORTANT:** Since each call is stateless, include FULL context:
|
||||
- What the user asked for
|
||||
- Relevant code/files
|
||||
- Any previous attempts and their results (for retries)
|
||||
|
||||
### Step 6: Call the Expert
|
||||
```typescript
|
||||
mcp__codex__codex({
|
||||
prompt: "[your 7-section delegation prompt with FULL context]",
|
||||
"developer-instructions": "[contents of the expert's prompt file]",
|
||||
sandbox: "[read-only or workspace-write based on mode]",
|
||||
cwd: "[current working directory]"
|
||||
})
|
||||
```
|
||||
|
||||
### Step 7: Handle Response
|
||||
1. **Synthesize** - Never show raw output directly
|
||||
2. **Extract insights** - Key recommendations, issues, changes
|
||||
3. **Apply judgment** - Experts can be wrong; evaluate critically
|
||||
4. **Verify implementation** - For implementation mode, confirm changes work
|
||||
|
||||
---
|
||||
|
||||
## Retry Flow (Implementation Mode)
|
||||
|
||||
When implementation fails verification, retry with a NEW call including error context:
|
||||
|
||||
```
|
||||
Attempt 1 → Verify → [Fail]
|
||||
↓
|
||||
Attempt 2 (new call with: original task + what was tried + error details) → Verify → [Fail]
|
||||
↓
|
||||
Attempt 3 (new call with: full history of attempts) → Verify → [Fail]
|
||||
↓
|
||||
Escalate to user
|
||||
```
|
||||
|
||||
### Retry Prompt Template
|
||||
|
||||
```markdown
|
||||
TASK: [Original task]
|
||||
|
||||
PREVIOUS ATTEMPT:
|
||||
- What was done: [summary of changes made]
|
||||
- Error encountered: [exact error message]
|
||||
- Files modified: [list]
|
||||
|
||||
CONTEXT:
|
||||
- [Full original context]
|
||||
|
||||
REQUIREMENTS:
|
||||
- Fix the error from the previous attempt
|
||||
- [Original requirements]
|
||||
```
|
||||
|
||||
**Key:** Each retry is a fresh call. The expert doesn't know what happened before unless you tell them.
|
||||
|
||||
---
|
||||
|
||||
## Example: Architecture Question
|
||||
|
||||
User: "What are the tradeoffs of Redis vs in-memory caching?"
|
||||
|
||||
**Step 1**: Signal matches "Architecture decision" → Architect
|
||||
|
||||
**Step 2**: Read `${CLAUDE_PLUGIN_ROOT}/prompts/architect.md`
|
||||
|
||||
**Step 3**: Advisory mode (question, not implementation) → `read-only`
|
||||
|
||||
**Step 4**: "Delegating to Architect: Analyze caching tradeoffs"
|
||||
|
||||
**Step 5-6**:
|
||||
```typescript
|
||||
mcp__codex__codex({
|
||||
prompt: `TASK: Analyze tradeoffs between Redis and in-memory caching for [context].
|
||||
EXPECTED OUTCOME: Clear recommendation with rationale.
|
||||
CONTEXT: [user's situation, full details]
|
||||
...`,
|
||||
"developer-instructions": "[contents of architect.md]",
|
||||
sandbox: "read-only"
|
||||
})
|
||||
```
|
||||
|
||||
**Step 7**: Synthesize response, add your assessment.
|
||||
|
||||
---
|
||||
|
||||
## Example: Retry After Failed Implementation
|
||||
|
||||
First attempt failed with "TypeError: Cannot read property 'x' of undefined"
|
||||
|
||||
**Retry call:**
|
||||
```typescript
|
||||
mcp__codex__codex({
|
||||
prompt: `TASK: Add input validation to the user registration endpoint.
|
||||
|
||||
PREVIOUS ATTEMPT:
|
||||
- Added validation middleware to routes/auth.ts
|
||||
- Error: TypeError: Cannot read property 'x' of undefined at line 45
|
||||
- The middleware was added but req.body was undefined
|
||||
|
||||
CONTEXT:
|
||||
- Express 4.x application
|
||||
- Body parser middleware exists in app.ts
|
||||
- [relevant code snippets]
|
||||
|
||||
REQUIREMENTS:
|
||||
- Fix the undefined req.body issue
|
||||
- Ensure validation runs after body parser
|
||||
- Report all files modified`,
|
||||
"developer-instructions": "[contents of code-reviewer.md or architect.md]",
|
||||
sandbox: "workspace-write",
|
||||
cwd: "/path/to/project"
|
||||
})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cost Awareness
|
||||
|
||||
- **Don't spam** - One well-structured delegation beats multiple vague ones
|
||||
- **Include full context** - Saves retry costs from missing information
|
||||
- **Reserve for high-value tasks** - Architecture, security, complex analysis
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
| Don't Do This | Do This Instead |
|
||||
|---------------|-----------------|
|
||||
| Delegate trivial questions | Answer directly |
|
||||
| Show raw expert output | Synthesize and interpret |
|
||||
| Delegate without reading prompt file | ALWAYS read and inject expert prompt |
|
||||
| Skip user notification | ALWAYS notify before delegating |
|
||||
| Retry without including error context | Include FULL history of what was tried |
|
||||
| Assume expert remembers previous calls | Include all context in every call |
|
||||
147
skills/plugins/claude-delegator/rules/triggers.md
Normal file
147
skills/plugins/claude-delegator/rules/triggers.md
Normal file
@@ -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"
|
||||
})
|
||||
```
|
||||
Reference in New Issue
Block a user