Plugin Settings

Store Claude Code plugin settings in `.claude/plugin-name.local.md` files with YAML frontmatter.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI --skill plugin-settings-quanngynx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Plugin Settings
Source: https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI/tree/main/servexa-warranty-ai/.cursor/skills/plugin-settings
Command: npx skills add https://github.com/quanngynx/GDGO-2026.Servexa-Warranty-AI --skill plugin-settings-quanngynx

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill solves the problem of making Claude Code plugin behavior configurable on a per-project basis without editing plugin code, by standardizing where users store settings and how those settings are structured and read.

Core Features & Use Cases

  • Per-project configuration via .claude/*.local.md: Store plugin enablement, modes, and custom instructions in a project-local Markdown file with YAML frontmatter.
  • Settings-driven behavior for hooks, commands, and agents: Use the stored frontmatter to conditionally run logic, enforce validation modes, and tailor behavior to the current project.
  • Deterministic parsing patterns: Extract YAML frontmatter fields and the Markdown body using bash-friendly parsing techniques (e.g., sed/awk) and validate common fields like booleans and numeric ranges.

Use case: You want a plugin to run in strict validation for one repository but remain disabled or lenient in another, while keeping the configuration user-local and out of git.

Quick Start

Ask the AI to “Read the project’s .claude/plugin-name.local.md file and explain what enabled, validation/mode fields mean for how the hook should behave, then list the key configuration values found in the YAML frontmatter.”

Frequently Asked Questions about Plugin Settings

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I configure Claude Code plugins per project?

You can configure Claude Code plugins per project by storing settings in a `.claude/plugin-name.local.md` file using YAML frontmatter. This allows you to define enablement flags and validation modes without editing plugin code.

What is the best way to manage plugin configuration state for Claude Code hooks?

The best way to manage plugin configuration state is using YAML frontmatter in project-local Markdown files. This standardizes where user-defined settings are stored and parsed deterministically by hooks and commands.

Can I use bash to parse YAML frontmatter for Claude Code project configuration?

Yes, you can use bash-friendly parsing techniques like `sed` and `awk` to extract YAML frontmatter fields and the Markdown body. This allows scripts to validate common fields such as booleans and numeric ranges.

How do I set different validation modes for Claude Code hooks across multiple repositories?

You can set different validation modes by creating a `.claude/plugin-name.local.md` file in each repository. Define the desired validation mode in the YAML frontmatter to conditionally enforce strict or lenient behavior per project.

Does Claude Code project configuration support keeping settings out of git?

Yes, storing configuration in `.claude/plugin-name.local.md` keeps settings user-local and out of git. This ensures individual developers can customize plugin behavior without affecting the shared repository.

What are the limitations of using local Markdown files for Claude Code plugin settings?

A key limitation is the restart expectation after modifying configuration. Users must also follow safety guidance regarding defaults and validation, as parsing relies on standard bash techniques rather than a dedicated YAML parser.