Plugin Settings

Manage per-project plugin configurations via YAML frontmatter in .claude/plugin-name.local.md files.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/PoyoPoak/FastAPI-App-Template --skill plugin-settings-poyopoak
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Plugin Settings
Source: https://github.com/PoyoPoak/FastAPI-App-Template/tree/main/.agents/skills/plugin-settings
Command: npx skills add https://github.com/PoyoPoak/FastAPI-App-Template --skill plugin-settings-poyopoak

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Local per-project plugin configurations are often scattered, hard to discover, and risk being committed or lost when switching projects. This section documents a pattern to store per-project plugin settings in .claude/plugin-name.local.md using YAML frontmatter and a markdown body to describe context and usage.

Core Features & Use Cases

  • Documents per-project configuration in .claude/plugin-name.local.md using YAML frontmatter and a markdown body
  • Supports an explicit enabled switch, per-project defaults, and safe gitignore practices
  • Enables consistent plugin behavior across repositories and teams, with a clear pattern for sharing configuration guidance

Quick Start

Create a per-project configuration file at .claude/plugin-name.local.md and restart Claude Code to apply changes.

Frequently Asked Questions about Plugin Settings

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

FAQPage Schema
How do I manage per-project plugin configurations safely in Claude Code?

Per-project plugin configurations are managed by storing YAML frontmatter and markdown documentation in a local file named .claude/plugin-name.local.md. This ensures settings remain isolated to the current repository and apply safely upon Claude Code restart.

What is the best way to prevent local plugin settings from being committed to git?

Preventing local plugin settings from being committed requires using safe gitignore practices alongside the .claude/plugin-name.local.md pattern. This ensures per-project configuration state remains local to your development environment without risking accidental repository exposure.

How do I enable or disable a plugin for a specific repository workflow?

Enabling or disabling a plugin for a specific repository involves setting an explicit enabled flag within the YAML frontmatter of the .claude/plugin-name.local.md file. This switch directly controls plugin activation for your current project workflow.

What happens if a local plugin configuration file is missing?

If a local plugin configuration file is missing, the plugin automatically applies safe default settings. The system handles missing files gracefully to ensure robust integration and prevent workflow interruptions when per-project state is absent.

Can I use YAML frontmatter to document plugin usage context alongside settings?

Yes, you can use YAML frontmatter to define plugin settings while utilizing the markdown body of the .claude/plugin-name.local.md file to provide usage context and documentation prompts for that specific plugin.

How are atomic updates handled for local plugin configuration files?

Atomic updates for local plugin configuration files are handled with quick-exit processing logic to ensure robust integration. This prevents partial configuration writes and maintains consistent per-project plugin behavior during updates.