Token导航 LogoToken导航

Agent Skill · 待分类

wpsnote-beautifier(wpsnote 美化器)

wpsnote-beautifier 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

wpsnote-beautifier 是待分类类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为调用外部服务;许可证信息还不明确,第三方扫描已通过,按安装量在待分类类的 11,209 个 Skill 里排第 9,754。

总安装 225周安装 9GitHub Stars 124下载 73核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:wpsnote-beautifier(wpsnote 美化器)
来源仓库:https://github.com/wpsnote/wpsnote-skills
仓库路径:skills/wpsnote-beautifier
安装命令:
npx skills add https://github.com/wpsnote/wpsnote-skills --skill wpsnote-beautifier
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/wpsnote/wpsnote-skills --skill wpsnote-beautifier

这个 Skill 是做什么的

这个 Skill 的分类还没最终确定,用法以来源仓库的说明为准。

该技能用于处理 wpsnote 相关的 GitHub 协作信息。适用于 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态与代码变更的场景。支持 Issue、Pull Request 和协作事项的整理。通过 GitHub 仓库安装,注意权限与文件操作风险。

建议结合原始 README 确认具体功能与使用边界。

来源仓库内路径:skills/wpsnote-beautifier

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/wpsnote/wpsnote-skills --skill wpsnote-beautif…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要调用外部服务,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

wpsnote-beautifier 怎么安装?

在终端执行 npx skills add https://github.com/wpsnote/wpsnote-skills --skill wpsnote-beautifier。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

wpsnote-beautifier 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

wpsnote-beautifier 需要什么权限?

权限级别是调用外部服务。该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

wpsnote-beautifier 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

wpsnote-beautifier 用的人多吗?

公开数据是累计安装 225 次,近一周安装 9 次,下载 73 次,GitHub 124 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

wpsnote-beautifier 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理待分类类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

待分类类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
infsh-cli

infsh CLI · Codex、Claude

4,374,576382权限未标注未明确未收录
ai-video-generation

AI 视频生成 · Codex、Claude

4,313,376382调用外部服务未明确有提醒
lark-openapi-explorer

云雀 OpenAPI 浏览器 · Codex、Claude

2,064,1209,011需要联网未明确有提醒
lark-workflow-standup-report

Lark 工作流程站立报告 · Codex、Claude

2,041,6328,978需要联网未明确通过
use-my-browser

使用我的浏览器 · Codex、Claude

1,848,49140操作浏览器未明确未通过
wpsnote-beautifier

wpsnote 美化器 · 本页

225124调用外部服务未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

WPS 笔记智能美化

概述

对 WPS 笔记进行智能美化,包括:结构层级优化、高亮块/分栏强调重点、配色方案应用、富文本样式写入。通过 WPS 笔记 MCP 工具(user-wpsnote)完成所有读写操作。

颜色克制总原则(最高优先级)

美化的核心目标是提升可读性,而非"让文档变得五颜六色"。必须遵守以下约束:

  1. 全文只用 1 种主色调 — 从配色方案中选定一个色系后,标题、加粗关键词、高亮块-要点、分栏-正面全部使用该色系,不混入其他色系
  2. 辅助色最多 1 种 — 仅用于"提示/注意"型高亮块(如黄色系),且全文该类型不超过 1-2 处
  3. 警告色按需使用 — 红色系仅在文档确实存在风险/警告内容时才使用,没有则不加
  4. 高亮块总数控制 — 全文高亮块不超过 3-5 个(短文档 1-2 个),类型不超过 2 种
  5. 分栏总数控制 — 全文分栏不超过 2-3 处,背景色使用同色系浅色
  6. 行内高亮极度克制 — 全文行内高亮不超过 5-8 处,颜色统一为 1 种
  7. 正文不上色 — 普通段落文字保持默认黑色,绝不给整段文字加颜色
  8. 宁少勿多 — 不确定是否需要加颜色/高亮时,选择不加

工作流程

Phase 1: 分析文档现状

必须先执行以下步骤,不要跳过:

  1. 调用 get_note_outline 获取笔记大纲(包含 block_id、类型、文本预览)
  2. 调用 read_note 读取全文 XML
  3. 调用 read_file 读取本 Skill 的 XML 参考文件(首次美化时)

分析要点:

  • 当前标题层级是否合理(是否全是 <p> 没有标题、标题层级跳跃等)
  • 是否存在大段纯文本缺乏视觉分隔
  • 是否有适合用高亮块强调的重点内容(结论、核心观点、警告、提示)
  • 是否有适合用分栏对比展示的内容(对比、并列关系、优缺点)
  • 现有格式元素(加粗、颜色等)的使用情况

Phase 2: 设计美化方案

根据分析结果,制定具体美化计划。向用户简要展示方案并确认后再执行。

方案应包含:

  1. 结构调整计划 — 哪些内容需要提升/降低标题层级,哪里需要增加分隔
  2. 强调元素计划 — 哪些内容用高亮块、哪些用分栏(严格控制数量,参照"颜色克制总原则")
  3. 配色方案选择 — 从预设方案中选择 1 个主色系(见 reference/color-schemes.md),全文统一使用该色系,不混用多个方案
  4. 颜色使用预算 — 明确列出:高亮块 X 个、分栏 X 处、行内高亮约 X 处,确保总量克制
  5. 预计操作数量 — 让用户对改动范围有预期

Phase 3: 执行美化

执行前必须刷新大纲: 每次写入前调用 get_note_outline 获取最新 block_id。

优先使用 batch_edit 批量执行,减少调用次数。执行顺序固定为:delete → replace → update_attrs → insert。

分批执行时,每批完成后重新获取大纲再继续。

Phase 4: 验证结果

  1. 调用 read_note 检查最终效果
  2. 确认层级结构正确、颜色一致、无格式错乱
  3. 向用户汇报完成情况

结构层级设计规则

标题层级规范

层级用途说明
<h1>文档主标题全文仅一个,位于开头
<h2>一级章节文档的主要板块划分
<h3>二级章节板块内的子主题
<h4>三级章节细分内容,按需使用
<h5>/<h6>极少使用仅在层级确实需要时

结构调整策略

扁平化文档(全是段落无标题):

  • 识别语义分界点(话题转换处)
  • 将领头段落提升为 <h2> 或 <h3>
  • 为无标题章节生成概括性标题

层级跳跃修复(如 h1 直接到 h4):

  • 补齐中间层级,或将深层标题上提

过深层级扁平化(超过 4 级):

  • 将 <h5>/<h6> 内容合并到上级或转为加粗段落

高亮块使用规则

适用场景与配色

场景背景色边框色推荐 emoji
核心结论/要点#E8F5E9#4CAF50✅ 或 💡
重要提示/注意#FFF3E0#FF9800⚠️ 或 📌
警告/风险#FFEBEE#F44336❗ 或 🚨
引用/摘要#E3F2FD#2196F3📖 或 💬
定义/术语#F3E5F5#9C27B0📝 或 🔍
最佳实践#E0F7FA#00BCD4⭐ 或 🎯

高亮块 XML 写法

<highlightBlock emoji="💡" highlightBlockBackgroundColor="#E8F5E9" highlightBlockBorderColor="#4CAF50">
  <p><strong>核心结论</strong></p>
  <p>这里是需要强调的重点内容。</p>
</highlightBlock>

使用原则

  • 全文总量限制:短文档(<20 block)1-2 个,中等文档(20-50 block)2-3 个,长文档(>50 block)最多 5 个
  • 一个章节内高亮块不超过 1 个,避免视觉疲劳
  • 高亮块内段落保持精简(1-3 段),不要把大段文字塞入
  • 同一篇文档内高亮块类型不超过 2 种(如只用"要点"+"提示"),避免出现 3 种以上不同配色的高亮块
  • 优先使用与主色调一致的"要点"型高亮块,"提示/警告"型仅在确实需要时使用

分栏使用规则

适用场景

场景栏数说明
优缺点对比2 栏左优右缺,配不同背景色
方案对比2-3 栏并列展示方案要点
概念并列2-3 栏相关但独立的概念并排
数据摘要2-4 栏关键指标并排展示

分栏 XML 写法

<columns>
  <column columnBackgroundColor="#E8F5E9">
    <p><strong><span fontColor="#2E7D32">优势</span></strong></p>
    <p>第一个优点说明</p>
    <p>第二个优点说明</p>
  </column>
  <column columnBackgroundColor="#FFEBEE">
    <p><strong><span fontColor="#C62828">劣势</span></strong></p>
    <p>第一个缺点说明</p>
    <p>第二个缺点说明</p>
  </column>
</columns>

使用原则

  • 每栏内容量大致均衡,避免一栏极长一栏极短
  • 分栏标题用加粗 + 颜色区分,颜色从主色系中选取(不引入新色系)
  • 全文分栏不超过 2-3 处,只在内容确实存在对比/并列关系时使用
  • 多个分栏尽量使用相同的背景色组合,保持视觉统一

颜色应用规则

标题颜色

通过 <span fontColor="..."> 包裹标题文字:

<h2><span fontColor="#1565C0">章节标题</span></h2>

标题颜色应全文统一:同级标题用同一颜色。

加粗文字颜色

关键术语、重点词汇使用加粗 + 颜色:

<p>这是一段文字,其中<strong><span fontColor="#D84315">关键概念</span></strong>被突出显示。</p>

行内高亮

对少量关键词使用背景高亮:

<p>使用 <span fontHighlightColor="#FFF9C4">核心方法</span> 实现目标。</p>

颜色使用原则

  • 正文保持默认黑色,绝不给普通段落上色
  • 全文仅 1 种主色(标题色 = 加粗色 = 高亮块主色 = 分栏主色,同属一个色系)
  • 同一语义角色(如所有 h2)使用同一颜色,不同级标题仅做深浅递进
  • 行内高亮(fontHighlightColor)全文统一为 1 种颜色,使用量不超过 5-8 处
  • 避免大面积使用高饱和度颜色,优先使用柔和色调
  • 不确定是否需要加颜色时,选择不加
  • 配色方案详见 reference/color-schemes.md,选定后全文统一,不混用多个方案

常用 XML 写入模板

详细的 XML 模板参见 reference/xml-patterns.md。


特殊场景处理

长文档(>50 个 block)

  1. 分段处理:按 <h2> 章节逐段美化
  2. 使用 read_section 读取单章节
  3. 每完成一个章节就验证,避免大规模回滚

已有格式的文档

  1. 保留用户已设置的格式,仅在无格式处添加
  2. 如用户要求"重新美化",则先分析现有配色再统一

纯文本文档

  1. 优先做结构化(加标题、分段)
  2. 再做美化(加颜色、高亮块、分栏)
  3. 这类文档改动最大,必须提前与用户确认方案

表格密集型文档

  • 表格本身不额外加颜色(保持可读性)
  • 在表格前后用高亮块做摘要/说明
  • 表格须整表替换,操作前仔细确认

关键约束

  1. block_id 随时可能变化 — 每次写入前必须通过 get_note_outline 刷新
  2. batch_edit 执行顺序固定 — delete → replace → update_attrs → insert(与数组顺序无关)
  3. anchor_id 只接受顶层 block ID — 容器内部(高亮块、分栏、表格内)的段落 id 不可用于写入
  4. 表格须整表替换 — 对表格 block 调用 edit_block(op="replace")
  5. 只读标签不可创建 — <img/>、<embed/>、<imageColumn/>、<tag> 无法通过 XML 创建
  6. 新建 block 不需要 id — 系统自动分配

平台分布

Codex

34.87%
按下载量换算25

Claude

28.62%
按下载量换算21

Cursor

19.04%
按下载量换算14

Gemini CLI

10.52%
按下载量换算8

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

调用外部服务

该 Skill 可能调用第三方服务、云服务或外部模型 API,使用前需要确认账号、额度、数据发送范围和服务条款。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills