prompt-evaluation-runn…
Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost…
Use when designing or reviewing filesystem MCP access, path boundaries, allowed roots, method allowlists, and safe local file operations.
Claude Code
$ npx -y skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails --agent claude-code
Codex
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a codex -y
Cursor
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a cursor -y
Gemini CLI
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a gemini-cli -y
GitHub Copilot
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a github-copilot -y
OpenCode
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a opencode -y
Windsurf
$ npx skills add yeaight7/agent-powerups --skill filesystem-mcp-guardrails -a windsurf -y
name: filesystem-mcp-guardrails description: Use when designing or reviewing filesystem MCP access, path boundaries, allowed roots, method allowlists, and safe local file operations.
Use when configuring, reviewing, or debugging a local filesystem MCP server — particularly when deciding which paths to expose, which methods to allow, and how to enforce workspace boundaries.
The core constraint is **strict path bounding**: the MCP server must only operate within explicitly declared workspace roots. No exceptions.
| Principle | Rule | |---|---| | Scope | Bind to the project workspace directory only — never `/`, `~`, or OS dirs | | Access | Start read-only; add write methods only when the use case requires them | | Methods | Use an allowlist — block delete/move/rename by default | | Secrets | Never expose `.env`, credential files, SSH keys, or token stores | | Approval | Always require user approval before starting a new MCP server process |
Before starting a filesystem MCP server:
1. **Define scope** — identify which directories the agent legitimately needs to access for this task. 2. **Set roots** — configure the server with the narrowest possible root list (usually just the project root). 3. **Define allowlist** — start with read-only methods; add write methods only after explicit use-case review. 4. **Validate path boundaries** — test that requests for paths outside the declared roots are refused with a clear error. 5. **Verify cleanup** — confirm the server process exits cleanly when the session ends; no background processes left running.
The server must return a clear error for any request targeting a path outside declared roots:
Error: path '/etc/passwd' is outside allowed workspace root '/home/user/project'
Silent failures or fallback to broader access are not acceptable.
Curated power-ups for coding agents: skills, slash commands, MCP configs, hooks, AGENTS.md templates, and workflows for serious software engineering. Claude Code, Codex, Antigravity CLI, Cursor and more
Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost…
Use when creating or reviewing red-team eval plugins, attack templates, grader rubrics, safety fixtures, or model-risk test…
Use when designing, running, debugging, or hardening deterministic eval suites for agent skills, prompts, tool workflows, or…
Use when designing tool definitions for a new agent or subagent, an agent shows high retry rates, ambiguous tool invocations, or…
Use when routing a prompt to a local provider CLI for a second opinion, review, or plan -- you are about to call a provider…
Use when starting work in an unfamiliar area of a codebase, spawning a subagent that needs targeted file context, a first search…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.