Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/poorgramer-zack/copilot-cli-things/plugin-settingsnpx skills add Poorgramer-Zack/copilot-cli-things --skill plugin-settingsgit clone --depth 1 https://github.com/Poorgramer-Zack/copilot-cli-thingsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00039 | $0.03017 |
| Opus 5 | $0.00019 | $0.01509 |
| Sonnet 5 | $0.00008 | $0.00603 |
| Haiku 4.5 | $0.00004 | $0.00302 |
Grade B, and why
Plugin Settings scanned grade B with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Asks for rootmediumPrivilege escalation
A mod that escalates privileges can change anything on the machine, not only the project.
- Readable by user only (`chmod 600`) How it starts
The opening of the file, as written. The whole thing — 541 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plugin Settings Pattern for Copilot CLI Plugins
Store per-project plugin configuration in .github/plugin-name.local.md using YAML frontmatter for structured settings and markdown body for prompts or context.
- File location:
.github/plugin-name.local.mdin project root - Structure: YAML frontmatter + markdown body
- Read from hooks, skills, and agents
- User-managed, not in git (add to
.gitignore)
File Structure
Basic Template
---
enabled: true
setting1: value1
setting2: value2
numeric_setting: 42
list_setting: ["item1", "item2"]
---
# Additional Context
This markdown body can contain:
- Task descriptions
- Additional instructions
- Prompts to feed back to Copilot
- Documentation or notes
Example: Plugin State File
.github/my-plugin.local.md:
---
enabled: true
strict_mode: false
max_retries: 3
notification_level: info
coordinator_session: team-leader
---
# Plugin Configuration
This plugin is configured for standard validation mode.
Contact @team-lead with questions.
Reading Settings Files
From Hooks (Bash Scripts)
Pattern: Check existence and parse frontmatter
#!/bin/bash
set -euo pipefail
# Define state file path
STATE_FILE=".github/my-plugin.local.md"
# Quick exit if file doesn't exist
if [[ ! -f "$STATE_FILE" ]]; then
exit 0 # Plugin not configured, skip
fi
# Parse YAML frontmatter (between --- markers)
FRONTMATTER=$(sed -n '/^---$/,/^---$/{ /^---$/d; p; }' "$STATE_FILE")
# Extract individual fields
ENABLED=$(echo "$FRONTMATTER" | grep '^enabled:' | sed 's/enabled: *//' | sed 's/^"\(.*\)"$/\1/')
STRICT_MODE=$(echo "$FRONTMATTER" | grep '^strict_mode:' | sed 's/strict_mode: *//' | sed 's/^"\(.*\)"$/\1/')
# Check if enabled
if [[ "$ENABLED" != "true" ]]; then
exit 0 # Disabled
fi
# Use configuration in hook logic
if [[ "$STRICT_MODE" == "true" ]]; then
# Apply strict validation
# ...
fi
See examples/read-settings-hook.sh for complete working example.
From Commands
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 541 lines · 0 tokens per session scan B f259b78c0746
Plugin Settings is a skill published in the GitHub repository Poorgramer-Zack/copilot-cli-things (2 stars, last pushed 5mo ago), licensed MIT. It adds 39 tokens to every session and 3,017 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 1 finding (asks for root). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
speckit-init
Scaffold a Spec Kit (spec-driven development) project for GitHub Copilot by running specify init --integration copilot --integration-options="--skills". USE FOR: starting a new spec-kit project, bootstrapping spec-driven development in an existing repo, installing spec-kit templates/scripts/commands for Copilot. DO…
speckit-bundle
Discover, install, and author Spec Kit bundles via specify bundle. USE FOR: searching/showing/listing bundles, installing/updating/removing a bundle (a curated set of extensions/presets/integrations/workflows), validating a bundle manifest, building a distributable bundle artifact, initializing a project and…
speckit-extension
Manage Spec Kit extensions via specify extension. USE FOR: installing/removing/updating spec-kit extensions, searching the extension catalog, showing extension info, enabling/disabling extensions, setting extension resolution priority, managing extension catalogs. DO NOT USE FOR: presets (use speckit-preset), bundles…
speckit-preset
Manage Spec Kit presets via specify preset. USE FOR: installing/removing presets, searching the preset catalog, showing preset info, resolving which template a preset name maps to, enabling/disabling presets, setting preset resolution priority, managing preset catalogs. DO NOT USE FOR: extensions (use…
speckit-workflow
Manage and run Spec Kit automation workflows via specify workflow. USE FOR: running a workflow by ID or local YAML, resuming a paused/failed run, checking run status, listing/installing/removing workflows, searching the workflow catalog, showing a workflow step graph. DO NOT USE FOR: extensions (use…
speckit-check
Check the local environment for Spec Kit by running specify check (and specify version). USE FOR: verifying required tools are installed, diagnosing a broken spec-kit setup, reporting CLI version/feature capabilities. DO NOT USE FOR: installing or upgrading the CLI itself (use the speckit-self skill).