Add mcp-skill-deployer — Universal MCP & Skill publisher - #341
Conversation
📝 WalkthroughWalkthroughAdds an opt-in ChangesMCP Skill Deployer
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant mcp-skill-deployer
participant MCPProject
participant RegistryOrGit
User->>mcp-skill-deployer: Request audit, optimization, export, or publishing
mcp-skill-deployer->>MCPProject: Inspect, score, test, and dry-run package
mcp-skill-deployer->>User: Present fixes, exports, and publishing actions
User->>mcp-skill-deployer: Confirm selected write or send operation
mcp-skill-deployer->>RegistryOrGit: Publish package or perform git/tag action
mcp-skill-deployer->>User: Print final compliance and action summary
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7375467757
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - [VSCode Extension (Electron/TypeScript)](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/vscode-extension-dev-typescript-cursorrules-prompt-file.mdc) - VSCode extension development with Electron and TypeScript integration. | ||
| - [Web App Optimization](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/web-app-optimization-cursorrules-prompt-file.mdc) - Web app development with optimization integration. | ||
| - [Ankra CLI (Kubernetes Cluster Management)](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/ankra-cli.mdc) - Ankra CLI development with Kubernetes cluster management integration. | ||
| - [MCP Skill Deployer](https://github.com/lalal-zzz/mcp-skill-publisher) - Universal MCP & Skill publisher. Automates pre-flight compliance audits and generates 9 platform export formats (.mdc, .yml, .txt, .json) for NPM, Smithery, GitHub, cursor.directory, Dify, GPT Store, Coze, FlowGPT, and more. |
There was a problem hiding this comment.
The README's documented usage flow tells users to browse the rules above for an .mdc rule and copy that file into .cursor/rules/, and the contribution section asks new entries to add a canonical rules/*.mdc file. This new item points to an external repo landing page instead of a rule file, so users selecting it from the Rules list cannot follow the repository's install path from this catalog. Please add/link a canonical .mdc under rules/ or move this to a non-rule resources section.
Useful? React with 👍 / 👎.
7375467 to
75abbf9
Compare
A universal AI Agent Skill that automates the complete publishing pipeline for MCP servers and Agent Skills across 9 platforms. - Repo: https://github.com/lalal-zzz/mcp-skill-publisher - Install: npx skills add https://github.com/lalal-zzz/mcp-skill-publisher
75abbf9 to
1a7e7d2
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with 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.
Inline comments:
In `@rules/mcp-skill-deployer.mdc`:
- Around line 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.
- Around line 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.
- Around line 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.
- Around line 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.
- Around line 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.
- Around line 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.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6949ae36-51ef-4dbe-a21c-ed566a5051b9
📒 Files selected for processing (1)
rules/mcp-skill-deployer.mdc
| globs: "**/package.json,**/skills/**" | ||
| alwaysApply: false |
There was a problem hiding this comment.
🎯 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:
- 1: https://dev.to/rulestack/how-cursor-claude-code-and-codex-actually-load-your-project-rules-and-why-yours-get-ignored-1l1j
- 2: https://dev.to/olivia_craft/switching-from-cursor-to-claude-code-your-rules-stop-working-migration-guide-5g2f
- 3: https://www.aibuilderclub.com/blog/claude-md-configuration-guide
- 4: https://code.claude.com/docs/en/memory.md
- 5: https://wmedia.es/en/tips/claude-code-conditional-rules
- 6: https://zenn.dev/yottayoshida/articles/claude-code-context-cost-structure?locale=en
- 7: Documentation: .claude/rules/ frontmatter format incorrect - globs works, paths with quotes/YAML list does not anthropics/claude-code#17204
- 8: https://code.claude.com/docs/en/commands
- 9: https://support.claude.com/en/articles/14553413-claude-code-cheatsheet
🌐 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:
- 1: https://cursor.com/docs/rules.md
- 2: https://cursor.com/docs/rules
- 3: https://taskprio.com/cursor-rules
- 4: https://design.dev/guides/cursor-rules/
- 5: https://forum.cursor.com/t/alwaysapply-true-rules-and-cursorrules-both-silently-treated-as-requestable-instead-of-auto-injected-cursor-3-0-16-macos/157431
- 6: https://aitoolsguidebook.com/en/articles/cursor-rules-tutorial/
- 7: https://forum.cursor.com/t/plugin-rules-with-alwaysapply-true-are-silently-downgraded-to-applied-intelligently/154223
- 8: https://techsy.io/en/blog/cursor-rules-guide
- 9: https://forum.cursor.com/t/cursor-2-0-project-rule-mdc-files-with-glob-patterns-not-auto-loaded-in-conversations/140641
🌐 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:
- 1: https://cursor.com/docs/rules.md
- 2: https://aitoolsguidebook.com/en/articles/cursor-rules-tutorial/
- 3: https://github.com/hktitan/cursor-best-practices/blob/HEAD/cursor-best-practices/references/rules-and-commands.md
- 4: https://dev.to/rulestack/why-your-cursor-rules-never-fire-globs-alwaysapply-and-description-explained-b33
- 5: https://github.com/cursor/cursor/issues/3253
- 6: https://www.datacamp.com/tutorial/cursor-rules
- 7: https://techsy.io/en/blog/cursor-rules-guide
🌐 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:
- 1: https://cursor.com/docs/rules.md
- 2: https://docs.anyweb.dev/docs/rules
- 3: https://dev.to/rulestack/why-your-cursor-rules-never-fire-globs-alwaysapply-and-description-explained-b33
- 4: https://forum.cursor.com/t/cursor-2-0-project-rule-mdc-files-with-glob-patterns-not-auto-loaded-in-conversations/140641
- 5: https://forum.cursor.com/t/do-glob-pattern-rules-only-apply-via-explicit-tagging/150931
- 6: https://forum.cursor.com/t/glob-pattern-rules-are-never-respected-by-agent/160133
- 7: https://developertoolkit.ai/en/cursor-ide/quick-start/project-rules/
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.
| 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) |
There was a problem hiding this comment.
🎯 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 || trueRepository: 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.
| - 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 |
There was a problem hiding this comment.
🎯 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) |
There was a problem hiding this comment.
🎯 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 4: Platform Export (file generation) | ||
| - Generate export files (.mdc, .yml, .txt, .json) for target platforms | ||
| - Never overwrite existing user files without asking |
There was a problem hiding this comment.
🗄️ 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) |
There was a problem hiding this comment.
🔒 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.
1 participant
Add mcp-skill-deployer to the Build Tools and Development section. It automates pre-flight compliance audits and generates 9 platform export formats for NPM, Smithery, GitHub, cursor.directory, Dify, GPT Store, Coze, FlowGPT, and more.
Summary by CodeRabbit