Skip to content

Add mcp-skill-deployer — Universal MCP & Skill publisher #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lalal-zzz wants to merge 1 commit into
base: main
Choose a base branch
from
+49 −0
Open

Add mcp-skill-deployer — Universal MCP & Skill publisher #341

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions rules/mcp-skill-deployer.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
description: "mcp-skill-deployer: when the user explicitly asks to audit, score, optimize, inspect, package, or publish an MCP server or Agent Skill project, run compliance checks, quality scoring, guided optimization, and export file generation. Never execute npm publish, git push, or registry commands without per-step user confirmation."
globs: "**/package.json,**/skills/**"
alwaysApply: false
Comment on lines +3 to +4

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== files =="
git ls-files | sed -n '1,200p'

echo "== rule file =="
if [ -f rules/mcp-skill-deployer.mdc ]; then
  cat -n rules/mcp-skill-deployer.mdc | sed -n '1,220p'
fi

echo "== rule references / patterns =="
rg -n "mcp-skill|Skill deployer|mcp|alwaysApply|globs|rules/" . --glob '!node_modules' --glob '!dist' --glob '!build' | sed -n '1,220p'

Repository: PatrickJS/awesome-cursorrules

Length of output: 50385

🌐 Web query:

Claude Code rules mdc globs alwaysApply format load rules outside globs explicit commands

💡 Result:

Claude Code configuration differs significantly from Cursor's.mdc rules [1][2][3]. While Cursor uses frontmatter with globs and alwaysApply inside.mdc files, Claude Code uses a separate system centered on CLAUDE.md and the.claude/rules/ directory [1][4]. Key configuration mechanisms for Claude Code include: 1. CLAUDE.md and.claude/rules/ Claude Code automatically loads instructions from CLAUDE.md (at the project root or subdirectories) and any.md files located in the.claude/rules/ directory [1][4][5]. Rules without path-scoped frontmatter are loaded into the context at session launch and apply globally [4][6]. 2. Scoping Rules with Paths To avoid loading all rules into context constantly, you can use frontmatter in individual.md files within.claude/rules/ [4][5]. Use the paths field to define which files trigger the rule [4][7][5]. - Format: Add a YAML frontmatter block to your rule file [4]. - Trigger: The rule is loaded into context only when Claude interacts with files matching the paths pattern [4][6][5]. - Syntax: Use unquoted comma-separated values for patterns (e.g., paths: src//.ts, lib//.ts) [7]. 3. Globs vs. Paths Claude Code documentation uses the paths field for conditional loading [4]. While some community discussions mention globs, paths is the officially supported field for file-specific scoping [4][7]. Note that older or incorrect configuration might attempt to use globs or alwaysApply syntax intended for Cursor; these do not function natively as "alwaysApply" toggles in Claude Code [1][2][7]. 4. Explicit Commands and Skills For task-specific instructions that should not be in the context unless necessary, use skills instead of rules [4][6]. Skills are located in.claude/skills/ and are invoked explicitly by the user or chosen by Claude when relevant [4][8][9]. This approach saves context space compared to global rules [6][5]. 5. Managing Rule Priority - Project rules are loaded recursively; files in subdirectories add context when working in those areas [1][4]. - You can maintain modularity by splitting large instructions into multiple files in.claude/rules/, using path-based scoping to ensure they only consume context when relevant [4][5]. In summary, do not use Cursor-style alwaysApply or glob frontmatter in Claude Code [1][2]. Instead, organize instructions into.claude/rules/ files and use the paths frontmatter to scope them, or create skills for on-demand use [4][5].

Citations:

🌐 Web query:

Cursor Project Rules .mdc globs alwaysApply behavior **/* rule only activates with globs

💡 Result:

In Cursor's rule system, setting alwaysApply: true in an .mdc file is intended to force the rule to be included in every chat session, regardless of context [1][2][3]. When alwaysApply is set to true, the globs and description fields are explicitly ignored [1][2][4]. The behavior where a rule only activates via globs suggests that the alwaysApply setting is either not being registered as true or is being overridden [5][6]. Technical documentation and community reports confirm that: 1. Intentional Interaction: When alwaysApply: true is set, globs are semantically unnecessary and ignored [1][5]. Including both can sometimes cause confusion in rule evaluation if the configuration is improperly parsed [5]. 2. Potential Issues: Users have reported regressions where rules with alwaysApply: true were silently downgraded to "Applied Intelligently" (agent-requested) or "requestable" status in certain Cursor versions [7][5][6]. If your rules are behaving as if they are governed by globs, the application may be failing to honor the alwaysApply: true flag [5][6]. 3. Recommended Troubleshooting: - Ensure the frontmatter is correctly formatted YAML [4][8]. - If the rule is not applying as expected, try removing the globs field entirely when alwaysApply: true is used [5]. - Verify in the Cursor "Rules" settings panel that the rule type is explicitly listed as "Always Apply" and not "Auto Attached" or "Agent Requested" [6]. - Check that you are not running both a legacy .cursorrules file and competing .mdc rules that might create conflicting behavior [5][6]. If the rule still only fires based on globs, it is likely that the alwaysApply property is being ignored, effectively reverting the rule to an "Auto Attached" state [6][9]. Updating to the latest version of Cursor is recommended, as previous version-specific bugs regarding alwaysApply precedence have been patched [7].

Citations:

🌐 Web query:

Cursor Project Rules alwaysApply false globs optional explicit commands

💡 Result:

In Cursor, .mdc project rules use YAML frontmatter to determine how and when instructions are applied to the AI agent [1][2]. The alwaysApply property is a boolean that, when set to true, is intended to force the rule to be included in every chat session, regardless of context [1][3]. However, technical documentation and community reports indicate that alwaysApply: true is designed to override other selection mechanisms (like globs or description-based intelligent application) [1][4]. When alwaysApply is true, the globs and description fields are effectively ignored [1][2]. If you find that an alwaysApply: true rule is not being correctly injected into your context, it may be due to a known discrepancy in certain versions of Cursor where the engine fails to trigger the rule without an accompanying catch-all glob pattern [5]. In such cases, users have reported that explicitly adding globs: ["*"] resolves the issue by forcing the rule to match every file, effectively achieving the desired "always on" behavior [5]. Key characteristics of alwaysApply and related fields: - alwaysApply: true: The rule is always included in the agent's context [1][6]. Use this sparingly for global project conventions, as it consumes tokens in every interaction [3][7]. - alwaysApply: false (Default): The rule's application depends on other metadata [4][2]. - If globs are provided: The rule auto-attaches when a matching file is in the current context [1][4]. - If a description is provided (without globs): The rule applies "intelligently," where the agent evaluates the description to determine relevance [1][4]. - If no globs or description are provided: The rule becomes manual-only, requiring an explicit @-mention (e.g., @rule-name) in the chat to be triggered [4][2]. For optimal rule management, it is recommended to use .mdc files in the .cursor/rules/ directory rather than the legacy .cursorrules file, as the .mdc format supports these specific frontmatter controls [1][7].

Citations:

🌐 Web query:

Cursor project rules only applies when file matches globs alwaysApply false documentation

💡 Result:

In Cursor, project rules defined in.mdc files use the alwaysApply frontmatter field to determine their activation behavior [1][2]. When alwaysApply is set to false, the rule's application depends on the presence of other frontmatter fields like globs or description [1][3][2]. Specifically, when alwaysApply is set to false and you provide a globs field, the rule is "auto-attached" [1][3][2]. This means the rule is automatically included in the AI agent's context whenever the agent reads, edits, or references a file that matches the specified glob pattern [3][4][5]. Key points regarding this behavior include: - Triggering Mechanism: Glob-scoped rules (alwaysApply: false) are not active at the start of a chat session [5]. They are injected into the agent's context dynamically when the agent interacts with a matching file during its workflow [4][6][5]. - Configuration Syntax: To ensure glob patterns are recognized correctly, use a plain, comma-separated string (e.g., globs: /.ts, /.tsx) rather than complex YAML list formatting, which can sometimes be misparsed [6]. - Fallback Behavior: If a rule has alwaysApply: false, no globs, and no description, it defaults to Manual, meaning it will never be applied unless you explicitly @-mention the rule in your chat [1][3][2]. - Precedence: Setting alwaysApply: true overrides all other settings, forcing the rule to be included in every chat session regardless of the file context [1][2]. If you find that your glob-scoped rules are not appearing, ensure the file is an.mdc file (not.md), the frontmatter syntax is correct, and that the agent has actually accessed or worked with a file matching your glob pattern [3][7][6].

Citations:

Make the MCP project rule available when user files are outside the current globs.

With alwaysApply: false, this rule only auto-attaches through **/package.json and **/skills/**. MCP servers that expose files outside those paths, or projects whose relevant source/config files are elsewhere, can miss the workflow entirely. Add broader matching for the MCP project (**/* if intended) or alwaysApply: true if the rule should run on explicit MCP/skill commands from any file context.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 3 - 4, Broaden the activation
settings for the MCP project rule by updating its globs or alwaysApply
configuration so it remains available when relevant MCP or skill files are
outside package.json and skills paths. Use a repository-wide glob such as **/*
or enable alwaysApply when the workflow must apply from any file context, while
preserving the intended scope for explicit MCP/skill commands.

---

# mcp-skill-deployer

Only activate when the user explicitly requests to audit, optimize, inspect, package, or publish an MCP or Skill project (e.g., "/mcp-skill-deployer", "score my skill", "optimize my MCP", "check and publish my project").

## Mode Selection
Pick the mode from user intent — do NOT default to full publishing:
- **Audit**: "check / score my project" → Phases 0-2 only (read-only report)
- **Optimize**: "optimize / fix my project" → Phases 0-3 (edits require per-item confirmation)
- **Publish**: "publish / release my project" → full pipeline (Phases 0-6)
Comment on lines +9 to +15

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== file excerpt =="
sed -n '1,120p' rules/mcp-skill-deployer.mdc 2>/dev/null || true

echo "== occurrences of inspect/package/modes/phases =="
rg -n "inspect|package|Audit|Optimize|Publish|Phase [0-9]|post-publish|summary|Phases" rules/mcp-skill-deployer.mdc 2>/dev/null || true

Repository: PatrickJS/awesome-cursorrules

Length of output: 4367

Define phases for inspect, package, and the post-publish summary.

inspect and package are activation keywords, but the mode list covers only audit/optimization/publish, so their intended phase set is undefined. The publish workflow also defines Phases 0-6 only, even though Phase 7: Summary exists below; include Phase 7 in publish if that summary must always run.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 9 - 15, Update the Mode Selection
section in mcp-skill-deployer.mdc to define explicit phase ranges for the
inspect and package intents, consistent with their intended read-only or
packaging behavior. Also extend the Publish mode to include Phase 7 so the
post-publish summary always runs, and ensure the phase descriptions remain
aligned with the workflow definitions below.


## Phase 0: Pre-flight Audit
- Run `npm whoami` (publish mode only), `git status` (read-only checks only)
- Scan for leaked secrets (API keys, tokens, .env content)
- Validate `package.json` or `skills/*/SKILL.md` structure

## Phase 1: Project Inspection
- Auto-detect: MCP-only / Skill-only / hybrid
Comment on lines +19 to +23

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Validate both project types in hybrid mode.

The rule can detect a hybrid project, but package.json or skills/*/SKILL.md structure permits one side to be skipped. For hybrid projects, validate both MCP/package metadata and every relevant SKILL.md.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 19 - 23, Update the validation
guidance near the project-type detection in the MCP/skill deployment rule so
hybrid projects validate both MCP package metadata, including package.json, and
every relevant skills/*/SKILL.md file; do not allow the “package.json or
SKILL.md” wording to skip either side when both project types are detected.


## Phase 2: Quality Audit & Scoring
- Score against the 100-point checklist (MCP: tool naming/descriptions, schemas, error handling, token efficiency, registry metadata; Skill: description triggerability, length, executable steps, trigger boundaries, confirmation gates)
- Output report: total score, A/B/C/D grade, prioritized fix list (blockers → high impact → polish)
Comment on lines +25 to +27

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Specify the scoring rubric and grade thresholds.

The rule requires a 100-point score and A/B/C/D grade but defines neither criterion weights nor grade boundaries. Without those values, scores will be non-reproducible and different runs can produce inconsistent recommendations.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 25 - 27, Update the “Phase 2:
Quality Audit & Scoring” section to define the 100-point criterion weights
across the listed MCP and Skill quality areas, along with explicit A/B/C/D score
thresholds. Ensure the report instructions use those fixed weights and
boundaries so evaluations and recommendations are reproducible.


## Phase 3: Optimization (WITH PER-ITEM CONFIRMATION)
- Show diff preview per fix, apply only after user approval
- Never change core functionality or delete user content
- Re-score after fixes and show before/after comparison

## Phase 4: Platform Export (file generation)
- Generate export files (.mdc, .yml, .txt, .json) for target platforms
- Never overwrite existing user files without asking
Comment on lines +34 to +36

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Apply the confirmation gate to every file write, not only overwrites and publishing.

The current wording allows new export files to be generated without explicit approval, while the “ANY write/send” rule is scoped only to Phase 6. Define one global confirmation policy covering optimization edits, new export files, tags, pushes, and registry submissions.

📍 Affects 1 file
  • rules/mcp-skill-deployer.mdc#L34-L36 (this comment)
  • rules/mcp-skill-deployer.mdc#L42-L46
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 34 - 36, Define one global
confirmation policy in rules/mcp-skill-deployer.mdc covering every write or
submission, including optimization edits, new export files, tags, pushes, and
registry submissions. Update the Phase 4 platform export guidance at lines 34-36
and the related Phase 6 guidance at lines 42-46 so all file writes require
explicit approval, not only overwrites or publishing; remove any wording that
permits unconfirmed new-file generation.


## Phase 5: Testing & Security
- Run `npm test` or `pytest`
- Run `npm pack --dry-run` (dry-run only)
Comment on lines +38 to +40

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift

Add an execution-safety boundary around project tests.

npm test and pytest execute repository-controlled code, which can modify files, access the network, or expose secrets. Require explicit approval or run these commands in an isolated, time-limited environment with an appropriate network policy.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/mcp-skill-deployer.mdc` around lines 38 - 40, Update the “Phase 5:
Testing & Security” instructions for npm test and pytest to require explicit
user approval before execution, or mandate running them in an isolated,
time-limited environment with an appropriate network policy. Keep npm pack
--dry-run unchanged.


## Phase 6: Publishing (WITH MANDATORY CONFIRMATION)
- Before ANY write/send operation, ask the user: "I'm about to [action]. Proceed? (yes/no)"
- **Track A (MCP)**: Ask confirmation before each: `npm publish`, Smithery submit, Anthropic registry submit
- **Track B (Skill)**: Ask confirmation before each: `git tag`, `git push`
- Never execute registry or git write operations without explicit user approval

## Phase 7: Summary
- Print read-only summary: compliance status, before/after quality score, export files generated, executed actions, pending manual submissions
Loading