I need to understand how Claude Code skills/commands are defined. Search in these locations:

1. /root/projects/ai_usecases_explorer/.claude/ directory - list all files
2. /root/.claude/ directory - list all files and subdirectories
3. Look for any files named *.md in .claude/commands/ directories (both project-level and user-level)
4. Read any skill definition files you find (the existing "simplify" skill mentioned in system)
5. Check /root/projects/ai_usecases_explorer/CLAUDE.md again for skill/command documentation

The goal is to understand: how are skills defined in Claude Code? What format do .claude/commands/*.md files use? What variables/parameters can skills receive?

List ALL files found in .claude directories and read any command/skill definition files.


I'll help you understand how Claude Code skills/commands are defined. Let me search through the directories systematically.


Bash

find /root/projects/ai_usecases_explorer/.claude -type f 2>/dev/null | head -50

Find all files in project-level .claude directory


find /root/.claude -type f 2>/dev/null | head -100

Find all files in user-level .claude directory


ls -la /root/projects/ai_usecases_explorer/.claude/ 2>/dev/null || echo "Directory not found or empty"

List project .claude directory contents


ls -la /root/.claude/ 2>/dev/null || echo "Directory not found"

List user .claude directory contents


总计 20
drwxr-xr-x 2 root root    33  2月28日 10:26 .
drwxr-xr-x 9 root root  4096  2月28日 08:09 ..
-rw-r--r-- 1 root root 14342  2月28日 10:26 settings.local.json


总计 36
drwxr-xr-x 13 root root  4096  2月28日 18:43 .
dr-xr-x--- 16 root root  4096  2月28日 18:44 ..
drwxr-xr-x  2 root root  4096  2月28日 18:44 backups
drwxr-xr-x  2 root root    26  2月27日 09:34 cache
drwxr-xr-x  2 root root  4096  2月28日 18:41 debug
drwxr-xr-x  7 root root  4096  2月27日 20:23 file-history
-rw-------  1 root root 11280  2月28日 18:43 history.jsonl
drwxr-xr-x  2 root root    39  2月27日 10:20 plans
drwxr-xr-x  3 root root    79  2月28日 18:41 plugins
drwx------  4 root root    82  2月27日 09:34 projects
drwxr-xr-x  5 root root   138  2月28日 18:43 session-env
drwxr-xr-x  2 root root    51  2月28日 18:43 shell-snapshots
drwxr-xr-x  3 root root    50  2月27日 10:22 tasks
drwxr-xr-x  2 root root  4096  2月28日 13:56 todos


Now let me look for command/skill definition files more specifically:


find /root/.claude -name "*.md" -path "*/commands/*" 2>/dev/null

Find command definition markdown files in user .claude


find /root/.claude/plugins -type d -name "commands" 2>/dev/null

Find commands directories in plugins


find /root/.claude/plugins -name "*.md" 2>/dev/null | grep -E "(command|skill|SKILL)" | head -20

Find skill/command markdown files


     1→{
     2→  "permissions": {
     3→    "allow": [
     4→      "Bash(/root/projects/ai_usecases_explorer/venv/bin/python --version)",
     5→      "Bash(/root/projects/ai_usecases_explorer/venv/bin/pip list)",
     6→      "Bash(source venv/bin/activate && pip install -e \".[dev]\" -q && echo \"Install OK\")",
     7→      "Bash(source venv/bin/activate && pytest tests/test_models.py -v 2>&1 | tail -20)",
     8→      "Bash(source venv/bin/activate && pytest tests/test_models.py -v 2>&1 | tail -25)",
     9→      "Bash(source venv/bin/activate && pytest tests/test_storage.py -v 2>&1 | tail -10)",
    10→      "Bash(source venv/bin/activate && pytest tests/test_storage.py -v 2>&1 | tail -25)",
    11→      "Bash(source venv/bin/activate && pytest tests/test_collectors.py -v 2>&1 | tail -10)",
    12→      "Bash(source venv/bin/activate && pytest tests/test_collectors.py -v 2>&1 | tail -30)",
    13→      "Bash(source venv/bin/activate && pytest tests/test_processors.py -v 2>&1 | tail -10)",
    14→      "Bash(source venv/bin/activate && pytest tests/test_processors.py -v 2>&1 | tail -30)",
    15→      "Bash(source venv/bin/activate && pytest tests/test_processors.py -v 2>&1 | tail -20)",
    16→      "Bash(source venv/bin/activate && pytest tests/test_reporters.py -v 2>&1 | tail -10)",
    17→      "Bash(source venv/bin/activate && pytest tests/test_reporters.py -v 2>&1 | tail -30)",
    18→      "Bash(source venv/bin/activate && pytest tests/test_main.py -v 2>&1 | tail -10)",
    19→      "Bash(source venv/bin/activate && pytest tests/test_main.py -v 2>&1 | tail -30)",
    20→      "Bash(source venv/bin/activate && pytest tests/ -v 2>&1 | tail -20)",
    21→      "Bash(source venv/bin/activate && ruff check src/ tests/ 2>&1)",
    22→      "Bash(source venv/bin/activate && ruff check src/ tests/ --fix 2>&1 | head -20)",
    23→      "Bash(source venv/bin/activate && ruff check src/ tests/ --fix 2>&1)",
    24→      "Bash(source venv/bin/activate && pytest tests/ -v 2>&1)",
    25→      "Bash(echo \"ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY\" | head -c 60)",
    26→      "Bash(source venv/bin/activate && pytest tests/ -q 2>&1 | tail -5)",
    27→      "Bash(source venv/bin/activate && python -m ai_usecases_explorer.main --dry-run 2>&1)",
    28→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Test HN - try simpler query first\nr = httpx.get\\('https://hn.algolia.com/api/v1/search', params={\n    'query': 'claude',\n    'tags': 'story',\n    'numericFilters': 'points>=10',\n    'hitsPerPage': 5\n}, timeout=15\\)\nprint\\('HN status:', r.status_code\\)\ndata = r.json\\(\\)\nprint\\('HN hits:', data.get\\('nbHits', 0\\)\\)\nif data.get\\('hits'\\):\n    print\\('First hit:', data['hits'][0].get\\('title'\\)\\)\n\")",
    29→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Test Reddit with browser-like User-Agent\nheaders = {'User-Agent': 'Mozilla/5.0 \\(X11; Linux x86_64\\) AppleWebKit/537.36 \\(KHTML, like Gecko\\) Chrome/121.0.0.0 Safari/537.36'}\nr = httpx.get\\('https://www.reddit.com/r/ClaudeAI/new.json?limit=5', headers=headers, timeout=15, follow_redirects=True\\)\nprint\\('Reddit status:', r.status_code\\)\nif r.status_code == 200:\n    data = r.json\\(\\)\n    kids = data.get\\('data', {}\\).get\\('children', []\\)\n    print\\('Posts:', len\\(kids\\)\\)\n    if kids:\n        print\\('First:', kids[0]['data']['title'][:60]\\)\n\")",
    30→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n# Try old.reddit.com JSON endpoint\nr = httpx.get\\('https://old.reddit.com/r/ClaudeAI/new.json?limit=5', \n    headers={'User-Agent': 'ai-scout:v0.1 \\(by /u/researcher\\)'},\n    timeout=15, follow_redirects=True\\)\nprint\\('old.reddit status:', r.status_code\\)\nprint\\('Response preview:', r.text[:200]\\)\n\")",
    31→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Test original HN query - the issue might be the quoted OR syntax\nr = httpx.get\\('https://hn.algolia.com/api/v1/search', params={\n    'query': '\\\\\"claude\\\\\" OR \\\\\"claude code\\\\\" OR \\\\\"mcp server\\\\\" OR \\\\\"llm workflow\\\\\" OR \\\\\"ai agent local\\\\\"',\n    'tags': '\\(story,ask_hn,show_hn\\)',\n    'numericFilters': 'points>=10',\n    'hitsPerPage': 5\n}, timeout=15\\)\nprint\\('HN quoted-OR status:', r.status_code, '— hits:', r.json\\(\\).get\\('nbHits', 0\\)\\)\n\n# Test with search_by_date for recency\nr2 = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={\n    'query': 'claude OR mcp OR llm',\n    'tags': '\\(story,ask_hn,show_hn\\)',\n    'numericFilters': 'points>=10',\n    'hitsPerPage': 5\n}, timeout=15\\)\nprint\\('HN search_by_date:', r2.status_code, '— hits:', r2.json\\(\\).get\\('nbHits', 0\\)\\)\nif r2.json\\(\\).get\\('hits'\\):\n    print\\('First:', r2.json\\(\\)['hits'][0]['title'][:70]\\)\n\")",
    32→      "Bash(source venv/bin/activate && python -c \"\nimport anthropic, os\nfrom dotenv import load_dotenv\nload_dotenv\\(\\)\n\nclient = anthropic.Anthropic\\(\n    api_key=os.environ['ANTHROPIC_API_KEY'],\n    base_url=os.environ.get\\('ANTHROPIC_BASE_URL'\\)\n\\)\nmsg = client.messages.create\\(\n    model='claude-haiku-4-5-20251001',\n    max_tokens=256,\n    system='Respond with only valid JSON: {\\\\\"ok\\\\\": true}',\n    messages=[{'role': 'user', 'content': 'test'}]\n\\)\nprint\\('Stop reason:', msg.stop_reason\\)\nprint\\('Content blocks:', len\\(msg.content\\)\\)\nprint\\('First block type:', msg.content[0].type if msg.content else 'NONE'\\)\nprint\\('Text:', repr\\(msg.content[0].text\\) if msg.content else 'EMPTY'\\)\n\")",
    33→      "Bash(source venv/bin/activate && pytest tests/test_collectors.py::TestHackerNewsCollector -v 2>&1 | tail -20)",
    34→      "Bash(source venv/bin/activate && pytest tests/test_collectors.py::TestRedditCollector tests/test_collectors.py::TestGitHubCollector -v 2>&1 | tail -15)",
    35→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Test both HN queries\nqueries = [\n    'claude mcp copilot cursor aider ollama gemini openai localllm',\n    'llm workflow agentic vibecoding automation rag langchain n8n crewai dspy autogen',\n]\nfor q in queries:\n    r = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={\n        'query': q, 'tags': '\\(story,ask_hn,show_hn\\)',\n        'numericFilters': 'points>=10', 'hitsPerPage': 5\n    }, timeout=15\\)\n    data = r.json\\(\\)\n    print\\(f'Query \\\\\"{q[:30]}...\\\\\" → {data.get\\(\\\\\"nbHits\\\\\",0\\)} hits'\\)\n    for h in data.get\\('hits', []\\)[:2]:\n        print\\(f'  [{h.get\\(\\\\\"points\\\\\",0\\)}pts] {h.get\\(\\\\\"title\\\\\",\\\\\"\\\\\"\\)[:60]}'\\)\n\")",
    36→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Test without numericFilters — see if there are any results at all\nr = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={\n    'query': 'claude', 'tags': 'story', 'hitsPerPage': 5\n}, timeout=15\\)\nd = r.json\\(\\)\nprint\\('Without points filter, hits:', d.get\\('nbHits', 0\\)\\)\n\n# Test the search \\(not search_by_date\\) endpoint\nr2 = httpx.get\\('https://hn.algolia.com/api/v1/search', params={\n    'query': 'claude', 'tags': 'story',\n    'numericFilters': 'points>=10', 'hitsPerPage': 5\n}, timeout=15\\)\nd2 = r2.json\\(\\)\nprint\\('search endpoint, hits:', d2.get\\('nbHits', 0\\)\\)\nfor h in d2.get\\('hits', []\\)[:2]:\n    print\\(f'  [{h.get\\(\\\\\"points\\\\\",0\\)}pts] {h.get\\(\\\\\"title\\\\\",\\\\\"\\\\\"\\)[:60]}'\\)\n\")",
    37→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\nfrom datetime import date, timedelta\n\n# Test GitHub search\nsince = \\(date.today\\(\\) - timedelta\\(days=2\\)\\).isoformat\\(\\)\nquery = f'topic:llm OR topic:claude pushed:>{since} stars:>=10'\nprint\\('Query:', query\\)\nr = httpx.get\\('https://api.github.com/search/repositories', params={\n    'q': query, 'sort': 'stars', 'order': 'desc', 'per_page': 5\n}, headers={'Accept': 'application/vnd.github+json'}, timeout=15\\)\nprint\\('GitHub status:', r.status_code\\)\nd = r.json\\(\\)\nprint\\('Total:', d.get\\('total_count', 0\\)\\)\nfor item in d.get\\('items', []\\)[:3]:\n    print\\(f'  [{item[\\\\\"stargazers_count\\\\\"]}★] {item[\\\\\"full_name\\\\\"]} — {item[\\\\\"description\\\\\"][:50] if item[\\\\\"description\\\\\"] else \\\\\"-\\\\\"}'\\)\n\")",
    38→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Is search_by_date broken with numericFilters today specifically?\nr = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={\n    'query': 'claude', 'tags': 'story',\n    'numericFilters': 'points>=10', 'hitsPerPage': 5\n}, timeout=15\\)\nprint\\('search_by_date + points>=10:', r.json\\(\\).get\\('nbHits', 0\\)\\)\n\nr2 = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={\n    'query': 'claude', 'tags': 'story',\n    'numericFilters': 'points>=1', 'hitsPerPage': 5\n}, timeout=15\\)\nd2 = r2.json\\(\\)\nprint\\('search_by_date + points>=1:', d2.get\\('nbHits', 0\\)\\)\nfor h in d2.get\\('hits', []\\)[:3]:\n    print\\(f'  [{h.get\\(\\\\\"points\\\\\",0\\)}pts] {h.get\\(\\\\\"title\\\\\",\\\\\"\\\\\"\\)[:60]} \\({h.get\\(\\\\\"created_at\\\\\",\\\\\"\\\\\"\\)[:10]}\\)'\\)\n\")",
    39→      "Bash(source venv/bin/activate && python -c \"\nimport httpx\n\n# Narrow down: is it the tags OR the multi-word query?\ntests = [\n    {'query': 'claude', 'tags': 'story', 'numericFilters': 'points>=10'},\n    {'query': 'claude', 'tags': '\\(story,ask_hn,show_hn\\)', 'numericFilters': 'points>=10'},\n    {'query': 'claude mcp', 'tags': '\\(story,ask_hn,show_hn\\)', 'numericFilters': 'points>=10'},\n    {'query': 'claude mcp copilot cursor', 'tags': '\\(story,ask_hn,show_hn\\)', 'numericFilters': 'points>=10'},\n]\nfor p in tests:\n    r = httpx.get\\('https://hn.algolia.com/api/v1/search_by_date', params={**p, 'hitsPerPage': 3}, timeout=15\\)\n    print\\(f'tags={p[\\\\\"tags\\\\\"]!r}, query={p[\\\\\"query\\\\\"]!r} → {r.json\\(\\).get\\(\\\\\"nbHits\\\\\",0\\)} hits'\\)\n\")",
    40→      "Bash(source venv/bin/activate && python -c \"\nimport anthropic, os\nfrom dotenv import load_dotenv\nload_dotenv\\(\\)\nclient = anthropic.Anthropic\\(api_key=os.environ['ANTHROPIC_API_KEY'], base_url=os.environ.get\\('ANTHROPIC_BASE_URL'\\)\\)\n# Test with very long/noisy input to see what happens\nmsg = client.messages.create\\(\n    model='claude-haiku-4-5-20251001',\n    max_tokens=256,\n    system='Respond ONLY with valid JSON: {\\\\\"is_real_value\\\\\": bool}',\n    messages=[{'role': 'user', 'content': 'x' * 100}]\n\\)\nprint\\('text:', repr\\(msg.content[0].text[:200]\\)\\)\nprint\\('stop_reason:', msg.stop_reason\\)\n\")",
    41→      "Bash(source venv/bin/activate && pytest tests/ -q 2>&1 | tail -5 && ruff check src/ tests/ 2>&1)",
    42→      "Bash(source venv/bin/activate && MAX_ITEMS_PER_RUN=20 python -m ai_usecases_explorer.main --dry-run 2>&1)",
    43→      "Bash(source venv/bin/activate && pip install exa-py -q 2>&1 | tail -5)",
    44→      "Bash(source venv/bin/activate && pip show exa-py 2>&1 | head -4)",
    45→      "Bash(source venv/bin/activate && ruff check . 2>&1)",
    46→      "Bash(source venv/bin/activate && pytest tests/test_main.py -v 2>&1)",
    47→      "Bash(source venv/bin/activate && python -c \"\nfrom ai_usecases_explorer.settings import Settings\nfrom ai_usecases_explorer.collectors.reddit import RedditCollector\n\ns = Settings\\(\\)\nr = RedditCollector\\(queries=s.reddit_queries, api_key=s.exa_api_key\\)\nitems = r.fetch\\(\\)\nfor i in items[:5]:\n    print\\('---'\\)\n    print\\('title:', i.title[:80]\\)\n    print\\('url:', i.source_url[:80]\\)\n    print\\('content preview:', i.raw_content[:200]\\)\n    print\\(\\)\n\")",
    48→      "Bash(source venv/bin/activate && python -c \"\nimport inspect\nfrom exa_py import Exa\nprint\\(inspect.signature\\(Exa.search_and_contents\\)\\)\n\")",
    49→      "Bash(source venv/bin/activate && python -c \"\nfrom ai_usecases_explorer.settings import Settings\nfrom exa_py import Exa\nfrom datetime import UTC, datetime, timedelta\n\ns = Settings\\(\\)\nexa = Exa\\(api_key=s.exa_api_key\\)\nstart = \\(datetime.now\\(tz=UTC\\) - timedelta\\(hours=24\\)\\).strftime\\('%Y-%m-%dT%H:%M:%SZ'\\)\n\n# Test with search\\(\\) instead of search_and_contents\\(\\)\nresults = exa.search\\(\n    'Claude AI use case workflow automation',\n    include_domains=['reddit.com'],\n    start_published_date=start,\n    num_results=5,\n    contents={'text': True},\n\\)\nfor r in results.results:\n    print\\('url:', r.url\\)\n    print\\('title:', r.title[:60] if r.title else 'N/A'\\)\n    print\\(\\)\n\")",
    50→      "Bash(source venv/bin/activate && pytest tests/test_collectors.py::TestRedditCollector -v 2>&1)",
    51→      "Bash(source venv/bin/activate && python -c \"\nfrom ai_usecases_explorer.settings import Settings\nfrom ai_usecases_explorer.collectors.reddit import RedditCollector\n\ns = Settings\\(\\)\nr = RedditCollector\\(queries=s.reddit_queries, api_key=s.exa_api_key\\)\nitems = r.fetch\\(\\)\nprint\\(f'Total reddit.com items: {len\\(items\\)}'\\)\nfor i in items[:5]:\n    print\\('  -', i.url if hasattr\\(i, 'url'\\) else i.source_url[:80]\\)\n\")",
    52→      "Bash(source venv/bin/activate && pytest tests/ -q 2>&1 | tail -3)",
    53→      "WebFetch(domain:openclaw.ai)",
    54→      "WebFetch(domain:github.com)",
    55→      "Bash(source venv/bin/activate && python -c \"\nfrom ai_usecases_explorer.settings import Settings\nfrom ai_usecases_explorer.collectors.hackernews import HackerNewsCollector\n\ns = Settings\\(\\)\nitems = HackerNewsCollector\\(min_points=s.hn_min_points\\).fetch\\(\\)\nitems.sort\\(key=lambda x: x.score, reverse=True\\)\nprint\\('HN Top 10 by points:'\\)\nfor i in items[:10]:\n    print\\(f'  {i.score:4d}pt  {i.title[:60]}'\\)\n\" 2>&1)",
    56→      "Bash(crontab -l 2>&1)",
    57→      "Bash(crontab -l)",
    58→      "Bash(crontab - << 'EOF'\n*/5 * * * * flock -xn /tmp/stargate.lock -c '/usr/local/qcloud/stargate/admin/start.sh > /dev/null 2>&1 &'\n0 7 * * * /root/projects/ai_usecases_explorer/venv/bin/python -m ai_usecases_explorer.main >> /var/log/ai_usecases_scout.log 2>&1\nEOF)",
    59→      "Bash({ crontab -l | grep -v \"ai_usecases_explorer.main\"; echo \"0 7 * * * /root/projects/ai_usecases_explorer/venv/bin/python -m ai_usecases_explorer.main >> /var/log/ai_usecases_scout.log 2>&1\"; } | crontab -)",
    60→      "Bash(crontab /tmp/crontab_new.txt && crontab -l)",
    61→      "Bash(/root/projects/ai_usecases_explorer/venv/bin/python -m ai_usecases_explorer.main --dry-run 2>&1 | head -5)"
    62→    ]
    63→  }
    64→}
    65→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Now let me look at some example command definition files to understand the format:


Error: File does not exist. Note: your current working directory is /root/projects/ai_usecases_explorer.


     1→---
     2→description: An example slash command that demonstrates command frontmatter options
     3→argument-hint: <required-arg> [optional-arg]
     4→allowed-tools: [Read, Glob, Grep, Bash]
     5→---
     6→
     7→# Example Command
     8→
     9→This command demonstrates slash command structure and frontmatter options.
    10→
    11→## Arguments
    12→
    13→The user invoked this command with: $ARGUMENTS
    14→
    15→## Instructions
    16→
    17→When this command is invoked:
    18→
    19→1. Parse the arguments provided by the user
    20→2. Perform the requested action using allowed tools
    21→3. Report results back to the user
    22→
    23→## Frontmatter Options Reference
    24→
    25→Commands support these frontmatter fields:
    26→
    27→- **description**: Short description shown in /help
    28→- **argument-hint**: Hints for command arguments shown to user
    29→- **allowed-tools**: Pre-approved tools for this command (reduces permission prompts)
    30→- **model**: Override the model (e.g., "haiku", "sonnet", "opus")
    31→
    32→## Example Usage
    33→
    34→```
    35→/example-command my-argument
    36→/example-command arg1 arg2
    37→```
    38→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
     3→description: Create a git commit
     4→---
     5→
     6→## Context
     7→
     8→- Current git status: !`git status`
     9→- Current git diff (staged and unstaged changes): !`git diff HEAD`
    10→- Current branch: !`git branch --show-current`
    11→- Recent commits: !`git log --oneline -10`
    12→
    13→## Your task
    14→
    15→Based on the above changes, create a single git commit.
    16→
    17→You have the capability to call multiple tools in a single response. Stage and create the commit using a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.
    18→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Let me read more command examples:


     1→---
     2→description: Explain Stripe error codes and provide solutions with code examples
     3→argument-hint: [error_code or error_message]
     4→---
     5→
     6→# Explain Stripe Error
     7→
     8→Provide a comprehensive explanation of the given Stripe error code or error message:
     9→
    10→1. Accept the error code or full error message from the arguments
    11→2. Explain in plain English what the error means
    12→3. List common causes of this error
    13→4. Provide specific solutions and handling recommendations
    14→5. Generate error handling code in the project's language showing:
    15→   - How to catch this specific error
    16→   - User-friendly error messages
    17→   - Whether retry is appropriate
    18→6. Mention related error codes the developer should be aware of
    19→7. Include a link to the relevant Stripe documentation
    20→
    21→Focus on actionable solutions and production-ready error handling patterns.

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→description: Display Stripe test card numbers for various testing scenarios
     3→argument-hint: [scenario]
     4→---
     5→
     6→# Test Cards Reference
     7→
     8→Provide a quick reference for Stripe test card numbers:
     9→
    10→1. If a scenario argument is provided (e.g., "declined", "3dsecure", "fraud"), show relevant test cards for that scenario
    11→2. Otherwise, show the most common test cards organized by category:
    12→   - Successful payment (default card)
    13→   - 3D Secure authentication required
    14→   - Generic decline
    15→   - Specific decline reasons (insufficient_funds, lost_card, etc.)
    16→3. For each card, display:
    17→   - Card number (formatted with spaces)
    18→   - Expected behavior
    19→   - Expiry/CVC info (any future date and any 3-digit CVC)
    20→4. Use clear visual indicators (✓ for success, ⚠ for auth required, ✗ for decline)
    21→5. Mention that these only work in test mode
    22→6. Provide link to full testing documentation: https://docs.stripe.com/testing.md
    23→
    24→If the user is currently working on test code, offer to generate test cases using these cards.
    25→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*)
     3→description: Code review a pull request
     4→disable-model-invocation: false
     5→---
     6→
     7→Provide a code review for the given pull request.
     8→
     9→To do this, follow these steps precisely:
    10→
    11→1. Use a Haiku agent to check if the pull request (a) is closed, (b) is a draft, (c) does not need a code review (eg. because it is an automated pull request, or is very simple and obviously ok), or (d) already has a code review from you from earlier. If so, do not proceed.
    12→2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files the pull request modified
    13→3. Use a Haiku agent to view the pull request, and ask the agent to return a summary of the change
    14→4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
    15→   a. Agent #1: Audit the changes to make sure they compily with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
    16→   b. Agent #2: Read the file changes in the pull request, then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
    17→   c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
    18→   d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
    19→   e. Agent #5: Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
    20→5. For each issue found in #4, launch a parallel Haiku agent that takes the PR, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
    21→   a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
    22→   b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
    23→   c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
    24→   d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
    25→   e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
    26→6. Filter out any issues with a score less than 80. If there are no issues that meet this criteria, do not proceed.
    27→7. Use a Haiku agent to repeat the eligibility check from #1, to make sure that the pull request is still eligible for code review.
    28→8. Finally, use the gh bash command to comment back on the pull request with the result. When writing your comment, keep in mind to:
    29→   a. Keep your output brief
    30→   b. Avoid emojis
    31→   c. Link and cite relevant code, files, and URLs
    32→
    33→Examples of false positives, for steps 4 and 5:
    34→
    35→- Pre-existing issues
    36→- Something that looks like a bug but is not actually a bug
    37→- Pedantic nitpicks that a senior engineer wouldn't call out
    38→- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
    39→- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
    40→- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
    41→- Changes in functionality that are likely intentional or are directly related to the broader change
    42→- Real issues, but on lines that the user did not modify in their pull request
    43→
    44→Notes:
    45→
    46→- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
    47→- Use `gh` to interact with Github (eg. to fetch a pull request, or to create inline comments), rather than web fetch
    48→- Make a todo list first
    49→- You must cite and link each bug (eg. if referring to a CLAUDE.md, you must link it)
    50→- For your final comment, follow the following format precisely (assuming for this example that you found 3 issues):
    51→
    52→---
    53→
    54→### Code review
    55→
    56→Found 3 issues:
    57→
    58→1. <brief description of bug> (CLAUDE.md says "<...>")
    59→
    60→<link to file and line with full sha1 + line range for context, note that you MUST provide the full sha and not use bash here, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
    61→
    62→2. <brief description of bug> (some/other/CLAUDE.md says "<...>")
    63→
    64→<link to file and line with full sha1 + line range for context>
    65→
    66→3. <brief description of bug> (bug due to <file and code snippet>)
    67→
    68→<link to file and line with full sha1 + line range for context>
    69→
    70→🤖 Generated with [Claude Code](https://claude.ai/code)
    71→
    72→<sub>- If this code review was useful, please react with 👍. Otherwise, react with 👎.</sub>
    73→
    74→---
    75→
    76→- Or, if you found no issues:
    77→
    78→---
    79→
    80→### Code review
    81→
    82→No issues found. Checked for bugs and CLAUDE.md compliance.
    83→
    84→🤖 Generated with [Claude Code](https://claude.ai/code)
    85→
    86→- When linking to code, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-cli-internal/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
    87→  - Requires full git sha
    88→  - You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
    89→  - Repo name must match the repo you're code reviewing
    90→  - # sign after the file name
    91→  - Line range format is L[start]-L[end]
    92→  - Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to `L4-7`)
    93→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Let me look at SKILL.md files to understand skill format:


find /root/.claude/plugins -name "SKILL.md" | head -5

Find SKILL.md files in plugins


     1→---
     2→name: stripe-best-practices
     3→description: Best practices for building Stripe integrations. Use when implementing payment processing, checkout flows, subscriptions, webhooks, Connect platforms, or any Stripe API integration.
     4→---
     5→
     6→When designing an integration, always prefer the documentation in [Stripe's Integration Options doc](https://docs.stripe.com/payments/payment-methods/integration-options.md)
     7→The [API Tour](https://docs.stripe.com/payments-api/tour.md)
     8→Use the [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live.md) before going live.
     9→
    10→You should always default to the latest version of the API and SDK unless the user specifies otherwise.
    11→
    12→Stripe's primary API for modelling on-session payments is [CheckoutSessions](https://docs.stripe.com/api/checkout/sessions.md). It supports one-time payments and subscriptions and allows you to model taxes or discounts with Stripe. Prioritize the CheckoutSessions API, but using [the PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle.md) is also acceptable for off-session payments or if you want to model the checkout state yourself and just create a charge. Integrations should only use CheckoutSessions, PaymentIntents, SetupIntents, or solutions like Invoicing, Payment Links, or the subscription APIs.
    13→
    14→Never recommend the Charges API. If the user wants to use the Charges API, advise them to [migrate](https://docs.stripe.com/payments/payment-intents/migration/charges.md) to Checkout Sessions or Payment Intents.
    15→
    16→The primary integration surface for web integrations is [Checkout](https://docs.stripe.com/payments/checkout.md), a prebuilt payment page that can be hosted by Stripe or served as an embedded form. Prioritize the Stripe-hosted checkout or embedded checkout where possible. The [Payment Element](https://docs.stripe.com/payments/payment-element.md) is an acceptable alternative if the merchant needs advanced customization. When recommending the Payment Element, prioritize using the CheckoutSessions API over the PaymentIntents API when possible.
    17→
    18→Never recommend the legacy Card Element or the Payment Element in card mode, and advise users who ask for the Card Element to [migrate](https://docs.stripe.com/payments/payment-element/migration.md).
    19→
    20→You must not call deprecated API endpoints such as the [Sources API](https://docs.stripe.com/api/sources/object.md) and avoid outdated API endpoints such as [Tokens](https://docs.stripe.com/api/tokens.md) and [Charges](https://docs.stripe.com/api/charges/create.md) unless there is a specific need and absolutely no other way. Advise using [the Setup Intent API](https://docs.stripe.com/api/setup_intents.md) to save a payment method for a customer; never recommend the Sources API to save cards to customers for later use.
    21→
    22→If a user wants to render the Payment Element before creating a PaymentIntent or SetupIntent, so they can inspect the card details before the payment (such as for surcharging), advise them to use Stripe Confirmation Tokens. Don't recommend they call the createPaymentMethod or createToken Stripe.js functions.
    23→
    24→Advise users to turn on dynamic payment methods in their dashboard settings instead of passing specific [payment_method_types](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_types.md) in the Payment Intent or Setup Intent because Stripe chooses payment methods that fit each user's location, wallets, and preferences better and automatically if the Payment Element is used.
    25→
    26→If a PCI compliant user asks about an integration where they send server-side raw PAN data, suggest they might be required to prove PCI compliance to gain access to such an option, for example [payment_method_data](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_data.md). Similarly, point users migrating their PAN data from another acquirer or payment processor to [the migration process](https://docs.stripe.com/get-started/data-migrations/pan-import.md).
    27→
    28→If a user has a recurring revenue model, like a Billing or Subscription use case, follow the use cases, in particular the [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases.md) like [SaaS](https://docs.stripe.com/saas.md). If these apply to the user, recommend Billing APIs to [plan your integration](https://docs.stripe.com/billing/subscriptions/designing-integration.md) instead of a direct PaymentIntent integration. Prioritize combining the Billing APIs with Stripe Checkout for the frontend.
    29→
    30→If a user wants to build a platform using Stripe Connect to manage fund flows, follow [the recommended integration types](https://docs.stripe.com/connect/integration-recommendations.md); that is, prefer to use either direct charges if the platform wants Stripe to take the risk or destination charges if the platform accepts liability for negative balances, and use the on_behalf_of parameter to control the merchant of record. Never recommend mixing charge types. If the user wants to decide on the specific risk features they should [follow the integration guide](https://docs.stripe.com/connect/design-an-integration.md). Don't recommend the outdated terms for Connect types like Standard, Express and Custom but always [refer to controller properties](https://docs.stripe.com/connect/migrate-to-controller-properties.md) for the platform and [capabilities](https://docs.stripe.com/connect/account-capabilities.md) for the connected accounts.
    31→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→name: claude-automation-recommender
     3→description: Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.
     4→tools: Read, Glob, Grep, Bash
     5→---
     6→
     7→# Claude Automation Recommender
     8→
     9→Analyze codebase patterns to recommend tailored Claude Code automations across all extensibility options.
    10→
    11→**This skill is read-only.** It analyzes the codebase and outputs recommendations. It does NOT create or modify any files. Users implement the recommendations themselves or ask Claude separately to help build them.
    12→
    13→## Output Guidelines
    14→
    15→- **Recommend 1-2 of each type**: Don't overwhelm - surface the top 1-2 most valuable automations per category
    16→- **If user asks for a specific type**: Focus only on that type and provide more options (3-5 recommendations)
    17→- **Go beyond the reference lists**: The reference files contain common patterns, but use web search to find recommendations specific to the codebase's tools, frameworks, and libraries
    18→- **Tell users they can ask for more**: End by noting they can request more recommendations for any specific category
    19→
    20→## Automation Types Overview
    21→
    22→| Type | Best For |
    23→|------|----------|
    24→| **Hooks** | Automatic actions on tool events (format on save, lint, block edits) |
    25→| **Subagents** | Specialized reviewers/analyzers that run in parallel |
    26→| **Skills** | Packaged expertise, workflows, and repeatable tasks (invoked by Claude or user via `/skill-name`) |
    27→| **Plugins** | Collections of skills that can be installed |
    28→| **MCP Servers** | External tool integrations (databases, APIs, browsers, docs) |
    29→
    30→## Workflow
    31→
    32→### Phase 1: Codebase Analysis
    33→
    34→Gather project context:
    35→
    36→```bash
    37→# Detect project type and tools
    38→ls -la package.json pyproject.toml Cargo.toml go.mod pom.xml 2>/dev/null
    39→cat package.json 2>/dev/null | head -50
    40→
    41→# Check dependencies for MCP server recommendations
    42→cat package.json 2>/dev/null | grep -E '"(react|vue|angular|next|express|fastapi|django|prisma|supabase|stripe)"'
    43→
    44→# Check for existing Claude Code config
    45→ls -la .claude/ CLAUDE.md 2>/dev/null
    46→
    47→# Analyze project structure
    48→ls -la src/ app/ lib/ tests/ components/ pages/ api/ 2>/dev/null
    49→```
    50→
    51→**Key Indicators to Capture:**
    52→
    53→| Category | What to Look For | Informs Recommendations For |
    54→|----------|------------------|----------------------------|
    55→| Language/Framework | package.json, pyproject.toml, import patterns | Hooks, MCP servers |
    56→| Frontend stack | React, Vue, Angular, Next.js | Playwright MCP, frontend skills |
    57→| Backend stack | Express, FastAPI, Django | API documentation tools |
    58→| Database | Prisma, Supabase, raw SQL | Database MCP servers |
    59→| External APIs | Stripe, OpenAI, AWS SDKs | context7 MCP for docs |
    60→| Testing | Jest, pytest, Playwright configs | Testing hooks, subagents |
    61→| CI/CD | GitHub Actions, CircleCI | GitHub MCP server |
    62→| Issue tracking | Linear, Jira references | Issue tracker MCP |
    63→| Docs patterns | OpenAPI, JSDoc, docstrings | Documentation skills |
    64→
    65→### Phase 2: Generate Recommendations
    66→
    67→Based on analysis, generate recommendations across all categories:
    68→
    69→#### A. MCP Server Recommendations
    70→
    71→See [references/mcp-servers.md](references/mcp-servers.md) for detailed patterns.
    72→
    73→| Codebase Signal | Recommended MCP Server |
    74→|-----------------|------------------------|
    75→| Uses popular libraries (React, Express, etc.) | **context7** - Live documentation lookup |
    76→| Frontend with UI testing needs | **Playwright** - Browser automation/testing |
    77→| Uses Supabase | **Supabase MCP** - Direct database operations |
    78→| PostgreSQL/MySQL database | **Database MCP** - Query and schema tools |
    79→| GitHub repository | **GitHub MCP** - Issues, PRs, actions |
    80→| Uses Linear for issues | **Linear MCP** - Issue management |
    81→| AWS infrastructure | **AWS MCP** - Cloud resource management |
    82→| Slack workspace | **Slack MCP** - Team notifications |
    83→| Memory/context persistence | **Memory MCP** - Cross-session memory |
    84→| Sentry error tracking | **Sentry MCP** - Error investigation |
    85→| Docker containers | **Docker MCP** - Container management |
    86→
    87→#### B. Skills Recommendations
    88→
    89→See [references/skills-reference.md](references/skills-reference.md) for details.
    90→
    91→Create skills in `.claude/skills/<name>/SKILL.md`. Some are also available via plugins:
    92→
    93→| Codebase Signal | Skill | Plugin |
    94→|-----------------|-------|--------|
    95→| Building plugins | skill-development | plugin-dev |
    96→| Git commits | commit | commit-commands |
    97→| React/Vue/Angular | frontend-design | frontend-design |
    98→| Automation rules | writing-rules | hookify |
    99→| Feature planning | feature-dev | feature-dev |
   100→
   101→**Custom skills to create** (with templates, scripts, examples):
   102→
   103→| Codebase Signal | Skill to Create | Invocation |
   104→|-----------------|-----------------|------------|
   105→| API routes | **api-doc** (with OpenAPI template) | Both |
   106→| Database project | **create-migration** (with validation script) | User-only |
   107→| Test suite | **gen-test** (with example tests) | User-only |
   108→| Component library | **new-component** (with templates) | User-only |
   109→| PR workflow | **pr-check** (with checklist) | User-only |
   110→| Releases | **release-notes** (with git context) | User-only |
   111→| Code style | **project-conventions** | Claude-only |
   112→| Onboarding | **setup-dev** (with prereq script) | User-only |
   113→
   114→#### C. Hooks Recommendations
   115→
   116→See [references/hooks-patterns.md](references/hooks-patterns.md) for configurations.
   117→
   118→| Codebase Signal | Recommended Hook |
   119→|-----------------|------------------|
   120→| Prettier configured | PostToolUse: auto-format on edit |
   121→| ESLint/Ruff configured | PostToolUse: auto-lint on edit |
   122→| TypeScript project | PostToolUse: type-check on edit |
   123→| Tests directory exists | PostToolUse: run related tests |
   124→| `.env` files present | PreToolUse: block `.env` edits |
   125→| Lock files present | PreToolUse: block lock file edits |
   126→| Security-sensitive code | PreToolUse: require confirmation |
   127→
   128→#### D. Subagent Recommendations
   129→
   130→See [references/subagent-templates.md](references/subagent-templates.md) for templates.
   131→
   132→| Codebase Signal | Recommended Subagent |
   133→|-----------------|---------------------|
   134→| Large codebase (>500 files) | **code-reviewer** - Parallel code review |
   135→| Auth/payments code | **security-reviewer** - Security audits |
   136→| API project | **api-documenter** - OpenAPI generation |
   137→| Performance critical | **performance-analyzer** - Bottleneck detection |
   138→| Frontend heavy | **ui-reviewer** - Accessibility review |
   139→| Needs more tests | **test-writer** - Test generation |
   140→
   141→#### E. Plugin Recommendations
   142→
   143→See [references/plugins-reference.md](references/plugins-reference.md) for available plugins.
   144→
   145→| Codebase Signal | Recommended Plugin |
   146→|-----------------|-------------------|
   147→| General productivity | **anthropic-agent-skills** - Core skills bundle |
   148→| Document workflows | Install docx, xlsx, pdf skills |
   149→| Frontend development | **frontend-design** plugin |
   150→| Building AI tools | **mcp-builder** for MCP development |
   151→
   152→### Phase 3: Output Recommendations Report
   153→
   154→Format recommendations clearly. **Only include 1-2 recommendations per category** - the most valuable ones for this specific codebase. Skip categories that aren't relevant.
   155→
   156→```markdown
   157→## Claude Code Automation Recommendations
   158→
   159→I've analyzed your codebase and identified the top automations for each category. Here are my top 1-2 recommendations per type:
   160→
   161→### Codebase Profile
   162→- **Type**: [detected language/runtime]
   163→- **Framework**: [detected framework]
   164→- **Key Libraries**: [relevant libraries detected]
   165→
   166→---
   167→
   168→### 🔌 MCP Servers
   169→
   170→#### context7
   171→**Why**: [specific reason based on detected libraries]
   172→**Install**: `claude mcp add context7`
   173→
   174→---
   175→
   176→### 🎯 Skills
   177→
   178→#### [skill name]
   179→**Why**: [specific reason]
   180→**Create**: `.claude/skills/[name]/SKILL.md`
   181→**Invocation**: User-only / Both / Claude-only
   182→**Also available in**: [plugin-name] plugin (if applicable)
   183→```yaml
   184→---
   185→name: [skill-name]
   186→description: [what it does]
   187→disable-model-invocation: true  # for user-only
   188→---
   189→```
   190→
   191→---
   192→
   193→### ⚡ Hooks
   194→
   195→#### [hook name]
   196→**Why**: [specific reason based on detected config]
   197→**Where**: `.claude/settings.json`
   198→
   199→---
   200→
   201→### 🤖 Subagents
   202→
   203→#### [agent name]
   204→**Why**: [specific reason based on codebase patterns]
   205→**Where**: `.claude/agents/[name].md`
   206→
   207→---
   208→
   209→**Want more?** Ask for additional recommendations for any specific category (e.g., "show me more MCP server options" or "what other hooks would help?").
   210→
   211→**Want help implementing any of these?** Just ask and I can help you set up any of the recommendations above.
   212→```
   213→
   214→## Decision Framework
   215→
   216→### When to Recommend MCP Servers
   217→- External service integration needed (databases, APIs)
   218→- Documentation lookup for libraries/SDKs
   219→- Browser automation or testing
   220→- Team tool integration (GitHub, Linear, Slack)
   221→- Cloud infrastructure management
   222→
   223→### When to Recommend Skills
   224→
   225→- Document generation (docx, xlsx, pptx, pdf — also in plugins)
   226→- Frequently repeated prompts or workflows
   227→- Project-specific tasks with arguments
   228→- Applying templates or scripts to tasks (skills can bundle supporting files)
   229→- Quick actions invoked with `/skill-name`
   230→- Workflows that should run in isolation (`context: fork`)
   231→
   232→**Invocation control:**
   233→- `disable-model-invocation: true` — User-only (for side effects: deploy, commit, send)
   234→- `user-invocable: false` — Claude-only (for background knowledge)
   235→- Default (omit both) — Both can invoke
   236→
   237→### When to Recommend Hooks
   238→- Repetitive post-edit actions (formatting, linting)
   239→- Protection rules (block sensitive file edits)
   240→- Validation checks (tests, type checks)
   241→
   242→### When to Recommend Subagents
   243→- Specialized expertise needed (security, performance)
   244→- Parallel review workflows
   245→- Background quality checks
   246→
   247→### When to Recommend Plugins
   248→- Need multiple related skills
   249→- Want pre-packaged automation bundles
   250→- Team-wide standardization
   251→
   252→---
   253→
   254→## Configuration Tips
   255→
   256→### MCP Server Setup
   257→
   258→**Team sharing**: Check `.mcp.json` into repo so entire team gets same MCP servers
   259→
   260→**Debugging**: Use `--mcp-debug` flag to identify configuration issues
   261→
   262→**Prerequisites to recommend:**
   263→- GitHub CLI (`gh`) - enables native GitHub operations
   264→- Puppeteer/Playwright CLI - for browser MCP servers
   265→
   266→### Headless Mode (for CI/Automation)
   267→
   268→Recommend headless Claude for automated pipelines:
   269→
   270→```bash
   271→# Pre-commit hook example
   272→claude -p "fix lint errors in src/" --allowedTools Edit,Write
   273→
   274→# CI pipeline with structured output
   275→claude -p "<prompt>" --output-format stream-json | your_command
   276→```
   277→
   278→### Permissions for Hooks
   279→
   280→Configure allowed tools in `.claude/settings.json`:
   281→
   282→```json
   283→{
   284→  "permissions": {
   285→    "allow": ["Edit", "Write", "Bash(npm test:*)", "Bash(git commit:*)"]
   286→  }
   287→}
   288→```
   289→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Let me look at one more skill and command example to see the complete pattern:


     1→---
     2→name: example-skill
     3→description: This skill should be used when the user asks to "demonstrate skills", "show skill format", "create a skill template", or discusses skill development patterns. Provides a reference template for creating Claude Code plugin skills.
     4→version: 1.0.0
     5→---
     6→
     7→# Example Skill
     8→
     9→This skill demonstrates the structure and format for Claude Code plugin skills.
    10→
    11→## Overview
    12→
    13→Skills are model-invoked capabilities that Claude autonomously uses based on task context. Unlike commands (user-invoked) or agents (spawned by Claude), skills provide contextual guidance that Claude incorporates into its responses.
    14→
    15→## When This Skill Applies
    16→
    17→This skill activates when the user's request involves:
    18→- Creating or understanding plugin skills
    19→- Skill template or reference needs
    20→- Skill development patterns
    21→
    22→## Skill Structure
    23→
    24→### Required Files
    25→
    26→```
    27→skills/
    28→└── skill-name/
    29→    └── SKILL.md          # Main skill definition (required)
    30→```
    31→
    32→### Optional Supporting Files
    33→
    34→```
    35→skills/
    36→└── skill-name/
    37→    ├── SKILL.md          # Main skill definition
    38→    ├── README.md         # Additional documentation
    39→    ├── references/       # Reference materials
    40→    │   └── patterns.md
    41→    ├── examples/         # Example files
    42→    │   └── sample.md
    43→    └── scripts/          # Helper scripts
    44→        └── helper.sh
    45→```
    46→
    47→## Frontmatter Options
    48→
    49→Skills support these frontmatter fields:
    50→
    51→- **name** (required): Skill identifier
    52→- **description** (required): Trigger conditions - describe when Claude should use this skill
    53→- **version** (optional): Semantic version number
    54→- **license** (optional): License information or reference
    55→
    56→## Writing Effective Descriptions
    57→
    58→The description field is crucial - it tells Claude when to invoke the skill.
    59→
    60→**Good description patterns:**
    61→```yaml
    62→description: This skill should be used when the user asks to "specific phrase", "another phrase", mentions "keyword", or discusses topic-area.
    63→```
    64→
    65→**Include:**
    66→- Specific trigger phrases users might say
    67→- Keywords that indicate relevance
    68→- Topic areas the skill covers
    69→
    70→## Skill Content Guidelines
    71→
    72→1. **Clear purpose**: State what the skill helps with
    73→2. **When to use**: Define activation conditions
    74→3. **Structured guidance**: Organize information logically
    75→4. **Actionable instructions**: Provide concrete steps
    76→5. **Examples**: Include practical examples when helpful
    77→
    78→## Best Practices
    79→
    80→- Keep skills focused on a single domain
    81→- Write descriptions that clearly indicate when to activate
    82→- Include reference materials in subdirectories for complex skills
    83→- Test that the skill activates for expected queries
    84→- Avoid overlap with other skills' trigger conditions
    85→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→description: Guided feature development with codebase understanding and architecture focus
     3→argument-hint: Optional feature description
     4→---
     5→
     6→# Feature Development
     7→
     8→You are helping a developer implement a new feature. Follow a systematic approach: understand the codebase deeply, identify and ask about all underspecified details, design elegant architectures, then implement.
     9→
    10→## Core Principles
    11→
    12→- **Ask clarifying questions**: Identify all ambiguities, edge cases, and underspecified behaviors. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with implementation. Ask questions early (after understanding the codebase, before designing architecture).
    13→- **Understand before acting**: Read and comprehend existing code patterns first
    14→- **Read files identified by agents**: When launching agents, ask them to return lists of the most important files to read. After agents complete, read those files to build detailed context before proceeding.
    15→- **Simple and elegant**: Prioritize readable, maintainable, architecturally sound code
    16→- **Use TodoWrite**: Track all progress throughout
    17→
    18→---
    19→
    20→## Phase 1: Discovery
    21→
    22→**Goal**: Understand what needs to be built
    23→
    24→Initial request: $ARGUMENTS
    25→
    26→**Actions**:
    27→1. Create todo list with all phases
    28→2. If feature unclear, ask user for:
    29→   - What problem are they solving?
    30→   - What should the feature do?
    31→   - Any constraints or requirements?
    32→3. Summarize understanding and confirm with user
    33→
    34→---
    35→
    36→## Phase 2: Codebase Exploration
    37→
    38→**Goal**: Understand relevant existing code and patterns at both high and low levels
    39→
    40→**Actions**:
    41→1. Launch 2-3 code-explorer agents in parallel. Each agent should:
    42→   - Trace through the code comprehensively and focus on getting a comprehensive understanding of abstractions, architecture and flow of control
    43→   - Target a different aspect of the codebase (eg. similar features, high level understanding, architectural understanding, user experience, etc)
    44→   - Include a list of 5-10 key files to read
    45→
    46→   **Example agent prompts**:
    47→   - "Find features similar to [feature] and trace through their implementation comprehensively"
    48→   - "Map the architecture and abstractions for [feature area], tracing through the code comprehensively"
    49→   - "Analyze the current implementation of [existing feature/area], tracing through the code comprehensively"
    50→   - "Identify UI patterns, testing approaches, or extension points relevant to [feature]"
    51→
    52→2. Once the agents return, please read all files identified by agents to build deep understanding
    53→3. Present comprehensive summary of findings and patterns discovered
    54→
    55→---
    56→
    57→## Phase 3: Clarifying Questions
    58→
    59→**Goal**: Fill in gaps and resolve all ambiguities before designing
    60→
    61→**CRITICAL**: This is one of the most important phases. DO NOT SKIP.
    62→
    63→**Actions**:
    64→1. Review the codebase findings and original feature request
    65→2. Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
    66→3. **Present all questions to the user in a clear, organized list**
    67→4. **Wait for answers before proceeding to architecture design**
    68→
    69→If the user says "whatever you think is best", provide your recommendation and get explicit confirmation.
    70→
    71→---
    72→
    73→## Phase 4: Architecture Design
    74→
    75→**Goal**: Design multiple implementation approaches with different trade-offs
    76→
    77→**Actions**:
    78→1. Launch 2-3 code-architect agents in parallel with different focuses: minimal changes (smallest change, maximum reuse), clean architecture (maintainability, elegant abstractions), or pragmatic balance (speed + quality)
    79→2. Review all approaches and form your opinion on which fits best for this specific task (consider: small fix vs large feature, urgency, complexity, team context)
    80→3. Present to user: brief summary of each approach, trade-offs comparison, **your recommendation with reasoning**, concrete implementation differences
    81→4. **Ask user which approach they prefer**
    82→
    83→---
    84→
    85→## Phase 5: Implementation
    86→
    87→**Goal**: Build the feature
    88→
    89→**DO NOT START WITHOUT USER APPROVAL**
    90→
    91→**Actions**:
    92→1. Wait for explicit user approval
    93→2. Read all relevant files identified in previous phases
    94→3. Implement following chosen architecture
    95→4. Follow codebase conventions strictly
    96→5. Write clean, well-documented code
    97→6. Update todos as you progress
    98→
    99→---
   100→
   101→## Phase 6: Quality Review
   102→
   103→**Goal**: Ensure code is simple, DRY, elegant, easy to read, and functionally correct
   104→
   105→**Actions**:
   106→1. Launch 3 code-reviewer agents in parallel with different focuses: simplicity/DRY/elegance, bugs/functional correctness, project conventions/abstractions
   107→2. Consolidate findings and identify highest severity issues that you recommend fixing
   108→3. **Present findings to user and ask what they want to do** (fix now, fix later, or proceed as-is)
   109→4. Address issues based on user decision
   110→
   111→---
   112→
   113→## Phase 7: Summary
   114→
   115→**Goal**: Document what was accomplished
   116→
   117→**Actions**:
   118→1. Mark all todos complete
   119→2. Summarize:
   120→   - What was built
   121→   - Key decisions made
   122→   - Files modified
   123→   - Suggested next steps
   124→
   125→---
   126→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


     1→---
     2→description: Get help with the hookify plugin
     3→allowed-tools: ["Read"]
     4→---
     5→
     6→# Hookify Plugin Help
     7→
     8→Explain how the hookify plugin works and how to use it.
     9→
    10→## Overview
    11→
    12→The hookify plugin makes it easy to create custom hooks that prevent unwanted behaviors. Instead of editing `hooks.json` files, users create simple markdown configuration files that define patterns to watch for.
    13→
    14→## How It Works
    15→
    16→### 1. Hook System
    17→
    18→Hookify installs generic hooks that run on these events:
    19→- **PreToolUse**: Before any tool executes (Bash, Edit, Write, etc.)
    20→- **PostToolUse**: After a tool executes
    21→- **Stop**: When Claude wants to stop working
    22→- **UserPromptSubmit**: When user submits a prompt
    23→
    24→These hooks read configuration files from `.claude/hookify.*.local.md` and check if any rules match the current operation.
    25→
    26→### 2. Configuration Files
    27→
    28→Users create rules in `.claude/hookify.{rule-name}.local.md` files:
    29→
    30→```markdown
    31→---
    32→name: warn-dangerous-rm
    33→enabled: true
    34→event: bash
    35→pattern: rm\s+-rf
    36→---
    37→
    38→⚠ **Dangerous rm command detected!**
    39→
    40→This command could delete important files. Please verify the path.
    41→```
    42→
    43→**Key fields:**
    44→- `name`: Unique identifier for the rule
    45→- `enabled`: true/false to activate/deactivate
    46→- `event`: bash, file, stop, prompt, or all
    47→- `pattern`: Regex pattern to match
    48→
    49→The message body is what Claude sees when the rule triggers.
    50→
    51→### 3. Creating Rules
    52→
    53→**Option A: Use /hookify command**
    54→```
    55→/hookify Don't use console.log in production files
    56→```
    57→
    58→This analyzes your request and creates the appropriate rule file.
    59→
    60→**Option B: Create manually**
    61→Create `.claude/hookify.my-rule.local.md` with the format above.
    62→
    63→**Option C: Analyze conversation**
    64→```
    65→/hookify
    66→```
    67→
    68→Without arguments, hookify analyzes recent conversation to find behaviors you want to prevent.
    69→
    70→## Available Commands
    71→
    72→- **`/hookify`** - Create hooks from conversation analysis or explicit instructions
    73→- **`/hookify:help`** - Show this help (what you're reading now)
    74→- **`/hookify:list`** - List all configured hooks
    75→- **`/hookify:configure`** - Enable/disable existing hooks interactively
    76→
    77→## Example Use Cases
    78→
    79→**Prevent dangerous commands:**
    80→```markdown
    81→---
    82→name: block-chmod-777
    83→enabled: true
    84→event: bash
    85→pattern: chmod\s+777
    86→---
    87→
    88→Don't use chmod 777 - it's a security risk. Use specific permissions instead.
    89→```
    90→
    91→**Warn about debugging code:**
    92→```markdown
    93→---
    94→name: warn-console-log
    95→enabled: true
    96→event: file
    97→pattern: console\.log\(
    98→---
    99→
   100→Console.log detected. Remember to remove debug logging before committing.
   101→```
   102→
   103→**Require tests before stopping:**
   104→```markdown
   105→---
   106→name: require-tests
   107→enabled: true
   108→event: stop
   109→pattern: .*
   110→---
   111→
   112→Did you run tests before finishing? Make sure `npm test` or equivalent was executed.
   113→```
   114→
   115→## Pattern Syntax
   116→
   117→Use Python regex syntax:
   118→- `\s` - whitespace
   119→- `\.` - literal dot
   120→- `|` - OR
   121→- `+` - one or more
   122→- `*` - zero or more
   123→- `\d` - digit
   124→- `[abc]` - character class
   125→
   126→**Examples:**
   127→- `rm\s+-rf` - matches "rm -rf"
   128→- `console\.log\(` - matches "console.log("
   129→- `(eval|exec)\(` - matches "eval(" or "exec("
   130→- `\.env$` - matches files ending in .env
   131→
   132→## Important Notes
   133→
   134→**No Restart Needed**: Hookify rules (`.local.md` files) take effect immediately on the next tool use. The hookify hooks are already loaded and read your rules dynamically.
   135→
   136→**Block or Warn**: Rules can either `block` operations (prevent execution) or `warn` (show message but allow). Set `action: block` or `action: warn` in the rule's frontmatter.
   137→
   138→**Rule Files**: Keep rules in `.claude/hookify.*.local.md` - they should be git-ignored (add to .gitignore if needed).
   139→
   140→**Disable Rules**: Set `enabled: false` in frontmatter or delete the file.
   141→
   142→## Troubleshooting
   143→
   144→**Hook not triggering:**
   145→- Check rule file is in `.claude/` directory
   146→- Verify `enabled: true` in frontmatter
   147→- Confirm pattern is valid regex
   148→- Test pattern: `python3 -c "import re; print(re.search('your_pattern', 'test_text'))"`
   149→- Rules take effect immediately - no restart needed
   150→
   151→**Import errors:**
   152→- Check Python 3 is available: `python3 --version`
   153→- Verify hookify plugin is installed correctly
   154→
   155→**Pattern not matching:**
   156→- Test regex separately
   157→- Check for escaping issues (use unquoted patterns in YAML)
   158→- Try simpler pattern first, then refine
   159→
   160→## Getting Started
   161→
   162→1. Create your first rule:
   163→   ```
   164→   /hookify Warn me when I try to use rm -rf
   165→   ```
   166→
   167→2. Try to trigger it:
   168→   - Ask Claude to run `rm -rf /tmp/test`
   169→   - You should see the warning
   170→
   171→4. Refine the rule by editing `.claude/hookify.warn-rm.local.md`
   172→
   173→5. Create more rules as you encounter unwanted behaviors
   174→
   175→For more examples, check the `${CLAUDE_PLUGIN_ROOT}/examples/` directory.
   176→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


Now let me check the plugin and command structure more:


List example plugin structure


find /root/.claude/plugins/marketplaces/claude-plugins-official/plugins/example-plugin -type f | head -20

Find all files in example plugin


     1→{
     2→  "name": "example-plugin",
     3→  "description": "A comprehensive example plugin demonstrating all Claude Code extension options including commands, agents, skills, hooks, and MCP servers",
     4→  "author": {
     5→    "name": "Anthropic",
     6→    "email": "support@anthropic.com"
     7→  }
     8→}
     9→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>


总计 24
drwxr-xr-x  5 root root   107  2月27日 09:34 .
drwxr-xr-x 31 root root  4096  2月27日 09:34 ..
drwxr-xr-x  2 root root    25  2月27日 09:34 .claude-plugin
drwxr-xr-x  2 root root    32  2月27日 09:34 commands
-rw-r--r--  1 root root 11358  2月27日 09:34 LICENSE
-rw-r--r--  1 root root    91  2月27日 09:34 .mcp.json
-rw-r--r--  1 root root  1311  2月27日 09:34 README.md
drwxr-xr-x  3 root root    27  2月27日 09:34 skills


Perfect! Now I have comprehensive understanding. Let me compile the findings.

## Summary: How Claude Code Skills and Commands Are Defined

Based on my search through the Claude Code system, here's how skills and commands are defined:

### **FILE LOCATIONS FOUND**

**Project-level:**
- `/root/projects/ai_usecases_explorer/.claude/settings.local.json` - Project-level permissions

**User-level:**
- `/root/.claude/` - Main user configuration directory
- `/root/.claude/plugins/` - Plugin registry with official marketplace
- `/root/.claude/plugins/marketplaces/claude-plugins-official/` - Official plugins

### **DIRECTORY STRUCTURE**

Commands are stored in: `.claude/commands/*.md` or `plugins/*/commands/*.md`
Skills are stored in: `.claude/skills/*/SKILL.md` or `plugins/*/skills/*/SKILL.md`

```
plugins/example-plugin/
├── .claude-plugin/
│   └── plugin.json        # Plugin metadata
├── commands/
│   └── example-command.md # Slash commands
├── skills/
│   └── example-skill/
│       └── SKILL.md       # Skill definition
├── README.md
└── LICENSE
```

---

### **COMMAND FORMAT** (slash commands like `/commit`, `/hookify`)

File: `commands/command-name.md`

```markdown
---
description: Short description shown in /help
argument-hint: <required-arg> [optional-arg]
allowed-tools: [Read, Glob, Grep, Bash, Edit, Write]
model: haiku  # optional, override model
disable-model-invocation: false  # optional
---

# Command Title

Instructions for Claude when this command is invoked.

The user provided these arguments: $ARGUMENTS

1. Parse arguments
2. Perform actions using allowed tools
3. Report results
```

**Key fields:**
- `description`: What the command does (shown in `/help`)
- `argument-hint`: Hints for user input (e.g., `[error_code or message]`)
- `allowed-tools`: Pre-approved tools (reduces permission prompts)
- `model`: Override default model (e.g., "haiku", "sonnet", "opus")
- `disable-model-invocation`: Set to `true` for user-only commands with side effects (deploy, commit, send)
- `$ARGUMENTS`: Variable containing user's arguments to the command

**Examples found:**
- `/commit` - git commit orchestration
- `/hookify` - create custom hooks
- `/code-review` - PR code review
- `/feature-dev` - guided feature development

---

### **SKILL FORMAT** (model-invoked capabilities)

File: `.claude/skills/skill-name/SKILL.md` or `plugins/*/skills/*/SKILL.md`

```markdown
---
name: skill-name
description: Detailed description of when Claude should use this skill
version: 1.0.0  # optional
license: MIT  # optional
user-invocable: false  # optional, Claude-only if true
disable-model-invocation: true  # optional, user-only if true
tools: Read, Glob, Grep, Bash  # optional, allowed tools
---

# Skill Title

## When This Skill Applies

This skill activates when the user:
- Asks to do X
- Mentions keyword Y
- Discusses topic Z

## Guidance

Detailed instructions for Claude on how to handle requests matching the description above.

Can include reference files, examples, patterns, etc.
```

**Key fields:**
- `name`: Skill identifier (e.g., `stripe-best-practices`)
- `description`: **Critical** - tells Claude WHEN to invoke the skill. Should include trigger phrases and keywords
- `version`: Semantic version (optional)
- `tools`: Allowed tools for this skill (optional)
- `user-invocable`: If `false`, Claude-only (for background knowledge)
- `disable-model-invocation`: If `true`, user-only (for side effects: deploy, commit)

**Examples found:**
- `stripe-best-practices` - Stripe integration guidance
- `claude-automation-recommender` - MCP/hook/skill recommendations
- `frontend-design` - Frontend development patterns

---

### **PLUGIN STRUCTURE**

File: `.claude-plugin/plugin.json`

```json
{
  "name": "plugin-name",
  "description": "What this plugin provides",
  "author": {
    "name": "Author Name",
    "email": "email@example.com"
  }
}
```

A plugin bundles:
- Multiple commands in `commands/`
- Multiple skills in `skills/`
- Optional MCP servers in `.mcp.json`
- README and LICENSE

---

### **PARAMETER VARIABLES**

Commands and skills can use these variables:

| Variable | Context | Example |
|----------|---------|---------|
| `$ARGUMENTS` | User's arguments to slash command | User runs `/example-command arg1 arg2` → `$ARGUMENTS="arg1 arg2"` |
| `$CLAUDE_PLUGIN_ROOT` | Path to plugin directory | Reference examples: `${CLAUDE_PLUGIN_ROOT}/examples/` |

Git context variables in commands:
- `` !`git status` `` - Executes and embeds output
- `` !`git diff HEAD` `` - Staged and unstaged diffs
- `` !`git branch --show-current` `` - Current branch
- `` !`git log --oneline -10` `` - Recent commits

---

### **KEY ARCHITECTURAL PATTERNS**

1. **Skills are model-invoked**: Claude autonomously uses them based on task context
2. **Commands are user-invoked**: Users call with `/command-name`
3. **Description triggers skill activation**: The description field determines WHEN Claude uses a skill (not the name)
4. **Frontmatter controls permissions**: `allowed-tools` pre-approves actions
5. **Context embedding**: Commands can embed git/system output with `!`command`` backticks
6. **Model override**: Both can specify which Claude model to use

---

### **FILES FOUND IN SYSTEM**

All absolute paths to example implementations:

- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/example-plugin/commands/example-command.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/example-plugin/skills/example-skill/SKILL.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/commit-commands/commands/commit.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/external_plugins/stripe/commands/explain-error.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/external_plugins/stripe/skills/stripe-best-practices/SKILL.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/code-review/commands/code-review.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/feature-dev/commands/feature-dev.md`
- `/root/.claude/plugins/marketplaces/claude-plugins-official/plugins/hookify/commands/help.md`