Add comprehensive skills, agents, commands collection
- Added 44 external skills from obra/superpowers, ui-ux-pro-max-skill, claude-codex-settings - Added 8 autonomous agents (commit-creator, pr-creator, pr-reviewer, etc.) - Added 23 slash commands for Git/GitHub, setup, and plugin development - Added hooks for code formatting, notifications, and validation - Added MCP configurations for Azure, GCloud, Supabase, MongoDB, etc. - Added awesome-openclaw-skills registry (3,002 skills referenced) - Updated comprehensive README with full documentation Sources: - github.com/obra/superpowers (14 skills) - github.com/nextlevelbuilder/ui-ux-pro-max-skill (1 skill) - github.com/fcakyon/claude-codex-settings (29 skills, 8 agents, 23 commands) - github.com/VoltAgent/awesome-openclaw-skills (registry) - skills.sh (reference) - buildwithclaude.com (reference)
This commit is contained in:
uroma
92
commands/claude-codex-settings/azure-tools-setup.md
Normal file
92
commands/claude-codex-settings/azure-tools-setup.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
description: Configure Azure MCP server with Azure CLI authentication
|
||||
---
|
||||
|
||||
# Azure Tools Setup
|
||||
|
||||
Configure the Azure MCP server with Azure CLI authentication.
|
||||
|
||||
## Step 1: Check Prerequisites
|
||||
|
||||
Check if Azure CLI is installed:
|
||||
|
||||
```bash
|
||||
az --version
|
||||
```
|
||||
|
||||
Check if Node.js is installed:
|
||||
|
||||
```bash
|
||||
node --version
|
||||
```
|
||||
|
||||
Report status based on results.
|
||||
|
||||
## Step 2: Show Installation Guide
|
||||
|
||||
If Azure CLI is missing, tell the user:
|
||||
|
||||
```
|
||||
Azure CLI is required for Azure MCP authentication.
|
||||
|
||||
Install Azure CLI:
|
||||
- macOS: brew install azure-cli
|
||||
- Linux: curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
|
||||
- Windows: winget install Microsoft.AzureCLI
|
||||
|
||||
After installing, restart your terminal and run this setup again.
|
||||
```
|
||||
|
||||
If Node.js is missing, tell the user:
|
||||
|
||||
```
|
||||
Node.js 20 LTS or later is required for Azure MCP.
|
||||
|
||||
Install Node.js:
|
||||
- macOS: brew install node@20
|
||||
- Linux: curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && sudo apt-get install -y nodejs
|
||||
- Windows: winget install OpenJS.NodeJS.LTS
|
||||
|
||||
After installing, restart your terminal and run this setup again.
|
||||
```
|
||||
|
||||
## Step 3: Check Authentication
|
||||
|
||||
If prerequisites are installed, check Azure login status:
|
||||
|
||||
```bash
|
||||
az account show
|
||||
```
|
||||
|
||||
If not logged in, tell the user:
|
||||
|
||||
```
|
||||
You need to authenticate to Azure.
|
||||
|
||||
Run: az login
|
||||
|
||||
This opens a browser for authentication. After signing in, you can close the browser.
|
||||
```
|
||||
|
||||
## Step 4: Verify Configuration
|
||||
|
||||
After authentication, verify:
|
||||
|
||||
1. Read `${CLAUDE_PLUGIN_ROOT}/.mcp.json` to confirm Azure MCP is configured
|
||||
2. Tell the user the current configuration
|
||||
|
||||
## Step 5: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Azure MCP is configured!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
To verify after restart, run /mcp and check that 'azure' server is connected.
|
||||
|
||||
Reference: https://github.com/microsoft/mcp/tree/main/servers/Azure.Mcp.Server
|
||||
```
|
||||
379
commands/claude-codex-settings/ccproxy-tools-setup.md
Normal file
379
commands/claude-codex-settings/ccproxy-tools-setup.md
Normal file
@@ -0,0 +1,379 @@
|
||||
---
|
||||
description: Configure ccproxy/LiteLLM to use Claude Code with any LLM provider
|
||||
---
|
||||
|
||||
# ccproxy-tools Setup
|
||||
|
||||
Configure Claude Code to use ccproxy/LiteLLM with Claude Pro/Max subscription, GitHub Copilot, or other LLM providers.
|
||||
|
||||
## Step 1: Check Prerequisites
|
||||
|
||||
Check if `uv` is installed:
|
||||
|
||||
```bash
|
||||
which uv
|
||||
```
|
||||
|
||||
If not installed, install it:
|
||||
|
||||
```bash
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
```
|
||||
|
||||
Then reload shell or run `source ~/.bashrc` (or `~/.zshrc`).
|
||||
|
||||
## Step 2: Ask Provider Choice
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Which LLM provider do you want to use with Claude Code?"
|
||||
- header: "Provider"
|
||||
- options:
|
||||
- label: "Claude Pro/Max (ccproxy)"
|
||||
description: "Use your Claude subscription via OAuth - no API keys needed"
|
||||
- label: "GitHub Copilot (LiteLLM)"
|
||||
description: "Use GitHub Copilot subscription via LiteLLM proxy"
|
||||
- label: "OpenAI API (LiteLLM)"
|
||||
description: "Use OpenAI models via LiteLLM proxy"
|
||||
- label: "Gemini API (LiteLLM)"
|
||||
description: "Use Google Gemini models via LiteLLM proxy"
|
||||
|
||||
## Step 3: Install Proxy Tool
|
||||
|
||||
### If Claude Pro/Max (ccproxy)
|
||||
|
||||
Install and initialize ccproxy:
|
||||
|
||||
```bash
|
||||
uv tool install ccproxy
|
||||
ccproxy init
|
||||
```
|
||||
|
||||
### If GitHub Copilot, OpenAI, or Gemini (LiteLLM)
|
||||
|
||||
Install LiteLLM:
|
||||
|
||||
```bash
|
||||
uv tool install 'litellm[proxy]'
|
||||
```
|
||||
|
||||
## Step 4: Configure LiteLLM (if applicable)
|
||||
|
||||
### For GitHub Copilot
|
||||
|
||||
Auto-detect VS Code and Copilot versions:
|
||||
|
||||
```bash
|
||||
# Get VS Code version
|
||||
VSCODE_VERSION=$(code --version 2> /dev/null | head -1 || echo "1.96.0")
|
||||
|
||||
# Find Copilot Chat extension version
|
||||
COPILOT_VERSION=$(ls ~/.vscode/extensions/ 2> /dev/null | grep "github.copilot-chat-" | sed 's/github.copilot-chat-//' | sort -V | tail -1 || echo "0.26.7")
|
||||
```
|
||||
|
||||
Create `~/.litellm/config.yaml` with detected versions:
|
||||
|
||||
```yaml
|
||||
general_settings:
|
||||
master_key: sk-dummy
|
||||
litellm_settings:
|
||||
drop_params: true
|
||||
model_list:
|
||||
- model_name: "*"
|
||||
litellm_params:
|
||||
model: "github_copilot/*"
|
||||
extra_headers:
|
||||
editor-version: "vscode/${VSCODE_VERSION}"
|
||||
editor-plugin-version: "copilot-chat/${COPILOT_VERSION}"
|
||||
Copilot-Integration-Id: "vscode-chat"
|
||||
user-agent: "GitHubCopilotChat/${COPILOT_VERSION}"
|
||||
```
|
||||
|
||||
### For OpenAI API
|
||||
|
||||
Ask for OpenAI API key using AskUserQuestion:
|
||||
|
||||
- question: "Enter your OpenAI API key (starts with sk-):"
|
||||
- header: "OpenAI Key"
|
||||
- options:
|
||||
- label: "I have it ready"
|
||||
description: "I'll paste my OpenAI API key"
|
||||
- label: "Skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
Create `~/.litellm/config.yaml`:
|
||||
|
||||
```yaml
|
||||
general_settings:
|
||||
master_key: sk-dummy
|
||||
litellm_settings:
|
||||
drop_params: true
|
||||
model_list:
|
||||
- model_name: "*"
|
||||
litellm_params:
|
||||
model: openai/gpt-4o
|
||||
api_key: ${OPENAI_API_KEY}
|
||||
```
|
||||
|
||||
### For Gemini API
|
||||
|
||||
Ask for Gemini API key using AskUserQuestion:
|
||||
|
||||
- question: "Enter your Gemini API key:"
|
||||
- header: "Gemini Key"
|
||||
- options:
|
||||
- label: "I have it ready"
|
||||
description: "I'll paste my Gemini API key"
|
||||
- label: "Skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
Create `~/.litellm/config.yaml`:
|
||||
|
||||
```yaml
|
||||
general_settings:
|
||||
master_key: sk-dummy
|
||||
litellm_settings:
|
||||
drop_params: true
|
||||
model_list:
|
||||
- model_name: "*"
|
||||
litellm_params:
|
||||
model: gemini/gemini-2.5-flash
|
||||
api_key: ${GEMINI_API_KEY}
|
||||
```
|
||||
|
||||
## Step 5: Setup Auto-Start Service
|
||||
|
||||
Detect platform and create appropriate service:
|
||||
|
||||
### macOS (launchd)
|
||||
|
||||
For ccproxy, create `~/Library/LaunchAgents/com.ccproxy.plist`:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
<dict>
|
||||
<key>Label</key>
|
||||
<string>com.ccproxy</string>
|
||||
<key>ProgramArguments</key>
|
||||
<array>
|
||||
<string>${HOME}/.local/bin/ccproxy</string>
|
||||
<string>start</string>
|
||||
</array>
|
||||
<key>RunAtLoad</key>
|
||||
<true/>
|
||||
<key>KeepAlive</key>
|
||||
<true/>
|
||||
<key>StandardOutPath</key>
|
||||
<string>${HOME}/.local/share/ccproxy/stdout.log</string>
|
||||
<key>StandardErrorPath</key>
|
||||
<string>${HOME}/.local/share/ccproxy/stderr.log</string>
|
||||
</dict>
|
||||
</plist>
|
||||
```
|
||||
|
||||
For LiteLLM, create `~/Library/LaunchAgents/com.litellm.plist`:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
<dict>
|
||||
<key>Label</key>
|
||||
<string>com.litellm</string>
|
||||
<key>ProgramArguments</key>
|
||||
<array>
|
||||
<string>${HOME}/.local/bin/litellm</string>
|
||||
<string>--config</string>
|
||||
<string>${HOME}/.litellm/config.yaml</string>
|
||||
</array>
|
||||
<key>RunAtLoad</key>
|
||||
<true/>
|
||||
<key>KeepAlive</key>
|
||||
<true/>
|
||||
<key>StandardOutPath</key>
|
||||
<string>${HOME}/.local/share/litellm/stdout.log</string>
|
||||
<key>StandardErrorPath</key>
|
||||
<string>${HOME}/.local/share/litellm/stderr.log</string>
|
||||
</dict>
|
||||
</plist>
|
||||
```
|
||||
|
||||
Load and start the service:
|
||||
|
||||
```bash
|
||||
launchctl load ~/Library/LaunchAgents/com.ccproxy.plist # or com.litellm.plist
|
||||
```
|
||||
|
||||
### Linux (systemd user service)
|
||||
|
||||
For ccproxy, create `~/.config/systemd/user/ccproxy.service`:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=ccproxy LLM Proxy
|
||||
|
||||
[Service]
|
||||
ExecStart=%h/.local/bin/ccproxy start
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
|
||||
[Install]
|
||||
WantedBy=default.target
|
||||
```
|
||||
|
||||
For LiteLLM, create `~/.config/systemd/user/litellm.service`:
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=LiteLLM Proxy
|
||||
|
||||
[Service]
|
||||
ExecStart=%h/.local/bin/litellm --config %h/.litellm/config.yaml
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
|
||||
[Install]
|
||||
WantedBy=default.target
|
||||
```
|
||||
|
||||
Enable and start the service:
|
||||
|
||||
```bash
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user enable --now ccproxy # or litellm
|
||||
```
|
||||
|
||||
## Step 6: Authenticate (ccproxy only)
|
||||
|
||||
For ccproxy, tell the user:
|
||||
|
||||
```
|
||||
The proxy is starting. A browser window will open for authentication.
|
||||
|
||||
1. Sign in with your Claude Pro/Max account
|
||||
2. Authorize the connection
|
||||
3. Return here after successful authentication
|
||||
```
|
||||
|
||||
Wait for authentication to complete.
|
||||
|
||||
## Step 7: Verify Proxy is Running
|
||||
|
||||
Check if proxy is healthy:
|
||||
|
||||
```bash
|
||||
curl -s http://localhost:4000/health
|
||||
```
|
||||
|
||||
Retry up to 5 times with 3-second delays if not responding.
|
||||
|
||||
If proxy is not healthy after retries:
|
||||
|
||||
- Show error and troubleshooting steps
|
||||
- Do NOT proceed to update settings
|
||||
- Exit
|
||||
|
||||
## Step 8: Confirm Before Updating Settings
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Proxy is running. Ready to configure Claude Code to use it?"
|
||||
- header: "Configure"
|
||||
- options:
|
||||
- label: "Yes, configure now"
|
||||
description: "Update settings to use the proxy (requires restart)"
|
||||
- label: "No, not yet"
|
||||
description: "Keep current settings, I'll configure later"
|
||||
|
||||
If user selects "No, not yet":
|
||||
|
||||
- Tell them they can run `/ccproxy-tools:setup` again when ready
|
||||
- Exit without changing settings
|
||||
|
||||
## Step 9: Update Settings
|
||||
|
||||
1. Read current `~/.claude/settings.json`
|
||||
2. Create backup at `~/.claude/settings.json.backup`
|
||||
3. Add to env section based on provider:
|
||||
|
||||
For ccproxy:
|
||||
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"ANTHROPIC_BASE_URL": "http://localhost:4000"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For LiteLLM:
|
||||
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"ANTHROPIC_BASE_URL": "http://localhost:4000",
|
||||
"ANTHROPIC_AUTH_TOKEN": "sk-dummy"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
4. Write updated settings
|
||||
|
||||
## Step 10: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Configuration complete!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
The proxy will start automatically on system boot.
|
||||
|
||||
To verify after restart:
|
||||
- Claude Code should connect to the proxy at localhost:4000
|
||||
- Check proxy logs: ~/Library/LaunchAgents/*.log (macOS) or journalctl --user -u ccproxy (Linux)
|
||||
```
|
||||
|
||||
## Recovery Instructions
|
||||
|
||||
Always show these recovery instructions:
|
||||
|
||||
```
|
||||
If Claude Code stops working after setup:
|
||||
|
||||
1. Check proxy status:
|
||||
curl http://localhost:4000/health
|
||||
|
||||
2. Restart proxy:
|
||||
macOS: launchctl kickstart -k gui/$(id -u)/com.ccproxy
|
||||
Linux: systemctl --user restart ccproxy
|
||||
|
||||
3. Check proxy logs:
|
||||
macOS: cat ~/.local/share/ccproxy/stderr.log
|
||||
Linux: journalctl --user -u ccproxy
|
||||
|
||||
4. Restore original settings (removes proxy):
|
||||
cp ~/.claude/settings.json.backup ~/.claude/settings.json
|
||||
|
||||
Or manually edit ~/.claude/settings.json and remove:
|
||||
- ANTHROPIC_BASE_URL
|
||||
- ANTHROPIC_AUTH_TOKEN (if present)
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If proxy setup fails:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. Port in use - Check if another process uses port 4000: lsof -i :4000
|
||||
2. Service not starting - Check logs in ~/.local/share/ccproxy/ or ~/.local/share/litellm/
|
||||
3. Authentication failed - Re-run setup to re-authenticate
|
||||
4. Permission denied - Ensure ~/.local/bin is in PATH
|
||||
5. Config invalid - Verify ~/.litellm/config.yaml syntax
|
||||
```
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
allowed-tools: Read
|
||||
description: Refresh context with CLAUDE.md instructions
|
||||
---
|
||||
|
||||
# Load CLAUDE.md
|
||||
|
||||
Read and inject CLAUDE.md content into the current context. Useful for refreshing instructions in long conversations.
|
||||
|
||||
1. Read `~/.claude/CLAUDE.md` (global instructions)
|
||||
2. Read `CLAUDE.md` or `AGENTS.md` from the current project directory (whichever exists)
|
||||
3. Acknowledge that context has been refreshed with these instructions
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
description: Load frontend design skill from Anthropic
|
||||
allowed-tools: WebFetch
|
||||
---
|
||||
|
||||
# Load Frontend Design Skill
|
||||
|
||||
Load the frontend-design skill from Anthropic's official Claude Code plugins to guide creation of distinctive, production-grade frontend interfaces.
|
||||
|
||||
Fetch from:
|
||||
https://raw.githubusercontent.com/anthropics/claude-code/main/plugins/frontend-design/skills/frontend-design/SKILL.md
|
||||
|
||||
Use this guidance when building web components, pages, or applications that require high design quality and avoid generic AI aesthetics.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
allowed-tools: Read, Bash
|
||||
description: Sync allowlist from GitHub repository to user settings
|
||||
---
|
||||
|
||||
# Sync Allowlist
|
||||
|
||||
Fetch the latest permissions allowlist from fcakyon/claude-codex-settings GitHub repository and update ~/.claude/settings.json.
|
||||
|
||||
Steps:
|
||||
|
||||
1. Use `gh api repos/fcakyon/claude-settings/contents/.claude/settings.json --jq '.content' | base64 -d` to fetch settings
|
||||
2. Parse the JSON and extract the `permissions.allow` array
|
||||
3. Read the user's `~/.claude/settings.json`
|
||||
4. Update only the `permissions.allow` field (preserve all other user settings)
|
||||
5. Write back to `~/.claude/settings.json`
|
||||
6. Confirm with a message showing count of allowlist entries synced
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
allowed-tools: Read, Bash
|
||||
description: Sync CLAUDE.md from GitHub repository
|
||||
---
|
||||
|
||||
# Sync CLAUDE.md
|
||||
|
||||
Fetch the latest CLAUDE.md from fcakyon/claude-codex-settings GitHub repository and update ~/.claude/CLAUDE.md.
|
||||
|
||||
Use `gh api repos/fcakyon/claude-codex-settings/contents/CLAUDE.md --jq '.content' | base64 -d` to fetch the file content, then write to ~/.claude/CLAUDE.md. Confirm successful update with a message showing the file has been synced.
|
||||
104
commands/claude-codex-settings/gcloud-tools-setup.md
Normal file
104
commands/claude-codex-settings/gcloud-tools-setup.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
description: Configure GCloud CLI authentication
|
||||
---
|
||||
|
||||
# GCloud Tools Setup
|
||||
|
||||
**Source:** [googleapis/gcloud-mcp](https://github.com/googleapis/gcloud-mcp)
|
||||
|
||||
Check GCloud MCP status and configure CLI authentication if needed.
|
||||
|
||||
## Step 1: Check gcloud CLI
|
||||
|
||||
Run: `gcloud --version`
|
||||
|
||||
If not installed: Continue to Step 2.
|
||||
If installed: Skip to Step 3.
|
||||
|
||||
## Step 2: Install gcloud CLI
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Install Google Cloud SDK:
|
||||
|
||||
macOS (Homebrew):
|
||||
brew install google-cloud-sdk
|
||||
|
||||
macOS/Linux (Manual):
|
||||
curl https://sdk.cloud.google.com | bash
|
||||
exec -l $SHELL
|
||||
|
||||
Windows:
|
||||
Download from: https://cloud.google.com/sdk/docs/install
|
||||
|
||||
After install, restart your terminal.
|
||||
```
|
||||
|
||||
## Step 3: Authenticate
|
||||
|
||||
Run these commands:
|
||||
|
||||
```bash
|
||||
# Login with your Google account
|
||||
gcloud auth login
|
||||
|
||||
# Set up Application Default Credentials (required for MCP)
|
||||
gcloud auth application-default login
|
||||
```
|
||||
|
||||
Both commands will open a browser for authentication.
|
||||
|
||||
## Step 4: Set Default Project
|
||||
|
||||
```bash
|
||||
# List available projects
|
||||
gcloud projects list
|
||||
|
||||
# Set default project
|
||||
gcloud config set project YOUR_PROJECT_ID
|
||||
```
|
||||
|
||||
## Step 5: Verify Setup
|
||||
|
||||
Run: `gcloud auth list`
|
||||
|
||||
Should show your authenticated account with asterisk (\*).
|
||||
|
||||
## Step 6: Restart Claude Code
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
After authentication:
|
||||
1. Exit Claude Code
|
||||
2. Run `claude` again
|
||||
|
||||
The MCP will use your gcloud credentials.
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If GCloud MCP fails:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. ADC not found - Run gcloud auth application-default login
|
||||
2. Project not set - Run gcloud config set project PROJECT_ID
|
||||
3. Permission denied - Check IAM roles in Cloud Console
|
||||
4. Quota exceeded - Check quotas in Cloud Console
|
||||
5. Token expired - Run gcloud auth application-default login again
|
||||
```
|
||||
|
||||
## Alternative: Disable Plugin
|
||||
|
||||
If user doesn't need GCloud integration:
|
||||
|
||||
```
|
||||
To disable this plugin:
|
||||
1. Run /mcp command
|
||||
2. Find the gcloud-observability server
|
||||
3. Disable it
|
||||
|
||||
This prevents errors from missing authentication.
|
||||
```
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
description: Clean up local branches deleted from remote
|
||||
---
|
||||
|
||||
# Clean Gone Branches
|
||||
|
||||
Remove local git branches that have been deleted from remote (marked as [gone]).
|
||||
|
||||
## Instructions
|
||||
|
||||
Run the following commands in sequence:
|
||||
|
||||
1. **Update remote references:**
|
||||
```bash
|
||||
git fetch --prune
|
||||
```
|
||||
|
||||
2. **View branches marked as [gone]:**
|
||||
```bash
|
||||
git branch -vv
|
||||
```
|
||||
|
||||
3. **List worktrees (if any):**
|
||||
```bash
|
||||
git worktree list
|
||||
```
|
||||
|
||||
4. **Remove worktrees for gone branches (if any):**
|
||||
```bash
|
||||
git branch -vv | grep '\[gone\]' | awk '{print $1}' | sed 's/^[*+]*//' | while read -r branch; do
|
||||
worktree=$(git worktree list | grep "\[$branch\]" | awk '{print $1}')
|
||||
if [ -n "$worktree" ]; then
|
||||
echo "Removing worktree: $worktree"
|
||||
git worktree remove --force "$worktree"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
5. **Delete gone branches:**
|
||||
```bash
|
||||
git branch -vv | grep '\[gone\]' | awk '{print $1}' | sed 's/^[*+]*//' | xargs -I {} git branch -D {}
|
||||
```
|
||||
|
||||
Report the results: list of removed worktrees and deleted branches, or notify if no [gone] branches exist.
|
||||
19
commands/claude-codex-settings/github-dev-commit-staged.md
Normal file
19
commands/claude-codex-settings/github-dev-commit-staged.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
allowed-tools: Task, Read, Grep, SlashCommand
|
||||
argument-hint: [context]
|
||||
description: Commit staged changes with optional context
|
||||
---
|
||||
|
||||
# Commit Staged Changes
|
||||
|
||||
Use the commit-creator agent to analyze and commit staged changes with intelligent organization and optimal commit strategy.
|
||||
|
||||
## Additional Context
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
Task(
|
||||
description: "Analyze and commit staged changes",
|
||||
prompt: "Analyze the staged changes and create appropriate commits. Additional context: $ARGUMENTS",
|
||||
subagent_type: "github-dev:commit-creator"
|
||||
)
|
||||
19
commands/claude-codex-settings/github-dev-create-pr.md
Normal file
19
commands/claude-codex-settings/github-dev-create-pr.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
allowed-tools: Task, Read, Grep, SlashCommand, Bash(git checkout:*), Bash(git -C:* checkout:*)
|
||||
argument-hint: [context]
|
||||
description: Create pull request with optional context
|
||||
---
|
||||
|
||||
# Create Pull Request
|
||||
|
||||
Use the pr-creator agent to handle the complete PR workflow including branch creation, commits, and PR submission.
|
||||
|
||||
## Additional Context
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
Task(
|
||||
description: "Create pull request",
|
||||
prompt: "Handle the complete PR workflow including branch creation, commits, and PR submission. Additional context: $ARGUMENTS",
|
||||
subagent_type: "github-dev:pr-creator"
|
||||
)
|
||||
19
commands/claude-codex-settings/github-dev-review-pr.md
Normal file
19
commands/claude-codex-settings/github-dev-review-pr.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
allowed-tools: Task, Read, Grep, Glob
|
||||
argument-hint: <PR number or URL>
|
||||
description: Review a pull request for code quality and issues
|
||||
---
|
||||
|
||||
# Review Pull Request
|
||||
|
||||
Use the pr-reviewer agent to analyze the pull request and provide a detailed code review.
|
||||
|
||||
## PR Reference
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
Task(
|
||||
description: "Review pull request",
|
||||
prompt: "Review the pull request and provide detailed feedback on code quality, potential bugs, and suggestions. PR reference: $ARGUMENTS",
|
||||
subagent_type: "github-dev:pr-reviewer"
|
||||
)
|
||||
53
commands/claude-codex-settings/github-dev-setup.md
Normal file
53
commands/claude-codex-settings/github-dev-setup.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
description: Configure GitHub CLI authentication
|
||||
---
|
||||
|
||||
# GitHub CLI Setup
|
||||
|
||||
**Source:** [github/github-mcp-server](https://github.com/github/github-mcp-server)
|
||||
|
||||
Configure `gh` CLI for GitHub access.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Run `gh auth status` to check authentication state.
|
||||
|
||||
Report status:
|
||||
|
||||
- "GitHub CLI is not authenticated - needs login"
|
||||
- OR "GitHub CLI is authenticated as <username>"
|
||||
|
||||
## Step 2: If Not Authenticated
|
||||
|
||||
Guide the user:
|
||||
|
||||
```
|
||||
To authenticate with GitHub CLI:
|
||||
|
||||
gh auth login
|
||||
|
||||
This will open a browser for GitHub OAuth login.
|
||||
Select: GitHub.com → HTTPS → Login with browser
|
||||
```
|
||||
|
||||
## Step 3: Verify Setup
|
||||
|
||||
After login, verify with:
|
||||
|
||||
```bash
|
||||
gh auth status
|
||||
gh api user --jq '.login'
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If `gh` commands fail:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. Check authentication - gh auth status
|
||||
2. Re-login - gh auth login
|
||||
3. Missing scopes - re-auth with required permissions
|
||||
4. Update gh CLI - brew upgrade gh (or equivalent)
|
||||
5. Token expired - gh auth refresh
|
||||
```
|
||||
118
commands/claude-codex-settings/github-dev-update-pr-summary.md
Normal file
118
commands/claude-codex-settings/github-dev-update-pr-summary.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# Claude Command: Update PR Summary
|
||||
|
||||
Update PR description with automatically generated summary based on complete changeset.
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
/update-pr-summary <pr_number> # Update PR description
|
||||
/update-pr-summary 131 # Example: update PR #131
|
||||
```
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
1. **Fetch PR Information**:
|
||||
- Get PR details using `gh pr view <pr_number> --json title,body,baseRefName,headRefName`
|
||||
- Identify base branch and head branch from PR metadata
|
||||
|
||||
2. **Analyze Complete Changeset**:
|
||||
- **IMPORTANT**: Analyze ALL committed changes in the branch using `git diff <base-branch>...HEAD`
|
||||
- PR description must describe the complete changeset across all commits, not just the latest commit
|
||||
- Focus on what changed from the perspective of someone reviewing the entire branch
|
||||
- Ignore unstaged changes
|
||||
|
||||
3. **Generate PR Description**:
|
||||
- Create brief summary (1 sentence or few words)
|
||||
- Add few bullet points of key changes
|
||||
- For significant changes, include before/after code examples in PR body
|
||||
- Include inline markdown links to relevant code lines when helpful (format: `[src/auth.py:42](src/auth.py#L42)`)
|
||||
- For config/API changes, use `mcp__tavily__tavily_search` to verify information and include source links inline
|
||||
- Never include test plans in PR descriptions
|
||||
|
||||
4. **Update PR Title** (if needed):
|
||||
- Title should start with capital letter and verb
|
||||
- Should NOT start with conventional commit prefixes (e.g. "fix:", "feat:")
|
||||
|
||||
5. **Update PR**:
|
||||
- Use `gh pr edit <pr_number>` with `--body` (and optionally `--title`) to update the PR
|
||||
- Use HEREDOC for proper formatting:
|
||||
```bash
|
||||
gh pr edit "$(
|
||||
cat << 'EOF'
|
||||
[PR description here]
|
||||
EOF
|
||||
)" < pr_number > --body
|
||||
```
|
||||
|
||||
## PR Description Format
|
||||
|
||||
```markdown
|
||||
[Brief summary in 1 sentence or few words]
|
||||
|
||||
- [Key change 1 with inline code reference if helpful]
|
||||
- [Key change 2 with source link if config/API change]
|
||||
- [Key change 3]
|
||||
|
||||
[Optional: Before/after code examples for significant changes]
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Config/API Change with Source Links
|
||||
|
||||
```markdown
|
||||
Update Claude Haiku to version 4.5
|
||||
|
||||
- Model ID: claude-3-haiku-20240307 → claude-haiku-4-5-20251001 ([source](https://docs.anthropic.com/en/docs/about-claude/models/overview))
|
||||
- Pricing: $0.80/$4.00 → $1.00/$5.00 per MTok ([source](https://docs.anthropic.com/en/docs/about-claude/pricing))
|
||||
- Max output: 4,096 → 64,000 tokens ([source](https://docs.anthropic.com/en/docs/about-claude/models/overview))
|
||||
```
|
||||
|
||||
### Example 2: Code Changes with File Links
|
||||
|
||||
````markdown
|
||||
Refactor authentication to use async context manager
|
||||
|
||||
- Replace synchronous auth flow with async/await pattern in [src/auth.py:15-42](src/auth.py#L15-L42)
|
||||
- Add context manager support for automatic cleanup
|
||||
|
||||
Before:
|
||||
|
||||
```python
|
||||
def authenticate(token):
|
||||
session = create_session(token)
|
||||
return session
|
||||
```
|
||||
|
||||
After:
|
||||
|
||||
```python
|
||||
async def authenticate(token):
|
||||
async with create_session(token) as session:
|
||||
return session
|
||||
```
|
||||
````
|
||||
|
||||
### Example 3: Simple Feature Addition
|
||||
|
||||
```markdown
|
||||
Add user profile export functionality
|
||||
|
||||
- Export user data to JSON format in [src/export.py:45-78](src/export.py#L45-L78)
|
||||
- Add CLI command `/export-profile` in [src/cli.py:123](src/cli.py#L123)
|
||||
- Include email, preferences, and activity history in export
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
**Pre-Analysis Verification**:
|
||||
|
||||
- Verify PR exists and is accessible
|
||||
- Check tool availability (`gh auth status`)
|
||||
- Confirm authentication status
|
||||
|
||||
**Common Issues**:
|
||||
|
||||
- Invalid PR number → List available PRs
|
||||
- Missing tools → Provide setup instructions
|
||||
- Auth issues → Guide through authentication
|
||||
74
commands/claude-codex-settings/linear-tools-setup.md
Normal file
74
commands/claude-codex-settings/linear-tools-setup.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
description: Configure Linear OAuth authentication
|
||||
---
|
||||
|
||||
# Linear Tools Setup
|
||||
|
||||
**Source:** [Linear MCP Docs](https://linear.app/docs/mcp)
|
||||
|
||||
Check Linear MCP status and configure OAuth if needed.
|
||||
|
||||
## Step 1: Test Current Setup
|
||||
|
||||
Try listing teams using `mcp__linear__list_teams`.
|
||||
|
||||
If successful: Tell user Linear is configured and working.
|
||||
|
||||
If fails with authentication error: Continue to Step 2.
|
||||
|
||||
## Step 2: OAuth Authentication
|
||||
|
||||
Linear uses OAuth - no API keys needed. Tell the user:
|
||||
|
||||
```
|
||||
Linear MCP uses OAuth authentication.
|
||||
|
||||
To authenticate:
|
||||
1. Run the /mcp command in Claude Code
|
||||
2. Find the "linear" server in the list
|
||||
3. Click "Authenticate" or similar option
|
||||
4. A browser window will open
|
||||
5. Sign in to Linear and authorize access
|
||||
```
|
||||
|
||||
## Step 3: Complete OAuth Flow
|
||||
|
||||
After user clicks authenticate:
|
||||
|
||||
- Browser opens to Linear authorization page
|
||||
- User signs in with their Linear account
|
||||
- User approves the permission request
|
||||
- Browser shows success message
|
||||
- Claude Code receives the token automatically
|
||||
|
||||
## Step 4: Verify Setup
|
||||
|
||||
Try listing teams again using `mcp__linear__list_teams`.
|
||||
|
||||
If successful: Linear is now configured.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If OAuth fails:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. Clear browser cookies for linear.app
|
||||
2. Try a different browser
|
||||
3. Disable browser extensions
|
||||
4. Re-run /mcp and authenticate again
|
||||
5. Restart Claude Code and try again
|
||||
```
|
||||
|
||||
## Alternative: Disable Plugin
|
||||
|
||||
If user doesn't need Linear integration:
|
||||
|
||||
```
|
||||
To disable this plugin:
|
||||
1. Run /mcp command
|
||||
2. Find the linear server
|
||||
3. Disable it
|
||||
|
||||
This prevents errors from missing authentication.
|
||||
```
|
||||
112
commands/claude-codex-settings/mongodb-tools-setup.md
Normal file
112
commands/claude-codex-settings/mongodb-tools-setup.md
Normal file
@@ -0,0 +1,112 @@
|
||||
---
|
||||
description: Configure MongoDB MCP connection
|
||||
---
|
||||
|
||||
# MongoDB Tools Setup
|
||||
|
||||
**Source:** [mongodb-js/mongodb-mcp-server](https://github.com/mongodb-js/mongodb-mcp-server)
|
||||
|
||||
Configure the MongoDB MCP server with your connection string.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Read the MCP configuration from `${CLAUDE_PLUGIN_ROOT}/.mcp.json`.
|
||||
|
||||
Check if MongoDB is configured:
|
||||
|
||||
- If `mongodb.env.MDB_MCP_CONNECTION_STRING` contains `REPLACE_WITH_CONNECTION_STRING`, it needs configuration
|
||||
- If it contains a value starting with `mongodb://` or `mongodb+srv://`, already configured
|
||||
|
||||
Report status:
|
||||
|
||||
- "MongoDB MCP is not configured - needs a connection string"
|
||||
- OR "MongoDB MCP is already configured"
|
||||
|
||||
## Step 2: Show Setup Guide
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
To configure MongoDB MCP, you need a connection string.
|
||||
|
||||
Formats:
|
||||
- Atlas: mongodb+srv://username:password@cluster.mongodb.net/database
|
||||
- Local: mongodb://localhost:27017/database
|
||||
|
||||
Get Atlas connection string:
|
||||
1. Go to cloud.mongodb.com
|
||||
2. Navigate to your cluster
|
||||
3. Click "Connect" → "Drivers"
|
||||
4. Copy connection string
|
||||
|
||||
Note: MCP runs in READ-ONLY mode.
|
||||
|
||||
Don't need MongoDB MCP? Disable it via /mcp command.
|
||||
```
|
||||
|
||||
## Step 3: Ask for Connection String
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your MongoDB connection string ready?"
|
||||
- header: "MongoDB"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my MongoDB connection string ready to paste"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/mongodb-tools:setup` again when ready
|
||||
- Remind them they can disable MongoDB MCP via `/mcp` if not needed
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides connection string via "Other":
|
||||
|
||||
- If they provided connection string in "Other" response, use that
|
||||
- Otherwise, ask them to paste the connection string
|
||||
|
||||
## Step 4: Validate Connection String
|
||||
|
||||
Validate the provided connection string:
|
||||
|
||||
- Must start with `mongodb://` or `mongodb+srv://`
|
||||
|
||||
If invalid:
|
||||
|
||||
- Show error: "Invalid connection string format. Must start with 'mongodb://' or 'mongodb+srv://'"
|
||||
- Ask if they want to try again or skip
|
||||
|
||||
## Step 5: Update Configuration
|
||||
|
||||
1. Read current `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
2. Create backup at `${CLAUDE_PLUGIN_ROOT}/.mcp.json.backup`
|
||||
3. Update `mongodb.env.MDB_MCP_CONNECTION_STRING` value to the actual connection string
|
||||
4. Write updated configuration back to `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
|
||||
## Step 6: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
MongoDB MCP configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
To verify after restart, run /mcp and check that 'mongodb' server is connected.
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If MongoDB MCP fails after configuration:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. Authentication failed - Add ?authSource=admin to connection string
|
||||
2. Network timeout - Whitelist IP in Atlas Network Access settings
|
||||
3. Wrong credentials - Verify username/password, special chars need URL encoding
|
||||
4. SSL/TLS errors - For Atlas, ensure mongodb+srv:// is used
|
||||
```
|
||||
62
commands/claude-codex-settings/paper-search-tools-setup.md
Normal file
62
commands/claude-codex-settings/paper-search-tools-setup.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
description: Configure Paper Search MCP (requires Docker)
|
||||
---
|
||||
|
||||
# Paper Search Tools Setup
|
||||
|
||||
**Source:** [mcp/paper-search](https://hub.docker.com/r/mcp/paper-search)
|
||||
|
||||
Configure the Paper Search MCP server. Requires Docker.
|
||||
|
||||
## Step 1: Check Docker Installation
|
||||
|
||||
Run `docker --version` to check if Docker is installed.
|
||||
|
||||
If Docker is not installed, show:
|
||||
|
||||
```
|
||||
Docker is required for Paper Search MCP.
|
||||
|
||||
Install Docker:
|
||||
|
||||
macOS: brew install --cask docker
|
||||
Linux: curl -fsSL https://get.docker.com | sh
|
||||
Windows: winget install Docker.DockerDesktop
|
||||
|
||||
After installation, start Docker Desktop and wait for it to fully launch.
|
||||
```
|
||||
|
||||
## Step 2: Verify Docker is Running
|
||||
|
||||
Run `docker info` to verify Docker daemon is running.
|
||||
|
||||
If not running, tell user:
|
||||
|
||||
```
|
||||
Docker is installed but not running.
|
||||
|
||||
Start Docker Desktop and wait for it to fully launch before continuing.
|
||||
```
|
||||
|
||||
## Step 3: Pull the Image
|
||||
|
||||
Run `docker pull mcp/paper-search` to download the MCP image.
|
||||
|
||||
Report progress:
|
||||
|
||||
- "Pulling paper-search image..."
|
||||
- "Image ready!"
|
||||
|
||||
## Step 4: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Paper Search MCP configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
To verify after restart, run /mcp and check that 'paper-search' server is connected.
|
||||
```
|
||||
104
commands/claude-codex-settings/playwright-tools-setup.md
Normal file
104
commands/claude-codex-settings/playwright-tools-setup.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
description: Configure Playwright MCP
|
||||
---
|
||||
|
||||
# Playwright Tools Setup
|
||||
|
||||
**Source:** [microsoft/playwright-mcp](https://github.com/microsoft/playwright-mcp)
|
||||
|
||||
Check Playwright MCP status and configure browser dependencies if needed.
|
||||
|
||||
## Step 1: Test Current Setup
|
||||
|
||||
Run `/mcp` command to check if playwright server is listed and connected.
|
||||
|
||||
If playwright server shows as connected: Tell user Playwright is configured and working.
|
||||
|
||||
If playwright server is missing or shows connection error: Continue to Step 2.
|
||||
|
||||
## Step 2: Browser Installation
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Playwright MCP requires browser binaries. Install them with:
|
||||
|
||||
npx playwright install
|
||||
|
||||
This installs Chromium, Firefox, and WebKit browsers.
|
||||
|
||||
For a specific browser only:
|
||||
npx playwright install chromium
|
||||
npx playwright install firefox
|
||||
npx playwright install webkit
|
||||
```
|
||||
|
||||
## Step 3: Browser Options
|
||||
|
||||
The MCP server supports these browsers via the `--browser` flag in `.mcp.json`:
|
||||
|
||||
- `chrome` (default)
|
||||
- `firefox`
|
||||
- `webkit`
|
||||
- `msedge`
|
||||
|
||||
Example `.mcp.json` for Firefox:
|
||||
|
||||
```json
|
||||
{
|
||||
"playwright": {
|
||||
"command": "npx",
|
||||
"args": ["@playwright/mcp@latest", "--browser", "firefox"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Step 4: Headless Mode
|
||||
|
||||
For headless operation (no visible browser), add `--headless`:
|
||||
|
||||
```json
|
||||
{
|
||||
"playwright": {
|
||||
"command": "npx",
|
||||
"args": ["@playwright/mcp@latest", "--headless"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Step 5: Restart
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
After making changes:
|
||||
1. Exit Claude Code
|
||||
2. Run `claude` again
|
||||
|
||||
Changes take effect after restart.
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If Playwright MCP fails:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. Browser not found - Run `npx playwright install`
|
||||
2. Permission denied - Check file permissions on browser binaries
|
||||
3. Display issues - Use `--headless` flag for headless mode
|
||||
4. Timeout errors - Increase timeout with `--timeout-navigation 120000`
|
||||
```
|
||||
|
||||
## Alternative: Disable Plugin
|
||||
|
||||
If user doesn't need browser automation:
|
||||
|
||||
```
|
||||
To disable this plugin:
|
||||
1. Run /mcp command
|
||||
2. Find the playwright server
|
||||
3. Disable it
|
||||
|
||||
This prevents errors from missing browser binaries.
|
||||
```
|
||||
415
commands/claude-codex-settings/plugin-dev-create-plugin.md
Normal file
415
commands/claude-codex-settings/plugin-dev-create-plugin.md
Normal file
@@ -0,0 +1,415 @@
|
||||
---
|
||||
description: Guided end-to-end plugin creation workflow with component design, implementation, and validation
|
||||
argument-hint: Optional plugin description
|
||||
allowed-tools: ["Read", "Write", "Grep", "Glob", "Bash", "TodoWrite", "AskUserQuestion", "Skill", "Task"]
|
||||
---
|
||||
|
||||
# Plugin Creation Workflow
|
||||
|
||||
Guide the user through creating a complete, high-quality Claude Code plugin from initial concept to tested implementation. Follow a systematic approach: understand requirements, design components, clarify details, implement following best practices, validate, and test.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Ask clarifying questions**: Identify all ambiguities about plugin purpose, triggering, scope, and components. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with implementation.
|
||||
- **Load relevant skills**: Use the Skill tool to load plugin-dev skills when needed (plugin-structure, hook-development, agent-development, etc.)
|
||||
- **Use specialized agents**: Leverage agent-creator, plugin-validator, and skill-reviewer agents for AI-assisted development
|
||||
- **Follow best practices**: Apply patterns from plugin-dev's own implementation
|
||||
- **Progressive disclosure**: Create lean skills with references/examples
|
||||
- **Use TodoWrite**: Track all progress throughout all phases
|
||||
|
||||
**Initial request:** $ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Discovery
|
||||
|
||||
**Goal**: Understand what plugin needs to be built and what problem it solves
|
||||
|
||||
**Actions**:
|
||||
1. Create todo list with all 7 phases
|
||||
2. If plugin purpose is clear from arguments:
|
||||
- Summarize understanding
|
||||
- Identify plugin type (integration, workflow, analysis, toolkit, etc.)
|
||||
3. If plugin purpose is unclear, ask user:
|
||||
- What problem does this plugin solve?
|
||||
- Who will use it and when?
|
||||
- What should it do?
|
||||
- Any similar plugins to reference?
|
||||
4. Summarize understanding and confirm with user before proceeding
|
||||
|
||||
**Output**: Clear statement of plugin purpose and target users
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Component Planning
|
||||
|
||||
**Goal**: Determine what plugin components are needed
|
||||
|
||||
**MUST load plugin-structure skill** using Skill tool before this phase.
|
||||
|
||||
**Actions**:
|
||||
1. Load plugin-structure skill to understand component types
|
||||
2. Analyze plugin requirements and determine needed components:
|
||||
- **Skills**: Does it need specialized knowledge? (hooks API, MCP patterns, etc.)
|
||||
- **Commands**: User-initiated actions? (deploy, configure, analyze)
|
||||
- **Agents**: Autonomous tasks? (validation, generation, analysis)
|
||||
- **Hooks**: Event-driven automation? (validation, notifications)
|
||||
- **MCP**: External service integration? (databases, APIs)
|
||||
- **Settings**: User configuration? (.local.md files)
|
||||
3. For each component type needed, identify:
|
||||
- How many of each type
|
||||
- What each one does
|
||||
- Rough triggering/usage patterns
|
||||
4. Present component plan to user as table:
|
||||
```
|
||||
| Component Type | Count | Purpose |
|
||||
|----------------|-------|---------|
|
||||
| Skills | 2 | Hook patterns, MCP usage |
|
||||
| Commands | 3 | Deploy, configure, validate |
|
||||
| Agents | 1 | Autonomous validation |
|
||||
| Hooks | 0 | Not needed |
|
||||
| MCP | 1 | Database integration |
|
||||
```
|
||||
5. Get user confirmation or adjustments
|
||||
|
||||
**Output**: Confirmed list of components to create
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Detailed Design & Clarifying Questions
|
||||
|
||||
**Goal**: Specify each component in detail and resolve all ambiguities
|
||||
|
||||
**CRITICAL**: This is one of the most important phases. DO NOT SKIP.
|
||||
|
||||
**Actions**:
|
||||
1. For each component in the plan, identify underspecified aspects:
|
||||
- **Skills**: What triggers them? What knowledge do they provide? How detailed?
|
||||
- **Commands**: What arguments? What tools? Interactive or automated?
|
||||
- **Agents**: When to trigger (proactive/reactive)? What tools? Output format?
|
||||
- **Hooks**: Which events? Prompt or command based? Validation criteria?
|
||||
- **MCP**: What server type? Authentication? Which tools?
|
||||
- **Settings**: What fields? Required vs optional? Defaults?
|
||||
|
||||
2. **Present all questions to user in organized sections** (one section per component type)
|
||||
|
||||
3. **Wait for answers before proceeding to implementation**
|
||||
|
||||
4. If user says "whatever you think is best", provide specific recommendations and get explicit confirmation
|
||||
|
||||
**Example questions for a skill**:
|
||||
- What specific user queries should trigger this skill?
|
||||
- Should it include utility scripts? What functionality?
|
||||
- How detailed should the core SKILL.md be vs references/?
|
||||
- Any real-world examples to include?
|
||||
|
||||
**Example questions for an agent**:
|
||||
- Should this agent trigger proactively after certain actions, or only when explicitly requested?
|
||||
- What tools does it need (Read, Write, Bash, etc.)?
|
||||
- What should the output format be?
|
||||
- Any specific quality standards to enforce?
|
||||
|
||||
**Output**: Detailed specification for each component
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Plugin Structure Creation
|
||||
|
||||
**Goal**: Create plugin directory structure and manifest
|
||||
|
||||
**Actions**:
|
||||
1. Determine plugin name (kebab-case, descriptive)
|
||||
2. Choose plugin location:
|
||||
- Ask user: "Where should I create the plugin?"
|
||||
- Offer options: current directory, ../new-plugin-name, custom path
|
||||
3. Create directory structure using bash:
|
||||
```bash
|
||||
mkdir -p plugin-name/.claude-plugin
|
||||
mkdir -p plugin-name/skills # if needed
|
||||
mkdir -p plugin-name/commands # if needed
|
||||
mkdir -p plugin-name/agents # if needed
|
||||
mkdir -p plugin-name/hooks # if needed
|
||||
```
|
||||
4. Create plugin.json manifest using Write tool:
|
||||
```json
|
||||
{
|
||||
"name": "plugin-name",
|
||||
"version": "0.1.0",
|
||||
"description": "[brief description]",
|
||||
"author": {
|
||||
"name": "[author from user or default]",
|
||||
"email": "[email or default]"
|
||||
}
|
||||
}
|
||||
```
|
||||
5. Create README.md template
|
||||
6. Create .gitignore if needed (for .claude/*.local.md, etc.)
|
||||
7. Initialize git repo if creating new directory
|
||||
|
||||
**Output**: Plugin directory structure created and ready for components
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Component Implementation
|
||||
|
||||
**Goal**: Create each component following best practices
|
||||
|
||||
**LOAD RELEVANT SKILLS** before implementing each component type:
|
||||
- Skills: Load skill-development skill
|
||||
- Commands: Load command-development skill
|
||||
- Agents: Load agent-development skill
|
||||
- Hooks: Load hook-development skill
|
||||
- MCP: Load mcp-integration skill
|
||||
- Settings: Load plugin-settings skill
|
||||
|
||||
**Actions for each component**:
|
||||
|
||||
### For Skills:
|
||||
1. Load skill-development skill using Skill tool
|
||||
2. For each skill:
|
||||
- Ask user for concrete usage examples (or use from Phase 3)
|
||||
- Plan resources (scripts/, references/, examples/)
|
||||
- Create skill directory structure
|
||||
- Write SKILL.md with:
|
||||
- Third-person description with specific trigger phrases
|
||||
- Lean body (1,500-2,000 words) in imperative form
|
||||
- References to supporting files
|
||||
- Create reference files for detailed content
|
||||
- Create example files for working code
|
||||
- Create utility scripts if needed
|
||||
3. Use skill-reviewer agent to validate each skill
|
||||
|
||||
### For Commands:
|
||||
1. Load command-development skill using Skill tool
|
||||
2. For each command:
|
||||
- Write command markdown with frontmatter
|
||||
- Include clear description and argument-hint
|
||||
- Specify allowed-tools (minimal necessary)
|
||||
- Write instructions FOR Claude (not TO user)
|
||||
- Provide usage examples and tips
|
||||
- Reference relevant skills if applicable
|
||||
|
||||
### For Agents:
|
||||
1. Load agent-development skill using Skill tool
|
||||
2. For each agent, use agent-creator agent:
|
||||
- Provide description of what agent should do
|
||||
- Agent-creator generates: identifier, whenToUse with examples, systemPrompt
|
||||
- Create agent markdown file with frontmatter and system prompt
|
||||
- Add appropriate model, color, and tools
|
||||
- Validate with validate-agent.sh script
|
||||
|
||||
### For Hooks:
|
||||
1. Load hook-development skill using Skill tool
|
||||
2. For each hook:
|
||||
- Create hooks/hooks.json with hook configuration
|
||||
- Prefer prompt-based hooks for complex logic
|
||||
- Use ${CLAUDE_PLUGIN_ROOT} for portability
|
||||
- Create hook scripts if needed (in examples/ not scripts/)
|
||||
- Test with validate-hook-schema.sh and test-hook.sh utilities
|
||||
|
||||
### For MCP:
|
||||
1. Load mcp-integration skill using Skill tool
|
||||
2. Create .mcp.json configuration with:
|
||||
- Server type (stdio for local, SSE for hosted)
|
||||
- Command and args (with ${CLAUDE_PLUGIN_ROOT})
|
||||
- extensionToLanguage mapping if LSP
|
||||
- Environment variables as needed
|
||||
3. Document required env vars in README
|
||||
4. Provide setup instructions
|
||||
|
||||
### For Settings:
|
||||
1. Load plugin-settings skill using Skill tool
|
||||
2. Create settings template in README
|
||||
3. Create example .claude/plugin-name.local.md file (as documentation)
|
||||
4. Implement settings reading in hooks/commands as needed
|
||||
5. Add to .gitignore: `.claude/*.local.md`
|
||||
|
||||
**Progress tracking**: Update todos as each component is completed
|
||||
|
||||
**Output**: All plugin components implemented
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Validation & Quality Check
|
||||
|
||||
**Goal**: Ensure plugin meets quality standards and works correctly
|
||||
|
||||
**Actions**:
|
||||
1. **Run plugin-validator agent**:
|
||||
- Use plugin-validator agent to comprehensively validate plugin
|
||||
- Check: manifest, structure, naming, components, security
|
||||
- Review validation report
|
||||
|
||||
2. **Fix critical issues**:
|
||||
- Address any critical errors from validation
|
||||
- Fix any warnings that indicate real problems
|
||||
|
||||
3. **Review with skill-reviewer** (if plugin has skills):
|
||||
- For each skill, use skill-reviewer agent
|
||||
- Check description quality, progressive disclosure, writing style
|
||||
- Apply recommendations
|
||||
|
||||
4. **Test agent triggering** (if plugin has agents):
|
||||
- For each agent, verify <example> blocks are clear
|
||||
- Check triggering conditions are specific
|
||||
- Run validate-agent.sh on agent files
|
||||
|
||||
5. **Test hook configuration** (if plugin has hooks):
|
||||
- Run validate-hook-schema.sh on hooks/hooks.json
|
||||
- Test hook scripts with test-hook.sh
|
||||
- Verify ${CLAUDE_PLUGIN_ROOT} usage
|
||||
|
||||
6. **Present findings**:
|
||||
- Summary of validation results
|
||||
- Any remaining issues
|
||||
- Overall quality assessment
|
||||
|
||||
7. **Ask user**: "Validation complete. Issues found: [count critical], [count warnings]. Would you like me to fix them now, or proceed to testing?"
|
||||
|
||||
**Output**: Plugin validated and ready for testing
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Testing & Verification
|
||||
|
||||
**Goal**: Test that plugin works correctly in Claude Code
|
||||
|
||||
**Actions**:
|
||||
1. **Installation instructions**:
|
||||
- Show user how to test locally:
|
||||
```bash
|
||||
cc --plugin-dir /path/to/plugin-name
|
||||
```
|
||||
- Or copy to `.claude-plugin/` for project testing
|
||||
|
||||
2. **Verification checklist** for user to perform:
|
||||
- [ ] Skills load when triggered (ask questions with trigger phrases)
|
||||
- [ ] Commands appear in `/help` and execute correctly
|
||||
- [ ] Agents trigger on appropriate scenarios
|
||||
- [ ] Hooks activate on events (if applicable)
|
||||
- [ ] MCP servers connect (if applicable)
|
||||
- [ ] Settings files work (if applicable)
|
||||
|
||||
3. **Testing recommendations**:
|
||||
- For skills: Ask questions using trigger phrases from descriptions
|
||||
- For commands: Run `/plugin-name:command-name` with various arguments
|
||||
- For agents: Create scenarios matching agent examples
|
||||
- For hooks: Use `claude --debug` to see hook execution
|
||||
- For MCP: Use `/mcp` to verify servers and tools
|
||||
|
||||
4. **Ask user**: "I've prepared the plugin for testing. Would you like me to guide you through testing each component, or do you want to test it yourself?"
|
||||
|
||||
5. **If user wants guidance**, walk through testing each component with specific test cases
|
||||
|
||||
**Output**: Plugin tested and verified working
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Documentation & Next Steps
|
||||
|
||||
**Goal**: Ensure plugin is well-documented and ready for distribution
|
||||
|
||||
**Actions**:
|
||||
1. **Verify README completeness**:
|
||||
- Check README has: overview, features, installation, prerequisites, usage
|
||||
- For MCP plugins: Document required environment variables
|
||||
- For hook plugins: Explain hook activation
|
||||
- For settings: Provide configuration templates
|
||||
|
||||
2. **Add marketplace entry** (if publishing):
|
||||
- Show user how to add to marketplace.json
|
||||
- Help draft marketplace description
|
||||
- Suggest category and tags
|
||||
|
||||
3. **Create summary**:
|
||||
- Mark all todos complete
|
||||
- List what was created:
|
||||
- Plugin name and purpose
|
||||
- Components created (X skills, Y commands, Z agents, etc.)
|
||||
- Key files and their purposes
|
||||
- Total file count and structure
|
||||
- Next steps:
|
||||
- Testing recommendations
|
||||
- Publishing to marketplace (if desired)
|
||||
- Iteration based on usage
|
||||
|
||||
4. **Suggest improvements** (optional):
|
||||
- Additional components that could enhance plugin
|
||||
- Integration opportunities
|
||||
- Testing strategies
|
||||
|
||||
**Output**: Complete, documented plugin ready for use or publication
|
||||
|
||||
---
|
||||
|
||||
## Important Notes
|
||||
|
||||
### Throughout All Phases
|
||||
|
||||
- **Use TodoWrite** to track progress at every phase
|
||||
- **Load skills with Skill tool** when working on specific component types
|
||||
- **Use specialized agents** (agent-creator, plugin-validator, skill-reviewer)
|
||||
- **Ask for user confirmation** at key decision points
|
||||
- **Follow plugin-dev's own patterns** as reference examples
|
||||
- **Apply best practices**:
|
||||
- Third-person descriptions for skills
|
||||
- Imperative form in skill bodies
|
||||
- Commands written FOR Claude
|
||||
- Strong trigger phrases
|
||||
- ${CLAUDE_PLUGIN_ROOT} for portability
|
||||
- Progressive disclosure
|
||||
- Security-first (HTTPS, no hardcoded credentials)
|
||||
|
||||
### Key Decision Points (Wait for User)
|
||||
|
||||
1. After Phase 1: Confirm plugin purpose
|
||||
2. After Phase 2: Approve component plan
|
||||
3. After Phase 3: Proceed to implementation
|
||||
4. After Phase 6: Fix issues or proceed
|
||||
5. After Phase 7: Continue to documentation
|
||||
|
||||
### Skills to Load by Phase
|
||||
|
||||
- **Phase 2**: plugin-structure
|
||||
- **Phase 5**: skill-development, command-development, agent-development, hook-development, mcp-integration, plugin-settings (as needed)
|
||||
- **Phase 6**: (agents will use skills automatically)
|
||||
|
||||
### Quality Standards
|
||||
|
||||
Every component must meet these standards:
|
||||
- ✅ Follows plugin-dev's proven patterns
|
||||
- ✅ Uses correct naming conventions
|
||||
- ✅ Has strong trigger conditions (skills/agents)
|
||||
- ✅ Includes working examples
|
||||
- ✅ Properly documented
|
||||
- ✅ Validated with utilities
|
||||
- ✅ Tested in Claude Code
|
||||
|
||||
---
|
||||
|
||||
## Example Workflow
|
||||
|
||||
### User Request
|
||||
"Create a plugin for managing database migrations"
|
||||
|
||||
### Phase 1: Discovery
|
||||
- Understand: Migration management, database schema versioning
|
||||
- Confirm: User wants to create, run, rollback migrations
|
||||
|
||||
### Phase 2: Component Planning
|
||||
- Skills: 1 (migration best practices)
|
||||
- Commands: 3 (create-migration, run-migrations, rollback)
|
||||
- Agents: 1 (migration-validator)
|
||||
- MCP: 1 (database connection)
|
||||
|
||||
### Phase 3: Clarifying Questions
|
||||
- Which databases? (PostgreSQL, MySQL, etc.)
|
||||
- Migration file format? (SQL, code-based?)
|
||||
- Should agent validate before applying?
|
||||
- What MCP tools needed? (query, execute, schema)
|
||||
|
||||
### Phase 4-8: Implementation, Validation, Testing, Documentation
|
||||
|
||||
---
|
||||
|
||||
**Begin with Phase 1: Discovery**
|
||||
18
commands/claude-codex-settings/plugin-dev-load-skills.md
Normal file
18
commands/claude-codex-settings/plugin-dev-load-skills.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: Load all plugin development skills
|
||||
allowed-tools: Read
|
||||
---
|
||||
|
||||
# Load Plugin Development Skills
|
||||
|
||||
Read all plugin development SKILL.md files to provide guidance. The files are located at:
|
||||
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/plugin-structure/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/agent-development/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/command-development/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/skill-development/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/hook-development/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/mcp-integration/SKILL.md
|
||||
- @${CLAUDE_PLUGIN_ROOT}/skills/plugin-settings/SKILL.md
|
||||
|
||||
Use this guidance to help with plugin development tasks.
|
||||
162
commands/claude-codex-settings/slack-tools-setup.md
Normal file
162
commands/claude-codex-settings/slack-tools-setup.md
Normal file
@@ -0,0 +1,162 @@
|
||||
---
|
||||
description: Configure Slack MCP tokens
|
||||
---
|
||||
|
||||
# Slack Tools Setup
|
||||
|
||||
**Source:** [ubie-oss/slack-mcp-server](https://github.com/ubie-oss/slack-mcp-server)
|
||||
|
||||
Configure the Slack MCP server with your tokens.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Read the MCP configuration from `${CLAUDE_PLUGIN_ROOT}/.mcp.json`.
|
||||
|
||||
Check if Slack is configured:
|
||||
|
||||
- If any of these contain placeholder values, it needs configuration:
|
||||
- `slack.env.GITHUB_TOKEN` contains `REPLACE_WITH_GITHUB_PAT`
|
||||
- `slack.env.SLACK_BOT_TOKEN` contains `REPLACE_WITH_BOT_TOKEN`
|
||||
- `slack.env.SLACK_USER_TOKEN` contains `REPLACE_WITH_USER_TOKEN`
|
||||
- If all contain actual tokens (ghp\_, xoxb-, xoxp-), already configured
|
||||
|
||||
Report status:
|
||||
|
||||
- "Slack MCP is not configured - needs tokens"
|
||||
- OR "Slack MCP is already configured"
|
||||
|
||||
## Step 2: Show Setup Guide
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
To configure Slack MCP, you need 3 tokens:
|
||||
|
||||
1. GitHub PAT (ghp_...) - For npm package access
|
||||
Get it at: https://github.com/settings/tokens
|
||||
Required scope: read:packages
|
||||
|
||||
2. Bot Token (xoxb-...) - From your Slack app
|
||||
3. User Token (xoxp-...) - From your Slack app
|
||||
Get both at: https://api.slack.com/apps
|
||||
Required scopes: channels:history, channels:read, chat:write, users:read
|
||||
|
||||
Don't need Slack MCP? Disable it via /mcp command.
|
||||
```
|
||||
|
||||
## Step 3: Ask for GitHub PAT
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your GitHub PAT ready?"
|
||||
- header: "GitHub PAT"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my GitHub PAT ready to paste (starts with ghp\_)"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/slack-tools:setup` again when ready
|
||||
- Remind them they can disable Slack MCP via `/mcp` if not needed
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides token via "Other":
|
||||
|
||||
- If they provided token in "Other" response, use that
|
||||
- Otherwise, ask them to paste the token
|
||||
|
||||
## Step 4: Ask for Bot Token
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your Slack Bot Token ready?"
|
||||
- header: "Bot Token"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my Slack bot token ready (starts with xoxb-)"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/slack-tools:setup` again when ready
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides token via "Other":
|
||||
|
||||
- If they provided token in "Other" response, use that
|
||||
- Otherwise, ask them to paste the token
|
||||
|
||||
## Step 5: Ask for User Token
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your Slack User Token ready?"
|
||||
- header: "User Token"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my Slack user token ready (starts with xoxp-)"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/slack-tools:setup` again when ready
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides token via "Other":
|
||||
|
||||
- If they provided token in "Other" response, use that
|
||||
- Otherwise, ask them to paste the token
|
||||
|
||||
## Step 6: Validate Tokens
|
||||
|
||||
Validate the provided tokens:
|
||||
|
||||
- GitHub PAT must start with `ghp_`
|
||||
- Bot Token must start with `xoxb-`
|
||||
- User Token must start with `xoxp-`
|
||||
|
||||
If any invalid:
|
||||
|
||||
- Show error with specific token that failed validation
|
||||
- Ask if they want to try again or skip
|
||||
|
||||
## Step 7: Update Configuration
|
||||
|
||||
1. Read current `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
2. Create backup at `${CLAUDE_PLUGIN_ROOT}/.mcp.json.backup`
|
||||
3. Update these values:
|
||||
- `slack.env.GITHUB_TOKEN` to the GitHub PAT
|
||||
- `slack.env.SLACK_BOT_TOKEN` to the bot token
|
||||
- `slack.env.SLACK_USER_TOKEN` to the user token
|
||||
4. Write updated configuration back to `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
|
||||
## Step 8: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Slack MCP configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
To verify after restart, run /mcp and check that 'slack' server is connected.
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If Slack MCP fails after configuration:
|
||||
|
||||
```
|
||||
Common fixes:
|
||||
1. invalid_auth - Token expired or invalid, regenerate from api.slack.com
|
||||
2. missing_scope - Re-install app with required OAuth scopes
|
||||
3. Token format - Bot tokens start with xoxb-, user tokens with xoxp-
|
||||
4. Channel not found - Ensure bot is invited to the channel
|
||||
5. Rate limited - Wait and retry, reduce request frequency
|
||||
```
|
||||
165
commands/claude-codex-settings/statusline-tools-setup.md
Normal file
165
commands/claude-codex-settings/statusline-tools-setup.md
Normal file
@@ -0,0 +1,165 @@
|
||||
---
|
||||
description: Configure Claude Code statusline
|
||||
---
|
||||
|
||||
# Statusline Setup
|
||||
|
||||
Configure the Claude Code statusline to display session context, cost, and account-wide usage.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Read `~/.claude/settings.json` and `.claude/settings.local.json` to check if `statusLine` is configured.
|
||||
|
||||
Report:
|
||||
|
||||
- "Statusline configured in user settings: [command]" if found in ~/.claude/settings.json
|
||||
- "Statusline configured in project settings: [command]" if found in .claude/settings.local.json
|
||||
- "Statusline is not configured" if neither exists
|
||||
|
||||
## Step 2: Show Options
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Statusline Options:
|
||||
|
||||
1. Native (recommended for Claude subscription/API)
|
||||
- Shows: [Session] context% $cost | [5H] usage% time-until-reset
|
||||
- Account-wide 5H usage tracking with time until reset
|
||||
- Color-coded: green <50%, yellow 50-80%, red >80%
|
||||
- Requires: Claude subscription (Max/Pro) or Claude API key
|
||||
- Does NOT work with: z.ai, third-party endpoints
|
||||
|
||||
2. ccusage (for external endpoints)
|
||||
- Shows: context%, session/daily cost
|
||||
- Works with: Anthropic, z.ai, third-party endpoints
|
||||
- Limitation: No account-wide 5H block usage info
|
||||
|
||||
3. Disable - Remove statusline
|
||||
```
|
||||
|
||||
## Step 3: Ask for Choice
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Which statusline do you want?"
|
||||
- header: "Statusline"
|
||||
- options:
|
||||
- label: "Native (Claude subscription/API)"
|
||||
description: "Session + account-wide 5H usage with reset time"
|
||||
- label: "ccusage (external endpoints)"
|
||||
description: "Works with z.ai - no 5H block info"
|
||||
- label: "Disable"
|
||||
description: "Remove statusline"
|
||||
|
||||
## Step 4: If Native Selected
|
||||
|
||||
### Ask where to install
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Where should the statusline be configured?"
|
||||
- header: "Location"
|
||||
- options:
|
||||
- label: "User settings (global)"
|
||||
description: "~/.claude/settings.json - applies to all projects"
|
||||
- label: "Project local"
|
||||
description: ".claude/settings.local.json - this project only"
|
||||
|
||||
### Check for existing config
|
||||
|
||||
If statusLine already exists in chosen location, use AskUserQuestion:
|
||||
|
||||
- question: "Statusline already configured. Replace it?"
|
||||
- header: "Override"
|
||||
- options:
|
||||
- label: "Yes, replace"
|
||||
description: "Override existing statusline config"
|
||||
- label: "No, cancel"
|
||||
description: "Keep current config"
|
||||
|
||||
If user chooses "No, cancel", stop and say "Setup cancelled."
|
||||
|
||||
### Install Native
|
||||
|
||||
1. Read `${CLAUDE_PLUGIN_ROOT}/scripts/statusline.sh`
|
||||
2. Write to `~/.claude/statusline.sh`
|
||||
3. Run `chmod +x ~/.claude/statusline.sh`
|
||||
4. Read current settings file (user or project based on choice)
|
||||
5. Create backup with `.backup` suffix
|
||||
6. Add/update `statusLine`:
|
||||
|
||||
```json
|
||||
"statusLine": {
|
||||
"type": "command",
|
||||
"command": "~/.claude/statusline.sh",
|
||||
"padding": 0
|
||||
}
|
||||
```
|
||||
|
||||
7. Write back to settings file
|
||||
|
||||
## Step 5: If ccusage Selected
|
||||
|
||||
### Ask where to install
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Where should the statusline be configured?"
|
||||
- header: "Location"
|
||||
- options:
|
||||
- label: "User settings (global)"
|
||||
description: "~/.claude/settings.json - applies to all projects"
|
||||
- label: "Project local"
|
||||
description: ".claude/settings.local.json - this project only"
|
||||
|
||||
### Check for existing config and confirm override (same as Native)
|
||||
|
||||
### Install ccusage
|
||||
|
||||
1. Read current settings file
|
||||
2. Create backup with `.backup` suffix
|
||||
3. Add/update `statusLine`:
|
||||
|
||||
```json
|
||||
"statusLine": {
|
||||
"type": "command",
|
||||
"command": "npx -y ccusage@latest statusline --cost-source cc",
|
||||
"padding": 0
|
||||
}
|
||||
```
|
||||
|
||||
4. Write back to settings file
|
||||
|
||||
## Step 6: If Disable Selected
|
||||
|
||||
1. Read `~/.claude/settings.json`
|
||||
2. Create backup
|
||||
3. Remove `statusLine` key if exists
|
||||
4. Write back
|
||||
|
||||
Also check `.claude/settings.local.json` and remove `statusLine` if present.
|
||||
|
||||
## Step 7: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Statusline configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code (Ctrl+C or /exit)
|
||||
- Run `claude` again
|
||||
|
||||
Backup saved to [settings-file].backup
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
Native statusline requires `jq`. Check with `which jq`.
|
||||
|
||||
If jq not installed:
|
||||
|
||||
- macOS: `brew install jq`
|
||||
- Ubuntu/Debian: `sudo apt install jq`
|
||||
- Other: https://jqlang.org/download/
|
||||
96
commands/claude-codex-settings/supabase-tools-setup.md
Normal file
96
commands/claude-codex-settings/supabase-tools-setup.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
description: Configure Supabase MCP with OAuth authentication
|
||||
---
|
||||
|
||||
# Supabase Tools Setup
|
||||
|
||||
**Source:** [supabase-community/supabase-mcp](https://github.com/supabase-community/supabase-mcp)
|
||||
|
||||
Configure the official Supabase MCP server with OAuth.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Read the MCP configuration from `${CLAUDE_PLUGIN_ROOT}/.mcp.json`.
|
||||
|
||||
Check if Supabase is configured:
|
||||
|
||||
- If `supabase.url` contains `REPLACE_WITH_PROJECT_REF`, it needs configuration
|
||||
- If it contains an actual project reference, already configured
|
||||
|
||||
Report status:
|
||||
|
||||
- "Supabase MCP is not configured - needs project reference"
|
||||
- OR "Supabase MCP is configured with project: PROJECT_REF"
|
||||
|
||||
## Step 2: Show Setup Guide
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
To configure Supabase MCP, you need your Supabase project reference.
|
||||
|
||||
Quick steps:
|
||||
1. Go to supabase.com/dashboard
|
||||
2. Select your project
|
||||
3. Go to Project Settings > General
|
||||
4. Copy the "Reference ID" (looks like: abcdefghijklmnop)
|
||||
|
||||
The MCP uses OAuth - you'll authenticate via browser when first connecting.
|
||||
```
|
||||
|
||||
## Step 3: Ask for Project Reference
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your Supabase project reference ready?"
|
||||
- header: "Project Ref"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my Supabase project reference ready"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/supabase-tools:setup` again when ready
|
||||
- Remind them they can disable Supabase MCP via `/mcp` if not needed
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides reference via "Other":
|
||||
|
||||
- If they provided reference in "Other" response, use that
|
||||
- Otherwise, ask them to paste the project reference
|
||||
|
||||
## Step 4: Validate Reference
|
||||
|
||||
Validate the provided reference:
|
||||
|
||||
- Must be alphanumeric
|
||||
- Should be 16-24 characters
|
||||
|
||||
If invalid:
|
||||
|
||||
- Show error: "Invalid project reference format"
|
||||
- Ask if they want to try again or skip
|
||||
|
||||
## Step 5: Update Configuration
|
||||
|
||||
1. Read current `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
2. Create backup at `${CLAUDE_PLUGIN_ROOT}/.mcp.json.backup`
|
||||
3. Replace `REPLACE_WITH_PROJECT_REF` with the actual project reference in the URL
|
||||
4. Write updated configuration back to `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
|
||||
## Step 6: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Supabase MCP configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
On first use, you'll be prompted to authenticate via browser (OAuth).
|
||||
To verify after restart, run /mcp and check that 'supabase' server is connected.
|
||||
```
|
||||
97
commands/claude-codex-settings/tavily-tools-setup.md
Normal file
97
commands/claude-codex-settings/tavily-tools-setup.md
Normal file
@@ -0,0 +1,97 @@
|
||||
---
|
||||
description: Configure Tavily MCP server credentials
|
||||
---
|
||||
|
||||
# Tavily Tools Setup
|
||||
|
||||
**Source:** [tavily-ai/tavily-mcp](https://github.com/tavily-ai/tavily-mcp)
|
||||
|
||||
Configure the Tavily MCP server with your API key.
|
||||
|
||||
## Step 1: Check Current Status
|
||||
|
||||
Read the MCP configuration from `${CLAUDE_PLUGIN_ROOT}/.mcp.json`.
|
||||
|
||||
Check if Tavily is configured:
|
||||
|
||||
- If `tavily.env.TAVILY_API_KEY` contains `REPLACE_WITH_TAVILY_API_KEY`, it needs configuration
|
||||
- If it contains a value starting with `tvly-`, already configured
|
||||
|
||||
Report status:
|
||||
|
||||
- "Tavily MCP is not configured - needs an API key"
|
||||
- OR "Tavily MCP is already configured"
|
||||
|
||||
## Step 2: Show Setup Guide
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
To configure Tavily MCP, you need a Tavily API key.
|
||||
|
||||
Quick steps:
|
||||
1. Go to app.tavily.com and sign in
|
||||
2. Navigate to API Keys
|
||||
3. Create a new API key
|
||||
4. Copy the key (starts with tvly-)
|
||||
|
||||
Free tier: 1,000 searches/month
|
||||
|
||||
Don't need Tavily MCP? Disable it via /mcp command.
|
||||
```
|
||||
|
||||
## Step 3: Ask for Key
|
||||
|
||||
Use AskUserQuestion:
|
||||
|
||||
- question: "Do you have your Tavily API key ready?"
|
||||
- header: "Tavily Key"
|
||||
- options:
|
||||
- label: "Yes, I have it"
|
||||
description: "I have my Tavily API key ready to paste"
|
||||
- label: "No, skip for now"
|
||||
description: "I'll configure it later"
|
||||
|
||||
If user selects "No, skip for now":
|
||||
|
||||
- Tell them they can run `/tavily-tools:setup` again when ready
|
||||
- Remind them they can disable Tavily MCP via `/mcp` if not needed
|
||||
- Exit
|
||||
|
||||
If user selects "Yes" or provides key via "Other":
|
||||
|
||||
- If they provided key in "Other" response, use that
|
||||
- Otherwise, ask them to paste the key
|
||||
|
||||
## Step 4: Validate Key
|
||||
|
||||
Validate the provided key:
|
||||
|
||||
- Must start with `tvly-`
|
||||
- Must be at least 20 characters
|
||||
|
||||
If invalid:
|
||||
|
||||
- Show error: "Invalid key format. Tavily keys start with 'tvly-'"
|
||||
- Ask if they want to try again or skip
|
||||
|
||||
## Step 5: Update Configuration
|
||||
|
||||
1. Read current `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
2. Create backup at `${CLAUDE_PLUGIN_ROOT}/.mcp.json.backup`
|
||||
3. Update `tavily.env.TAVILY_API_KEY` value to the actual key
|
||||
4. Write updated configuration back to `${CLAUDE_PLUGIN_ROOT}/.mcp.json`
|
||||
|
||||
## Step 6: Confirm Success
|
||||
|
||||
Tell the user:
|
||||
|
||||
```
|
||||
Tavily MCP configured successfully!
|
||||
|
||||
IMPORTANT: Restart Claude Code for changes to take effect.
|
||||
- Exit Claude Code
|
||||
- Run `claude` again
|
||||
|
||||
To verify after restart, run /mcp and check that 'tavily' server is connected.
|
||||
```
|
||||
Reference in New Issue
Block a user