# Claude Code Community Plugins & Examples — User Guide

## 1. Quick Start

Claude Code Community Plugins & Examples is the official collection of community-contributed plugins, hooks, settings presets, and example code for extending Claude Code. It provides ready-to-use plugins for code review, PR analysis, security guidance, commit workflows, feature development, and plugin authoring — plus examples showing how to build your own hooks, configure managed settings, and set up DevContainer environments.

**Key features:**

- 15 community plugins covering code review, security, commits, PR review, feature development, and more
- Hookify rule engine for creating custom hooks from simple markdown files
- Security guidance hooks that detect common vulnerability patterns in real time
- Settings presets for strict, lax, and sandbox configurations
- MDM (managed device management) templates for macOS and Windows enterprise deployment
- Plugin development toolkit with skills for every plugin component type
- DevContainer integration script for Docker and Podman backends

**Prerequisites:** Claude Code installed and accessible via the `claude` command.

**Install a plugin (example — security-guidance):**

```bash
claude plugins add anthropics/claude-code/plugins/security-guidance
```

> [!TIP]
> Browse the `plugins/` directory in the repository to see all available plugins. Each plugin has its own `README.md` with usage instructions.

**What to try next:**

- Install the `hookify` plugin to create custom rules from markdown
- Review the settings presets in `examples/settings/` to lock down or relax permissions
- Read the "Core Usage" section below for a tour of every plugin

## 2. Installation

### System Requirements

| Requirement | Detail |
|---|---|
| Claude Code | Latest version with plugin support |
| Python | 3.x (required by hookify, security-guidance hooks) |
| jq | Recommended for hook scripts that parse JSON input |
| Git | For cloning the repository |
| Docker or Podman | Only if using the DevContainer script |

### Installing Plugins

Plugins live in the `plugins/` directory. Each plugin is self-contained with its own commands, agents, skills, and hooks.

**From the repository:**

```bash
git clone https://github.com/anthropics/claude-code.git
cd claude-code
```

To use a plugin, register it with Claude Code by pointing to its directory. Each plugin contains a standard structure that Claude Code auto-discovers:

```text
plugin-name/
├── README.md
├── commands/          # Slash commands
├── agents/            # Specialized agents
├── skills/            # Knowledge packs
├── hooks/             # Event hooks (hooks.json + scripts)
└── scripts/           # Utility scripts
```

> [!IMPORTANT]
> Hook scripts must be executable. On Unix-like systems, run `chmod +x` on any `.sh` or `.py` hook script before use.

### Post-Install Verification

Confirm a plugin's hooks are active by running Claude Code in debug mode:

```bash
claude --debug
```

Check that the plugin's commands appear in the help output:

```bash
# Inside a Claude Code session
/help
```

```text
Available commands should list any plugin-provided slash commands
```

### Install Troubleshooting

**Plugin commands not appearing:**

- Verify the plugin directory contains a valid structure (at minimum, a `commands/` directory with `.md` files)
- Check that Claude Code is running from the project directory where the plugin is registered

**Hook script not executing:**

- Ensure the script has a shebang line (`#!/bin/bash` or `#!/usr/bin/env python3`)
- Ensure the script is executable (`chmod +x script.sh`)
- Verify the path in `hooks.json` is correct — use `${CLAUDE_PLUGIN_ROOT}` for plugin-relative paths

**Permission denied errors:**

- On macOS/Linux: `chmod +x plugins/*/hooks/*.sh plugins/*/hooks/*.py`
- On Windows: Python hooks (`.py`) work directly; bash hooks require WSL or Git Bash

## 3. Configuration

### Settings Presets

The repository includes three settings presets in `examples/settings/` that demonstrate different security postures. Copy one to your Claude Code settings location to apply it.

| Preset | File | Description |
|---|---|---|
| Bash Sandbox | `settings-bash-sandbox.json` | Enables sandboxing, disables bypass permissions, restricts all bash commands |
| Strict | `settings-strict.json` | Denies web tools, forces ask-mode for Bash, enables managed hooks/permissions only |
| Lax | `settings-lax.json` | Disables bypass permissions mode with no other restrictions |

**Bash Sandbox preset** (`examples/settings/settings-bash-sandbox.json`):

```json
{
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false,
    "allowUnsandboxedCommands": false,
    "excludedCommands": [],
    "network": {
      "allowUnixSockets": [],
      "allowAllUnixSockets": false,
      "allowLocalBinding": false,
      "allowedDomains": [],
      "httpProxyPort": null,
      "socksProxyPort": null
    },
    "enableWeakerNestedSandbox": false
  }
}
```

**Strict preset** (`examples/settings/settings-strict.json`):

```json
{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "ask": ["Bash"],
    "deny": ["WebSearch", "WebFetch"]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "strictKnownMarketplaces": []
}
```

> [!WARNING]
> The `allowManagedPermissionRulesOnly` and `allowManagedHooksOnly` settings prevent users from adding their own permission rules or hooks. Use these only when you need centralized control (e.g., enterprise MDM deployment).

**MDM managed settings** (`examples/mdm/managed-settings.json`):

```json
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}
```

For full configuration reference, see the Admin Guide.

### Hook Configuration

Hooks are configured via `hooks.json` files inside each plugin's `hooks/` directory. The JSON structure specifies which events trigger which scripts:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ${CLAUDE_PLUGIN_ROOT}/hooks/my_hook.py"
          }
        ]
      }
    ]
  }
}
```

**Supported hook events:**

| Event | When It Fires | Common Use |
|---|---|---|
| `PreToolUse` | Before a tool executes | Validate commands, block dangerous operations |
| `PostToolUse` | After a tool executes | Log actions, post-processing |
| `Stop` | When Claude stops | Enforce workflows (e.g., require push before stop) |
| `SessionStart` | When a session begins | Load project context, set environment variables |
| `UserPromptSubmit` | When user submits a prompt | Input validation, preprocessing |

### Environment Variables

| Variable | Default | Description |
|---|---|---|
| `ENABLE_SECURITY_REMINDER` | `1` | Set to `0` to disable security-guidance hook warnings |
| `CLAUDE_PLUGIN_ROOT` | (set by Claude Code) | Absolute path to the plugin's root directory |
| `CLAUDE_PROJECT_DIR` | (set by Claude Code) | Absolute path to the current project directory |
| `CLAUDE_ENV_FILE` | (set by Claude Code) | Path to the environment file for persisting variables across hook invocations |

## 4. Core Usage

### Available Plugins

#### Hookify

A rule engine that lets you create custom hooks from simple markdown files. Instead of writing Python or bash scripts, write rules as `.claude/hookify.*.local.md` files with YAML frontmatter.

**Rule file format:**

```markdown
---
name: dangerous-rm
enabled: true
event: bash
action: block
conditions:
  - field: command
    operator: regex_match
    pattern: "rm\\s+-rf"
---

⚠️ Dangerous `rm -rf` command detected! This could delete important files.
```

**Slash commands provided:**

| Command | Description |
|---|---|
| `/hookify` | Main command — create, manage, and test rules |
| `/hookify:configure` | Configure hookify settings |
| `/hookify:list` | List all active rules |
| `/hookify:help` | Show hookify usage help |

**Supported event types:** `bash`, `file`, `stop`, `all`

**Supported condition operators:**

| Operator | Description |
|---|---|
| `regex_match` | Match field value against a regex pattern (case-insensitive) |
| `contains` | Check if field value contains a substring |
| `equals` | Exact string match |
| `not_contains` | Check that field value does NOT contain a substring |
| `starts_with` | Check if field value starts with a string |
| `ends_with` | Check if field value ends with a string |

**Supported condition fields:**

| Field | Available For | Description |
|---|---|---|
| `command` | Bash tool | The bash command being executed |
| `file_path` | Write/Edit tools | Path of the file being modified |
| `new_text` / `new_string` | Edit tool | The replacement text |
| `old_text` / `old_string` | Edit tool | The original text being replaced |
| `content` | Write tool | The file content being written |
| `reason` | Stop events | The reason Claude is stopping |
| `transcript` | Stop events | Full session transcript (reads from file) |
| `user_prompt` | UserPromptSubmit | The user's input text |

**Actions:** `warn` (show message, allow operation) or `block` (show message, deny operation).

> [!TIP]
> Start with `action: warn` while developing rules. Switch to `block` once you've confirmed the rule matches correctly.

#### Security Guidance

A `PreToolUse` hook that scans file edits for common security anti-patterns and warns about them. Triggers on `Edit`, `Write`, and `MultiEdit` tool calls.

**Detected patterns:**

| Pattern | Trigger | Risk |
|---|---|---|
| GitHub Actions workflow injection | Editing `.github/workflows/*.yml` | Command injection via untrusted event data |
| `child_process.exec()` | Content contains `exec(`, `execSync(` | Shell injection |
| `new Function()` | Content contains `new Function` | Code injection |
| `eval()` | Content contains `eval(` | Arbitrary code execution |
| `dangerouslySetInnerHTML` | Content contains the string | XSS vulnerability |
| `document.write()` | Content contains `document.write` | XSS vulnerability |
| `.innerHTML =` | Content contains `.innerHTML =` | XSS vulnerability |
| `pickle` | Content contains `pickle` | Arbitrary code execution via deserialization |
| `os.system` | Content contains `os.system` | Command injection |

Warnings are session-scoped — each pattern fires only once per file per session. State files are automatically cleaned up after 30 days.

#### Code Review

Provides a `/code-review` slash command for reviewing code quality and potential bugs.

#### PR Review Toolkit

A comprehensive PR review suite with six specialized agents:

| Agent | Role |
|---|---|
| `code-reviewer` | General code quality review |
| `code-simplifier` | Identifies simplification opportunities |
| `comment-analyzer` | Analyzes PR comments |
| `pr-test-analyzer` | Reviews test coverage |
| `silent-failure-hunter` | Finds silent failure paths |
| `type-design-analyzer` | Reviews type system design |

**Command:** `/review-pr` — orchestrates the agents for a thorough PR review.

#### Commit Commands

Git workflow commands:

| Command | Description |
|---|---|
| `/commit` | Create a commit with a generated message |
| `/commit-push-pr` | Commit, push, and create a PR in one step |
| `/clean_gone` | Clean up local branches whose remote tracking branch is gone |

#### Feature Development

A structured feature development workflow with three agents:

| Agent | Role |
|---|---|
| `code-architect` | Plans architecture and component design |
| `code-explorer` | Explores existing codebase for context |
| `code-reviewer` | Reviews implementation quality |

**Command:** `/feature-dev` — guides you through feature planning and implementation.

#### Plugin Development (plugin-dev)

A meta-plugin for building other plugins. Provides comprehensive skills covering every aspect of plugin development:

| Skill | Coverage |
|---|---|
| Plugin Structure | Directory layout, `plugin.json` manifest, component organization |
| Command Development | Slash command format, frontmatter, arguments, bash execution |
| Hook Development | Hook scripts, events, exit codes, JSON output |
| Skill Development | SKILL.md format, progressive disclosure, references |
| Agent Development | Agent markdown format, system prompts, triggering |
| MCP Integration | stdio, SSE, and HTTP server configuration |
| Plugin Settings | Settings files, frontmatter parsing, settings-driven hooks |

**Commands:** `/create-plugin` — scaffolds a new plugin with the standard directory structure.

**Agents:** `agent-creator`, `plugin-validator`, `skill-reviewer`.

#### Agent SDK Dev

Provides `/new-sdk-app` command for scaffolding new applications using the Claude Agent SDK. Includes verifier agents for both Python and TypeScript implementations.

#### Ralph Wiggum

A looping task automation plugin:

| Command | Description |
|---|---|
| `/ralph-loop` | Start a recurring task loop |
| `/cancel-ralph` | Cancel an active loop |
| `/ralph-wiggum:help` | Show usage help |

#### Output Style Plugins

Two plugins that modify Claude's output style via `SessionStart` hooks:

- **explanatory-output-style** — Sets Claude to explain reasoning and decisions in detail
- **learning-output-style** — Sets Claude to a teaching-oriented response style

#### Claude Opus 4.5 Migration

A skill pack for migrating codebases from older Claude model versions to Claude Opus 4.5, with migration references and prompt snippets.

#### Frontend Design

Provides a skill for frontend design guidance and best practices.

### Using Hook Examples

The `examples/hooks/` directory contains a ready-to-use bash command validator:

```python
# examples/hooks/bash_command_validator_example.py
# Intercepts Bash tool calls and suggests better alternatives:
# - grep → rg (ripgrep)
# - find -name → rg --files -g pattern
```

**To use it**, add this to your Claude Code hooks configuration:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /path/to/claude-code/examples/hooks/bash_command_validator_example.py"
          }
        ]
      }
    ]
  }
}
```

> [!NOTE]
> Replace `/path/to/claude-code/` with the actual path to your clone of the repository.

### Using the DevContainer Script

The `Script/run_devcontainer_claude_code.ps1` PowerShell script automates DevContainer setup on Windows with Docker or Podman.

```powershell
# Using Docker
.\Script\run_devcontainer_claude_code.ps1 -Backend docker

# Using Podman
.\Script\run_devcontainer_claude_code.ps1 -Backend podman
```

The script:

1. Checks that the backend (`docker` or `podman`) and `devcontainer` CLI are installed
2. For Podman: initializes and starts a `claudeVM` machine, sets it as default connection
3. For Docker: verifies Docker Desktop is running
4. Runs `devcontainer up --workspace-folder .`
5. Finds the container ID by label matching the current directory
6. Executes `claude` inside the container and drops into an interactive `zsh` shell

> [!IMPORTANT]
> Run this script from your project root directory. The script expects a `.devcontainer/` directory to exist in the project.

## 5. Common Tasks

### Create a Custom Hookify Rule

**Goal:** Block `rm -rf` commands with a warning message.

1. Create a rule file:

```bash
touch .claude/hookify.dangerous-rm.local.md
```

2. Add the rule content:

```markdown
---
name: dangerous-rm
enabled: true
event: bash
action: block
conditions:
  - field: command
    operator: regex_match
    pattern: "rm\\s+-(rf|fr)"
---

⚠️ **Dangerous delete command detected!**

The `rm -rf` command can permanently delete files. Consider using a safer alternative or double-checking the target path.
```

3. Verify the rule loads:

```bash
# In a Claude Code session, try running a matching command
# The hook should block it and display the warning message
```

### Create a Custom Hookify Rule for Sensitive File Protection

**Goal:** Warn when editing `.env` or credential files.

```markdown
---
name: sensitive-files
enabled: true
event: file
action: warn
tool_matcher: "Edit|Write"
conditions:
  - field: file_path
    operator: regex_match
    pattern: "\\.(env|secret|credentials|pem|key)$"
---

⚠️ **Sensitive file detected!**

You are editing a file that may contain secrets or credentials. Ensure you:
- Do not commit this file to version control
- Use environment variables instead of hardcoded values
- Review the changes carefully before saving
```

### Apply the Strict Settings Preset

**Goal:** Lock down Claude Code with the strictest available preset.

1. Copy the preset to your project:

```bash
cp examples/settings/settings-strict.json .claude/settings.json
```

2. The settings take effect on the next Claude Code session. Bash commands will require explicit approval, and web tools (`WebSearch`, `WebFetch`) will be denied entirely.

### Use the Security Guidance Plugin

**Goal:** Get automatic security warnings when editing code.

1. Install the plugin from `plugins/security-guidance`
2. The hook activates automatically on `Edit`, `Write`, and `MultiEdit` operations
3. When you edit a file containing patterns like `eval(`, `innerHTML =`, or a GitHub Actions workflow, the hook will display a security warning and block the first occurrence per session

**Disable for a session:**

```bash
export ENABLE_SECURITY_REMINDER=0
```

### Set Up a PR Review Workflow

**Goal:** Run a comprehensive review of a pull request.

1. Install the `pr-review-toolkit` plugin
2. In a Claude Code session with the target repository:

```text
/review-pr 123
```

This dispatches six specialized agents (code reviewer, simplifier, comment analyzer, test analyzer, silent failure hunter, type design analyzer) to review PR #123.

### Create a New Plugin

**Goal:** Scaffold a new plugin from scratch.

1. Install the `plugin-dev` plugin
2. Run the create command:

```text
/create-plugin
```

3. Follow the prompts to set up your plugin's name, components, and structure

The scaffolded plugin will include the standard directory layout with placeholder files for commands, hooks, and skills.

> [!TIP]
> Use the plugin-dev skills (hook-development, command-development, etc.) as reference guides while building your plugin. Each skill includes detailed examples and best practices.

### Write a PreToolUse Hook Script

**Goal:** Create a hook that validates file write operations.

1. Create the hook script (`validate-write.sh`):

```bash
#!/bin/bash
set -euo pipefail

input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')

if [ -z "$file_path" ]; then
  exit 0  # No path to validate — allow
fi

# Block path traversal
if [[ "$file_path" == *".."* ]]; then
  echo '{"hookSpecificOutput": {"permissionDecision": "deny"}, "systemMessage": "Path traversal detected"}' >&2
  exit 2
fi

# Block system directories
if [[ "$file_path" == /etc/* ]] || [[ "$file_path" == /sys/* ]]; then
  echo '{"hookSpecificOutput": {"permissionDecision": "deny"}, "systemMessage": "Cannot write to system directory"}' >&2
  exit 2
fi

exit 0
```

2. Make it executable: `chmod +x validate-write.sh`

3. Register it in your `hooks.json`:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/validate-write.sh"
          }
        ]
      }
    ]
  }
}
```

**Hook exit codes:**

| Exit Code | Meaning |
|---|---|
| `0` | Allow the operation |
| `1` | Error (stderr shown to user, not to Claude) |
| `2` | Block/modify (stderr shown to Claude as system message) |

### Lint a Hook Script

**Goal:** Check a hook script for common issues before deployment.

```bash
cd plugins/plugin-dev/skills/hook-development/scripts
./hook-linter.sh /path/to/your-hook.sh
```

```text
🔎 Hook Script Linter
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔍 Linting: /path/to/your-hook.sh

⚠️  Missing 'set -euo pipefail' (recommended for safety)
⚠️  No explicit exit codes (should exit 0 or 2)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️  Found 2 warning(s)
```

The linter checks for: shebang presence, `set -euo pipefail`, stdin reading, JSON parsing with `jq`, unquoted variables, hardcoded paths, exit codes, long-running operations, stderr usage, and input validation.

### Test a Hook Script

**Goal:** Test a hook with sample input before deploying.

```bash
cd plugins/plugin-dev/skills/hook-development/scripts

# Generate sample input for a PreToolUse event
./test-hook.sh --create-sample PreToolUse > test-input.json

# Run the hook with the sample input
./test-hook.sh -v /path/to/your-hook.sh test-input.json
```

### Configure MCP Servers in a Plugin

Three transport types are supported for MCP server integration:

**stdio** (local process):

```json
{
  "filesystem": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "${CLAUDE_PROJECT_DIR}"],
    "env": {
      "LOG_LEVEL": "info"
    }
  }
}
```

**SSE** (hosted cloud service):

```json
{
  "github": {
    "type": "sse",
    "url": "https://mcp.github.com/sse"
  }
}
```

**HTTP** (REST API):

```json
{
  "rest-api": {
    "type": "http",
    "url": "https://api.example.com/mcp",
    "headers": {
      "Authorization": "Bearer ${API_TOKEN}"
    }
  }
}
```

> [!NOTE]
> Use environment variable references (`${VAR_NAME}`) in MCP configurations to avoid hardcoding secrets.

## 6. Troubleshooting

### Error: Hook script exits with code 1 but no output appears

**Cause:** Exit code 1 sends stderr output to the user but NOT to Claude. If there's no `print(..., file=sys.stderr)` or `echo ... >&2` before the exit, nothing is shown.

**Solution:**

1. Add error output before exiting:

```bash
echo "Error: description of what went wrong" >&2
exit 1
```

2. For Python hooks:

```python
print("Error: description", file=sys.stderr)
sys.exit(1)
```

**Prevention:** Always write diagnostic messages to stderr before non-zero exit codes.

### Error: Hook blocks operation but Claude doesn't see the reason

**Cause:** The blocking message must be written to stderr (not stdout) when using exit code 2. The JSON structure must include `systemMessage` for Claude to see it.

**Solution:**

```bash
echo '{"hookSpecificOutput": {"permissionDecision": "deny"}, "systemMessage": "Reason for blocking"}' >&2
exit 2
```

**Prevention:** Always use `>&2` for hook output and include a `systemMessage` field.

### Error: Hookify rule doesn't match expected commands

**Cause:** Regex patterns in YAML frontmatter may need double-escaping. A single backslash (`\s`) in YAML is interpreted as a literal `s`.

**Solution:**

Use double backslashes in patterns:

```yaml
pattern: "rm\\s+-rf"  # Correct — matches "rm -rf"
```

Not:

```yaml
pattern: "rm\s+-rf"   # Wrong — \s becomes literal "s"
```

**Prevention:** Test regex patterns with the hookify `/hookify:list` command to verify they parse correctly.

### Error: Security guidance hook fires repeatedly for the same file

**Cause:** State file corruption or missing session ID. The hook uses session-scoped state files at `~/.claude/security_warnings_state_{session_id}.json`.

**Solution:**

1. Remove stale state files:

```bash
rm ~/.claude/security_warnings_state_*.json
```

2. The hook auto-cleans state files older than 30 days (10% chance per invocation).

### Error: DevContainer script fails to find container ID

**Cause:** The `devcontainer up` command may have failed silently, or the container label doesn't match the current directory path.

**Solution:**

1. Verify the container is running:

```bash
docker ps --filter "label=devcontainer.local_folder"
```

2. Check that you're running the script from the project root (the directory containing `.devcontainer/`)

3. Try running `devcontainer up --workspace-folder .` manually to see detailed error output

**Prevention:** Always run the script from the project root directory.

### Error: `jq` not found when running hook scripts

**Cause:** Many hook examples use `jq` for JSON parsing, but it may not be installed.

**Solution:**

=== "macOS"
    ```bash
    brew install jq
    ```

=== "Ubuntu/Debian"
    ```bash
    sudo apt-get install jq
    ```

=== "Windows"
    ```bash
    choco install jq
    ```

### Cowork tab not showing on Windows 11 (GitHub issue #50495)

**Cause:** Known issue where the Cowork tab is completely absent from navigation on Windows 11 Pro x64.

**Solution:** Check for Claude Code updates. This is a tracked issue in the upstream repository.

### Auto-Compact triggers prematurely (GitHub issue #50492)

**Cause:** Auto-compact may trigger at low token usage percentages (e.g., 24%) instead of waiting until the context window is nearly full.

**Solution:** This is a known upstream issue. No workaround is available from this plugin repository.

### WSL1 compatibility broken in Claude Code 2.1.83+ (GitHub issue #38788)

**Cause:** Claude Code versions 2.1.83 and above have known compatibility issues with WSL1.

**Solution:** Use WSL2 instead of WSL1, or pin to Claude Code version 2.1.82 or earlier.

> [!WARNING]
> Plugin hooks that use bash scripts require a Unix-like shell environment. On Windows, use WSL2 or Git Bash.

### MCP OAuth flow redirects incorrectly (GitHub issue #48101)

**Cause:** MCP Google Drive OAuth flow redirects to claude.ai web instead of completing in the CLI.

**Solution:** This is a known upstream issue. Check for updates to the MCP integration.

## 7. FAQ

**Q: What is the difference between a plugin command, agent, skill, and hook?**

- **Command**: A slash command (`/command-name`) — a markdown file with an optional YAML frontmatter that defines a prompt template. Users invoke it directly.
- **Agent**: A specialized sub-agent defined in markdown that Claude can spawn for complex tasks. Agents have their own system prompts and tool access.
- **Skill**: A knowledge pack (SKILL.md) that Claude loads automatically when relevant. Skills use progressive disclosure — core content loads first, references and examples load on demand.
- **Hook**: A script (bash/Python) that runs automatically on specific events (PreToolUse, Stop, etc.). Hooks can allow, block, or modify operations.

**Q: Can I use multiple plugins simultaneously?**

Yes. Plugins are independent and can be composed. If multiple plugins register hooks for the same event, all hooks run. If any hook blocks an operation (exit code 2), the operation is blocked.

**Q: Where do hookify rule files go?**

Rule files go in your project's `.claude/` directory with the naming pattern `hookify.{rule-name}.local.md`. The `local` suffix indicates these are local/personal rules not committed to version control.

**Q: How do I disable a hookify rule without deleting it?**

Set `enabled: false` in the rule's YAML frontmatter:

```yaml
---
name: my-rule
enabled: false
event: bash
---
```

**Q: What's the difference between the settings presets?**

- **Lax** (`settings-lax.json`): Only disables bypass permissions mode. Minimal restrictions.
- **Bash Sandbox** (`settings-bash-sandbox.json`): Full sandboxing with no network access, no unsandboxed commands, managed permissions only.
- **Strict** (`settings-strict.json`): Denies web tools, forces ask-mode for Bash, requires managed hooks and permissions only.

**Q: Can I use the security-guidance hook with custom patterns?**

The security-guidance hook has a fixed set of 9 patterns compiled into the Python script. To add custom patterns, either modify `security_reminder_hook.py` directly or use the hookify plugin to create complementary rules without editing the security-guidance code.

**Q: How do hook exit codes work?**

| Exit Code | Effect |
|---|---|
| `0` | Allow — operation proceeds normally |
| `1` | Error — stderr shown to user (not Claude), operation proceeds |
| `2` | Block — stderr shown to Claude as system message, operation blocked/modified |

**Q: Does the DevContainer script work on macOS or Linux?**

No. `run_devcontainer_claude_code.ps1` is a PowerShell script designed for Windows. On macOS/Linux, use the `devcontainer` CLI directly:

```bash
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . claude
```

**Q: How do I contribute a new plugin?**

Follow the standard plugin structure (see the plugin-dev skill for guidance), create a `README.md` for your plugin, and submit a pull request to the `anthropics/claude-code` repository. See the repository's contribution guidelines for details.

---

_Generated May 2026 from anthropics/claude-code at fb063cd. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial; not affiliated with or reviewed by the project._