awesome-copilot CMS 开发插件实战指南：主题、插件、媒体管线与静态导出全流程

awesome-copilot CMS 开发插件实战指南：主题、插件、媒体管线与静态导出全流程

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

本指南围绕 awesome-copilot 仓库中的 cms-development 插件 展开，介绍如何借助 GitHub Copilot 在 WordPress、Shopify、Drupal、Webflow、AEM 等主流 CMS 平台上完成主题/模板开发、插件与扩展开发、后台编辑界面、媒体上传管线、Markdown 渲染以及静态导出流水线的全链路工作。读完本文，你将掌握该插件的安装方式、内置四项技能的定位与触发时机、跨平台“接线缝（owning seam）”定位方法论，以及可直接落地的 Markdown 转 HTML 与“准代码（quasi-code）”转生产代码的实战方案。

一、插件定位：一个面向 CMS 开发的技能工具包

cms-development是 awesome-copilot 社区维护的一个插件（Plugin），其定位在 plugin.json 中描述为：

Skills for CMS development across themes, plugins, admin tooling, media workflows, markdown rendering, and static export pipelines.

即覆盖六个核心工作面：

• 主题（themes）与模板（templates）
• 插件（plugins）、应用（apps）、模块（modules）与扩展（extensions）
• 后台（admin）与编辑器（editor）界面
• 媒体（media）与上传（upload）处理
• 内容模型（content models）、分类法（taxonomy）与元数据（metadata）
• 渲染管线（render pipelines）与静态导出（static export）流程

在仓库体系里，插件是一组“围绕特定主题/工作流组织的相关技能集合”，可通过 GitHub Copilot CLI 或 VS Code 直接安装，而 awesome-copilot 本身作为默认插件市场，无需额外配置（见 docs/README.plugins.md）。

二、安装与使用方式

2.1 通过 Copilot CLI 安装

在插件 README 中给出了唯一一条安装命令：

copilot plugin install cms-development@awesome-copilot

此外，根据 docs/README.plugins.md 的说明，你还可以在交互式会话中浏览市场：

/plugin marketplace browse awesome-copilot

2.2 通过 VS Code 安装

• 打开扩展搜索视图，输入@agentPlugins浏览可用插件；
• 或打开命令面板（Command Palette），执行Chat: Plugins。

安装后，相关技能会在对应任务场景中被自动调用（技能通常由 Copilot 依据描述自动匹配触发，无需手动切换）。

2.3 插件清单与技能映射

插件 README 的“What's Included”表格列出了四项技能，其功能定位如下：

对照 plugin.json 的extensions.com.github.awesome-copilot.skills字段可以看到，插件实际挂载了三个技能目录：./skills/content-management-systems/、./skills/markdown-to-html/、./skills/quasi-coder/。其中web-coder在插件 README 中被列为支撑性技能，负责前端/浏览器/HTTP 基础能力；插件元数据声明的技能路径以仓库中实际存在的三个技能目录为准。

三、何时使用该插件

当工作重心落在以下任一场景时，就应当安装并使用 cms-development 插件：

• 在任何 CMS 平台上开发或定制主题（themes）与模板（templates）
• 构建或修改插件、应用（apps）、模块或扩展
• 处理后台/编辑器界面、内容表单或发布流程
• 处理媒体上传、资源管线或创作文件存储
• 实现或调试 Markdown 渲染与内容转换
• 构建静态导出、部署或服务端渲染输出管线
• 建模内容类型、分类法（taxonomy）、slug、元数据或迁移 schema

四、核心技能一：content-management-systems（CMS 平台工作流）

该技能的完整定义位于 skills/content-management-systems/SKILL.md，其适用平台包括 WordPress、Shopify、Wix、Squarespace、Drupal、WooCommerce、Joomla、HubSpot CMS Hub、Webflow、Adobe Experience Manager 及类似系统。

4.1 技能聚焦的“关键接缝”

技能将 CMS 工作聚焦在六个“接缝（seams）”上：

• themes and templates（主题与模板）
• plugins, apps, modules, and extensions（插件、应用、模块与扩展）
• admin and editor interfaces（后台与编辑器界面）
• media and upload handling（媒体与上传处理）
• content models, taxonomy, and metadata（内容模型、分类法与元数据）
• render pipelines and static export flows（渲染管线与静态导出流程）

4.2 触发时机

当用户提到下述任一情况时，应触发该技能：

• 提及 WordPress、Shopify、Drupal、Joomla、Webflow、Squarespace、Wix、WooCommerce、HubSpot CMS Hub 或 Adobe Experience Manager 等 CMS 平台；
• 任务是主题开发、模板修改或 CMS 内的设计系统工作；
• 任务涉及插件、模块、应用或扩展点；
• 任务涉及编辑器 UX、预览、分类法、slug、SEO 字段或发布行为；
• 任务涉及上传、媒体库、创作资源、Markdown 渲染或静态导出。

4.3 第一遍（First Pass）流程

动手修改前，技能要求先完成三步定性：

1. 识别平台类别：自托管 CMS、SaaS 站点构建器、电商平台，还是混合/无头（headless）系统；
2. 定位负责实现的接缝，包括：
   • 主题/模板层
   • 插件/应用/模块/扩展层
   • 后台/编辑器表面
   • 内容模型或存储层
   • 媒体管线
   • 导出、部署或渲染管线
3. 检查平台约束：
   • 哪些可以本地编辑
   • 哪些是创作内容（authored content）而非代码
   • 媒体应该放在哪里
   • 最终站点是服务端渲染、静态导出，还是远程托管

4.4 CMS 通用规则

• 遵循平台对主题、模块、模板部件或区块的命名与目录约定；
• 除非平台明确合并，否则保持主题资源与用户上传媒体的分离；
• 优先使用结构化内容字段，而不是把重要元数据塞进展示标记里；
• 将预览、slug、分类法、摘要、meta 字段与发布状态视为一等公民；
• 在配置、主题选择或内容输入无效时，采用安全默认值与优雅回退；
• 修改编辑器/后台行为时，要串联追踪存储字段、校验规则、预览路径与最终渲染路径。

4.5 六大常见工作流

主题与模板（Themes and Templates）

• 从模板加载器或主题运行时入手，而不是下游的 include；
• 保留平台的模板层级与局部模板命名约定；
• 展示层改动尽量贴近模板与共享主题辅助函数。

插件、应用与模块（Plugins, Apps, and Modules）

• 在平台的扩展接缝处添加行为，而不是把逻辑散落到模板中；
• 让迁移、种子数据与配置更新显式化并纳入版本管理；
• 平台要求激活或注册时，文档化扩展的安装假设。

后台与编辑器 UX（Admin and Editor UX）

• 表单与存储的内容模型保持对齐；
• 内容转换较复杂时，优先提供面向作者的预览；
• 校验、CSRF 或等价防护与权限设置要和周围后台代码保持一致。

媒体与上传（Media and Uploads）

• 创作媒体使用专用上传路径；
• 装饰性或主题自有的图片放在当前主题目录；
• 默认采用约定位置：创作媒体用uploads/，主题资源用img/（除非平台有更强约定）；
• CMS 支持可配置媒体目录时，暴露该设置并提供安全回退。

内容模型与迁移（Content Models and Migrations）

• 清晰区分内容实体：页面、文章、产品、条目、集合、分类法与设置；
• 优先使用迁移文件或可导出的 schema 定义，而非临时运行时变更；
• 让 slug、发布日期、摘要、规范元数据与分类法关系保持结构化。

Markdown、HTML 与静态导出（Markdown, HTML, and Static Export）

• 修改渲染器前，先判定 Markdown 是创作输入、中间内容还是构建输出；
• 渲染器改动尽量配套预览或校验；
• 对静态导出的 CMS，构建变更后要验证重写后的永久链接（permalinks）与资源路径。

4.6 定位负责接缝（Identifying the Owning Seam）

无论何种平台，先把代码库映射到以下 CMS 角色，再定位负责接缝：

• 运行时引导（runtime bootstrap）与请求路由
• 后台/编辑器控制器及其视图模板
• 主题加载、模板层级与共享模板辅助函数
• 内容、分类法与设置的仓储/模型/schema/迁移文件
• Markdown 或内容转换工具
• 静态导出、部署或渲染管线入口

先走到负责接缝，再做“能保持 CMS 结构的最小改动”。

4.7 平台对照速查表

skills/content-management-systems/references/cms-platform-workflows.md 提供了常用平台、扩展表面与媒体约定的紧凑映射：

媒体黄金法则（Media Rule of Thumb）：

• 主题自有图片属于主题/模板包；
• 用户创作图片属于平台的 uploads 或媒体库流程；
• 若项目两者都支持，在配置与代码路径中保持二者分离。

五、核心技能二：markdown-to-html（Markdown 渲染与转换）

完整技能定义位于 skills/markdown-to-html/SKILL.md，定位是“将 Markdown 文档转换为 HTML 的专家技能”，对标marked.js、pandoc、gomarkdown/markdown等工具，以及jekyll、hugo这类基于 Markdown 的模板系统。它同时支持 CLI 与 Node.js 工作流，覆盖 GFM、CommonMark 与标准 Markdown 风格。

5.1 触发时机

• 用户要求“convert markdown to html”“transform md files”；
• 用户要“render markdown”为 HTML 输出；
• 需要从 .md 文件生成 HTML 文档；
• 正在用 Markdown 内容构建静态站点；
• 正在构建把 Markdown 转 HTML 的模板系统；
• 正在为既有模板系统开发工具、组件或自定义模板；
• 想预览 Markdown 的渲染 HTML 效果。

5.2 基础转换对照（Essential Basic Conversions）

技能要求转换脚本或工具能处理单文件、批量转换与高级配置。其核心示例（Markdown 输入 → HTML 输出）如下：

输入（Markdown）： # Level 1 ## Level 2 One sentence with a [link](https://example.com), and a HTML snippet like `<p>paragraph tag</p>`. - `ul` list item 1 - `ul` list item 2 1. `ol` list item 1 2. `ol` list item 1 | Table Item | Description | | One | One is the spelling of the number `1`. | | Two | Two is the spelling of the number `2`. | ```js var one = 1; var two = 2; function simpleMath(x, y) { return x + y; } console.log(simpleMath(one, two));

输出（HTML）：

Level 1

Level 2

One sentence with a link, and a HTML snippet like<p>paragraph tag</p>.

• `ul` list item 1
• `ul` list item 2

1. `ol` list item 1
2. `ol` list item 2

var one = 1; var two = 2; function simpleMath(x, y) { return x + y; } console.log(simpleMath(one, two));

**代码块转换**：围栏代码块转换为 `<pre><code class="language-xxx">` 结构；包含可见反引号的内容需保留反引号原样输出。 **折叠区（Collapsed Sections）转换**：`<details>/<summary>` 块内嵌 Markdown 时，内部标题、列表、格式化与代码块都要分别转换为对应 HTML 元素。 **数学表达式转换**：行内 `$...$` 与块级 `$$...$$` 数学公式转换为 MathML（如 `<math-renderer><math xmlns="http://www.w3.org/1998/Math/MathML">…</math></math-renderer>`），例如 Cauchy-Schwarz 不等式可转换为完整的 `<msup>/<munderover>/<msub>` 结构。 **表格转换**：普通管道表格转为 `<table><thead><tr><th>` 结构；对齐标记（`:---`、`:---:`、`---:`）对应转换为 `<th align="left|center|right">`。 ### 5.3 基于 marked.js 的工作流 **前置条件**：Node.js 已安装；全局安装 `npm install -g marked` 或本地安装 `npm install marked`。 **CLI 配置**：创建 `~/.marked.json` 持久化选项： ```json { "gfm": true, "breaks": true }

或使用自定义配置文件：

marked -i input.md -o output.html -c config.json

CLI 选项参考：

安全警告：marked 不会净化输出 HTML。对不可信输入，必须配合净化器：

import { marked } from 'marked'; import DOMPurify from 'dompurify'; const unsafeHtml = marked.parse(untrustedMarkdown); const safeHtml = DOMPurify.sanitize(unsafeHtml);

推荐净化器：DOMPurify（首选）、sanitize-html、js-xss。

支持的 Markdown 风格：原始 Markdown 100%；CommonMark 0.31 约 98%；GFM 约 97%。

常见问题排查：

5.4 基于 pandoc 的工作流

前置条件：安装 pandoc；如需 PDF 输出还需 LaTeX（macOS 用 MacTeX、Windows 用 MiKTeX、Linux 用 texlive）。

快速转换方法：

# Markdown 转 HTML pandoc input.md -o output.html # 独立文档（含页头/页脚） pandoc input.md -s -o output.html # 显式指定输入/输出格式 pandoc input.md -f markdown -t html -s -o output.html

过滤器（Filter）交互模式：直接运行pandoc，输入 Markdown 后按 Ctrl-D（Linux/macOS）或 Ctrl-Z+Enter（Windows），例如输入Hello *pandoc*!会输出<p>Hello <em>pandoc</em>!</p>。

格式互转：

# HTML 转 Markdown pandoc -f html -t markdown input.html -o output.md # Markdown 转 LaTeX pandoc input.md -s -o output.tex # Markdown 转 PDF（需 LaTeX） pandoc input.md -s -o output.pdf # Markdown 转 Word pandoc input.md -s -o output.docx

CLI 选项参考：

安全警告：pandoc 忠实处理输入。转换不可信 Markdown 时建议：使用--sandbox禁用外部文件访问、处理前校验输入、浏览器展示时净化 HTML 输出：

pandoc --sandbox input.md -o output.html

支持的 Markdown 风格：Pandoc Markdown 100%（原生）；CommonMark 完整（用-f commonmark）；GFM 完整（用-f gfm）；MultiMarkdown 部分支持。

常见问题排查：PDF 生成失败需安装 LaTeX；Windows 编码问题先运行chcp 65001；缺少独立页头加-s；数学不渲染用--mathml或--mathjax；表格不渲染检查管道符与破折号语法。

5.5 基于 gomarkdown/markdown 的工作流

前置条件：Go 1.18+；安装库go get github.com/gomarkdown/markdown；CLI 工具go install github.com/gomarkdown/mdtohtml@latest。

简单转换（Go）：

package main import ( "fmt" "github.com/gomarkdown/markdown" ) func main() { md := []byte("# Hello World\n\nThis is **bold** text.") html := markdown.ToHTML(md, nil, nil) fmt.Println(string(html)) }

CLI 工具：

go install github.com/gomarkdown/mdtohtml@latest mdtohtml input.md output.html # 输出到文件 mdtohtml input.md # 输出到 stdout

自定义解析器与渲染器：

package main import ( "github.com/gomarkdown/markdown" "github.com/gomarkdown/markdown/html" "github.com/gomarkdown/markdown/parser" ) func mdToHTML(md []byte) []byte { // 带扩展的解析器 extensions := parser.CommonExtensions | parser.AutoHeadingIDs | parser.NoEmptyLineBeforeBlock p := parser.NewWithExtensions(extensions) doc := p.Parse(md) // 带标志的 HTML 渲染器 htmlFlags := html.CommonFlags | html.HrefTargetBlank opts := html.RendererOptions{Flags: htmlFlags} renderer := html.NewRenderer(opts) return markdown.Render(doc, renderer) }

解析器扩展：parser.CommonExtensions（表格、围栏代码、自动链接、删除线等）、parser.AutoHeadingIDs（为标题生成 ID）、parser.NoEmptyLineBeforeBlock（块前无需空行）、parser.MathJax（LaTeX 数学的 MathJax 支持）。

渲染器标志：html.CommonFlags（通用输出标志）、html.HrefTargetBlank（链接加target="_blank"）、html.CompletePage（生成完整页面）、html.UseXHTML（生成 XHTML 输出）。

安全警告：gomarkdown 不净化输出 HTML，不可信输入需配合 Bluemonday：

import ( "github.com/microcosm-cc/bluemonday" "github.com/gomarkdown/markdown" ) maybeUnsafeHTML := markdown.ToHTML(md, nil, nil) html := bluemonday.UGCPolicy().SanitizeBytes(maybeUnsafeHTML)

常见问题排查：Windows/Mac 换行不解析用parser.NormalizeNewlines(input)；表格不渲染启用parser.Tables；数学不渲染启用parser.MathJax；XSS 用 Bluemonday 净化。

5.6 基于 Jekyll 的静态站点工作流

前置条件：Ruby 2.7.0+、RubyGems、GCC 与 Make；安装gem install jekyll bundler。

快速上手：

# 创建新站点 jekyll new myblog cd myblog bundle exec jekyll serve # 本地预览 http://localhost:4000 # 构建静态站点 bundle exec jekyll build # 输出到 _site JEKYLL_ENV=production bundle exec jekyll build # 带 live reload / drafts 的开发模式 bundle exec jekyll serve --livereload bundle exec jekyll serve --drafts

常用命令：jekyll new <path>建站、jekyll build构建到_site、jekyll serve构建并本地服务、jekyll clean清理生成文件、jekyll doctor检查配置问题；serve 选项包括--livereload、--drafts、--port <port>（默认 4000）、--host <host>（默认 localhost）、--baseurl <url>。

安全配置示例（_config.yml）：

exclude: - Gemfile - Gemfile.lock - node_modules - vendor

Markdown 处理器配置：

markdown: kramdown kramdown: input: GFM syntax_highlighter: rouge

支持的风格：Kramdown（默认）100%；CommonMark 与 GFM 通过 jekyll-commonmark / jekyll-commonmark-ghpages 插件；RedCarpet 已弃用。

5.7 基于 Hugo 的静态站点工作流

快速上手：

# 创建新站点 hugo new site mysite cd mysite git init git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke themes/ananke echo "theme = 'ananke'" >> hugo.toml # 创建内容 hugo new content posts/my-first-post.md # 开发服务器（含 drafts） hugo server -D # 构建到 public hugo hugo --minify

构建选项：-D, --buildDrafts（含草稿）、-E, --buildExpired（含过期内容）、-F, --buildFuture（含未来内容）、--minify（压缩输出）、--gc（构建后垃圾回收）、-d, --destination <path>（输出目录）。Server 选项：--bind <ip>、-p, --port <port>（默认 1313）、--disableLiveReload等。

安全配置示例（hugo.toml）：

[security] enableInlineShortcodes = false [security.exec] allow = ['^go$', '^npx$', '^postcss$'] [security.funcs] getenv = ['^HUGO_', '^CI$'] [security.http] methods = ['(?i)GET|POST'] urls = ['.*']

Goldmark 渲染配置：

[markup] [markup.goldmark] [markup.goldmark.extensions] definitionList = true footnote = true linkify = true strikethrough = true table = true taskList = true [markup.goldmark.renderer] unsafe = false # 设 true 允许原始 HTML

常见问题排查：路径 404 检查baseURL；主题不加载检查themes/或 Hugo Modules；原始 HTML 不渲染设unsafe = true；图片不加载检查static/目录结构。

5.8 安全总原则

无论使用哪种转换工具，技能都强调同一安全主线：转换工具默认不净化 HTML，面向不可信输入时必须在渲染链路末端增加净化环节（marked 配 DOMPurify、pandoc 用--sandbox、gomarkdown 配 Bluemonday）。

六、核心技能三：quasi-coder（准代码解释与实现）

完整技能定义位于 skills/quasi-coder/SKILL.md，定位是“专家级 10x 工程师技能”：从简写（shorthand）、准代码（quasi-code）和自然语言描述中解读意图并实现生产级代码，弥合不同技术背景协作者与专业代码实现之间的鸿沟。

6.1 触发时机

• 协作者提供简写或准代码；
• 收到可能含拼写错误或术语错误的代码描述；
• 与技术水平参差的团队成员协作；
• 将大方向想法转化为详细、可交付的实现；
• 将自然语言需求转化为功能代码；
• 将混合语言的伪代码解释为目标语言；
• 处理带有start-shorthand与end-shorthand标记的指令。

6.2 协作者技术水平评估

技能要求先评估协作者对工具、语言与最佳实践的掌握程度，再决定纠偏力度：

• 高置信度（90%+）：信任其技术合理的方案，仅做拼写/语法的小修正，按描述专业落地，仅在明显有利时提出优化；
• 中等置信度（30%-90%）：批判性评估方案、酌情提出更优替代、补齐缺失的错误处理与校验、应用其可能遗漏的专业模式；
• 低置信度（<30%）：补偿术语错误或误解、寻找达成目标的最佳路径、将描述翻译为正确技术实现、选用正确的库/方法/模式。

6.3 补偿规则（Compensation Rules）

1. 超过 90% 确定协作者方法不正确或非最佳实践 → 寻找并实现更优方案；
2. 超过 99% 确定协作者缺乏工具专业知识 → 补偿错误描述并使用正确实现；
3. 超过 30% 确定协作者描述有误 → 应用专家判断并做必要修正；
4. 对意图或需求不确定 → 先提出澄清问题再实现。

当方法明显次优时，始终把目标（goal）置于方法（method）之上。

6.4 简写语法规范

简写区块由语言注释标记包围：

• 起始标记：${language:comment} start-shorthand
• 结束标记：${language:comment} end-shorthand

例如 JavaScript：

// start-shorthand ()=> add validation for email field ()=> check if user is authenticated before allowing access // end-shorthand

简写指示符规则：

• 以()=>开头的行表示需要解释的简写：约 90% 是注释式意图描述、10% 是伪代码结构；
• 必须转换为实际可运行的代码；
• 实现时 ALWAYS 删除()=>行。

解释流程：通读整个简写区块 → 识别目标 → 评估技术准确性 → 确定最佳实现 → 用生产级代码替换简写行 → 为目标文件类型应用合适语法。

注释处理：REMOVE COMMENT表示最终实现中删除该注释；NOTE表示实现时需考虑的重要信息；自然语言描述转换为有效代码或适当文档。

6.5 完整示例：从简写到生产代码

协作者输入（JavaScript 文件）：

// start-shorthand ()=> create function that validates user input ()=> check email format is correct ()=> make sure password is at least 8 characters ()=> return true if valid, false otherwise // end-shorthand

步骤 1：评估水平——协作者知道需要校验，但使用通用词汇而非具体库名，评估为中等置信度（30%-90%）。

步骤 2：解读意图——目标：创建输入校验函数；需求：邮箱格式检查、密码长度检查；输出：布尔返回值。

步骤 3：专家级实现：

/** * Validates user registration input * @param {string} email - User email address * @param {string} password - User password * @returns {boolean} True if input is valid, false otherwise */ function validateUserInput(email, password) { // Validate email format using standard regex pattern const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; if (!emailRegex.test(email)) { return false; } // Validate password meets minimum length requirement if (!password || password.length < 8) { return false; } return true; }

专家决策要点：使用标准邮箱正则、补充 JSDoc、包含 null/undefined 检查、描述性函数名、返回布尔值、删除所有()=>简写行。

6.6 高级用法

混合语言伪代码：例如 Python 中()=> use forEach to iterate over users array应转为 Python 原生模式：

# Filter adult users from the users list adults = [user for user in users if user.get('age', 0) > 18]

非代码动作：简写可能请求运行命令、创建文件、抓取数据、生成图形等非代码动作，实现后同样删除简写行。

复杂多步逻辑：如登录检查 + 重定向 + 数据加载 + 错误处理的 TypeScript 流程，应转换为带鉴权检查、路由、数据获取与错误处理的完整实现。

6.7 陷阱规避清单

• 不要在任何文件中遗留()=>行；
• 不要盲目照搬错误的技术描述，要应用专家判断；
• 不要让简单请求过度复杂化；
• 不要忽略大方向，要理解目标而非单行；
• 不要居高临下，要尊重地翻译与实现；
• 不要跳过错误处理，即使未被提及也要补充专业级错误处理。

七、技能之间的协同关系

从 CMS 开发的实际任务流看，三项技能构成了一条完整链路：

1. content-management-systems负责回答“改哪里”——定位平台类别、负责接缝与最小改动方案；
2. markdown-to-html负责回答“内容怎么渲染”——处理创作内容到 HTML/静态导出的转换环节；
3. quasi-coder负责回答“描述怎么落地”——把产品/设计侧的非技术描述翻译为生产级代码；
4. web-coder提供前端、浏览器与 HTTP 基础能力，支撑上述工作流中涉及浏览器行为与网络交互的部分。

例如一个典型场景：在 WordPress 上开发自定义主题时，content-management-systems 指导你从模板层级与 hooks 入手、把创作媒体放在 uploads 风格路径；quasi-coder 把设计师的“准代码”备注转换为可用的 PHP 模板片段；而 markdown-to-html 则处理博客正文的 Markdown 渲染与静态导出管线。

八、插件元数据与仓库结构速览

• 插件清单： plugins/cms-development/README.md
• 插件元数据（名称、版本 1.1.0、关键词、技能挂载路径）：plugins/cms-development/plugin.json
• CMS 平台技能： skills/content-management-systems/SKILL.md
• 平台对照速查： skills/content-management-systems/references/cms-platform-workflows.md
• Markdown 转换技能： skills/markdown-to-html/SKILL.md
• 准代码实现技能： skills/quasi-coder/SKILL.md
• 插件体系总览与安装说明： docs/README.plugins.md

从 plugin.json 的keywords字段（cms、content-management-system、wordpress、shopify、drupal、theme、plugin、media、static-site）也可以印证该插件的定位边界：它不是一个通用 Web 开发插件，而是精确聚焦 CMS 领域的主题、插件、媒体与静态站点能力。该插件采用 MIT 许可证，属于 awesome-copilot 社区贡献的插件集合（README.md）的一部分，可通过上述 Copilot CLI 或 VS Code 方式直接安装使用。

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot