Project Plugin Settings Pattern
Store and read configurable Claude Code plugin settings in project-local Markdown files.
The material documents local user-managed files, gitignore usage, permission guidance, input sanitization, path-traversal checks, and atomic updates, while one example includes user confirmation. However, confirmation, permissions, rollback, and sensitive-data handling are not enforced consistently; some examples feed user-controlled body content back to Claude or send it through tmux, with limited disclosure of data flow and external effects. Points are deducted for these gaps.
The skill supplies Bash examples, defaults, partial validation, and some diagnostic messages, so the main simple path is plausible on static inspection. Dependencies such as jq, yq, and tmux are not consistently declared; sed/grep parsing is not full YAML parsing; missing fields can fail under set -e; and the validator may accept non-strict YAML-like content. No key-path tests are provided, so the score is kept below the static ceiling.
Triggers, naming, configuration purposes, and several hooks/commands/agents scenarios are clearly described. Boundaries remain incomplete: non-fit cases, Claude Code version assumptions, working-directory behavior, complex YAML limits, and Chinese-language support are not specified. Mainland-China network reachability is not discussed, although the core pattern is primarily local.
The material has clear layering across the main skill, examples, references, and utility scripts. It includes a version, repository Apache-2.0 metadata, official organization provenance, maintenance signals, restart guidance, and gitignore advice. It lacks a skill-level changelog, explicit update path or stability policy, complete dependency installation notes, FAQ coverage, and a single stable schema; some documentation is assumed to exist elsewhere.
For simple plugin configuration, the skill provides usable patterns, templates, parsing utilities, validation utilities, and an implementation workflow. Nevertheless, the result is guidance and illustrative code rather than verified drop-in behavior; complex YAML, malformed input, and security edge cases require review and likely revision. Static calibration limits effectiveness to 7.
Concrete source files, commands, scripts, examples, and error messages make the claims partly auditable. There is no committed test suite or CI evidence covering this skill's key paths, and the purported real-world examples are documentation-contained examples rather than independently corroborated execution evidence. The static maximum is therefore used.
- Do not treat sed/grep extraction as full YAML parsing; complex structures, quoting, duplicate keys, nested values, and malicious content require a strict parser and schema validation.
- Relative paths depend on the current working directory, and body content may be fed back to the model or sent through tmux; establish project scoping, sensitive-data rules, confirmation, permissions, and rollback before adoption.
- jq, optional yq, tmux, and Claude Code restart semantics are assumed inconsistently; validate these requirements separately in the target environment.
What it does & when to use it
This skill documents the `.claude/plugin-name.local.md` pattern for plugin configuration and state. Each file combines YAML frontmatter with a Markdown body and can be read by hooks, commands, and agents. It covers naming, parsing, defaults, validation, Git exclusion, permissions, and restart requirements. It suits Claude Code plugin developers who need per-project behavior, but the source does not provide a standalone installation command or complete test evidence.
It guides users to create .claude/plugin-name.local.md files; use sed to extract YAML frontmatter, grep and sed to read fields, and awk to extract the Markdown body; and read Boolean, string, and numeric settings from Bash hooks, commands, and agents. It also demonstrates template generation, input validation, path-traversal checks, file permissions, and default values when a settings file is absent.
- A plugin developer needs per-project enablement, mode, or retry settings stored outside the plugin code.
- A team wants to temporarily activate or deactivate a security-scan hook through an `enabled` field.
- A multi-agent plugin needs to store agent names, task numbers, and coordinator sessions as project-local state.
- A loop-based plugin needs iteration counts, limits, completion promises, and prompt text persisted between runs.
Pros & cons
- Includes copyable file templates and Bash parsing examples.
- Covers defaults, validation, Git exclusion, and permission guidance.
- Explains use from hooks, commands, and agents.
- It is explicitly framed around Claude Code plugin mechanisms, so hooks, commands, agents, and restart behavior need adaptation elsewhere.
- The examples rely mainly on text-command parsing and do not establish support for complex YAML structures.
- The source provides no test suite, platform compatibility matrix, or standalone installation name.
How to install
The skill is located at plugins/plugin-dev/skills/plugin-settings/SKILL.md. The README says plugins can be installed through Claude Code's plugin system using /plugin install {plugin-name}@claude-plugins-official, but the source does not identify this skill's standalone marketplace name or provide separate installation steps.
How to use
Ask Claude Code a prompt such as “How should a plugin store project-local configuration and read YAML frontmatter?” Create .claude/plugin-name.local.md in the project root with YAML frontmatter and a Markdown body, then read it from a hook, command, or agent. Exit and restart Claude Code after editing so hooks load the new settings.