Token导航 LogoToken导航

Agent Skill · 前端设计

flowforge(flowforge 前端)

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

flowforge 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在前端设计类的 10,216 个 Skill 里排第 10,088。

总安装 186周安装 8GitHub Stars 29下载 65核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/wentong2022-arch/flowforge-skill --skill FlowForge

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态、代码变更或协作事项进行整理。通过 npx skills add 命令从指定仓库安装并使用。

安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。可结合来源仓库和原始 README 进一步核验具体用法。

来源仓库内路径:skills/flowforge

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

flowforge 怎么安装?

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

flowforge 支持哪些 AI 工具?

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

flowforge 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

flowforge 是免费的吗?

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

flowforge 用的人多吗?

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

flowforge 安全吗?

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

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

值得选的地方

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

先想清楚的地方

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

适不适合你

更适合

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

不太适合

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

前端设计类 Skill 对比

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

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
flowforge

flowforge 前端 · 本页

18629需要联网未明确通过

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

SKILL.md 原文

FlowForge — Draw.io Diagram Skill

Generate professional diagrams as draw.io XML files. Supports flowcharts, architecture diagrams, comparisons, mind maps, timelines, and more.

Usage

/FlowForge "OAuth 2.0 authorization code flow"
/FlowForge path/to/design-doc.md
/FlowForge "CI/CD pipeline" --type loop
/FlowForge "Monolith vs Microservices" --type compare --theme morandi
/FlowForge "System Architecture" --lang en

Workflow

Step 1: Understand Requirements

If given a document:

  1. Read the full document
  2. Identify 1–3 places that benefit from a diagram
  3. For each, list:

- Insert position (after which section) - Diagram topic (one sentence) - Recommended diagram type (see Diagram Type Reference below)

  1. Wait for user confirmation

If given a concept directly:

  1. Confirm the core message to convey
  2. Choose diagram type
  3. Proceed to Step 2

Step 2: Confirm Theme

If the user hasn't specified --theme, state:

Default theme: tech-blue (科技蓝灰). Other options: morandi, mint, terracotta, indigo. Want a different one?

Proceed after user confirms. For full theme definitions, see themes.md.

Step 3: Design Sketch (ASCII)

Produce an ASCII sketch showing:

  • All nodes with labels
  • Arrow directions and labels
  • Grouping/regions
  • Color role assignments (e.g., [primary], [accent], [neutral])
  • Approximate dimensions and layout direction

Example sketch:

Direction: left-to-right | Nodes: 4 | Type: flow

[primary] Code Commit  →  [process] Build  →  [process] Test  →  [accent] Deploy
                                                    ↓ (fail)
                                              [error] Alert

STOP — Wait for user confirmation or revision before proceeding to XML generation.

Step 4: Generate draw.io XML

  1. Select layout algorithm for the chosen type (see Layout System below)
  2. Compute all coordinates using the formulas and constants
  3. Apply theme colors from themes.md
  4. Use element templates from xml-reference.md
  5. Reference complete examples in examples.md for pattern matching
  6. Fix any issues found

Step 5: Save & Deliver

Save the .drawio file. Default path:

./diagrams/{diagram-name}.drawio

Or user-specified path. After saving, report:

Iteration

If the user wants changes after viewing:

  1. Read the current .drawio file
  2. Modify the XML per feedback
  3. Save as {name}_v2.drawio (preserve previous version)

Layout System

Global Constants

CANVAS_PAD    = 40       # padding from content to canvas edge
NODE_W        = 160      # default node width
NODE_H        = 50       # single-label node height
NODE_H_RICH   = 90       # node with title + bullet list
TITLE_H       = 28       # diagram title height
GAP_H         = 60       # horizontal gap between nodes
GAP_V         = 50       # vertical gap between nodes
DIAMOND_W     = 120      # decision diamond width
DIAMOND_H     = 80       # decision diamond height
GROUP_PAD     = 20       # padding inside dashed group boxes
FONT_TITLE    = 18       # diagram title font size
FONT_NODE     = 13       # node title font size
FONT_BODY     = 10       # node body/list font size
FONT_ARROW    = 9        # arrow label font size
STROKE_NODE   = 1.2      # node border stroke width
STROKE_ARROW  = 0.8      # arrow stroke width
ARC_SIZE      = 10       # rounded rect arc size
ARROW_SIZE    = 5        # arrowhead size

Adjust constants when needed:

  • If nodes > 6 in a flow, reduce NODE_W to 140 or GAP_H to 40
  • If labels are long, increase NODE_W up to 200
  • Rich nodes (title + list): use NODE_H_RICH instead of NODE_H

Layout Algorithms by Type

flow — Linear Flow (left-to-right)
x[i] = CANVAS_PAD + i × (NODE_W + GAP_H)
y    = CANVAS_PAD + TITLE_H + GAP_V

Canvas width  = CANVAS_PAD × 2 + n × NODE_W + (n-1) × GAP_H
Canvas height = CANVAS_PAD × 2 + TITLE_H + GAP_V + NODE_H

If n > 5, use snake layout — wrap to next row flowing right-to-left:

Row 0 (L→R): nodes 0..4
Row 1 (R→L): nodes 5..9
Row 2 (L→R): nodes 10..14

y[row] = CANVAS_PAD + TITLE_H + GAP_V + row × (NODE_H + GAP_V)
x[i] in even row = CANVAS_PAD + col × (NODE_W + GAP_H)
x[i] in odd row  = CANVAS_PAD + (4-col) × (NODE_W + GAP_H)
flow-vertical — Linear Flow (top-to-bottom)
x    = CANVAS_PAD + (Canvas width / 2) - NODE_W / 2
y[i] = CANVAS_PAD + TITLE_H + GAP_V + i × (NODE_H + GAP_V)
compare — Left-Right Comparison
VS_W = 50   # width of "VS" badge

Left column x  = CANVAS_PAD
Right column x = CANVAS_PAD + NODE_W + GAP_H + VS_W + GAP_H
VS badge x     = CANVAS_PAD + NODE_W + GAP_H

Header y = CANVAS_PAD + TITLE_H + GAP_V
Row y[j] = Header y + NODE_H + GAP_V/2 + j × (NODE_H + GAP_V/2)

Each side has a header node (title) and content rows below.

layers — Layer Stack
LAYER_W = 400

x = CANVAS_PAD + (canvas center offset)
y[i] = CANVAS_PAD + TITLE_H + GAP_V + i × (NODE_H_RICH + GAP_V/3)

Canvas width  = CANVAS_PAD × 2 + LAYER_W
Canvas height = CANVAS_PAD × 2 + TITLE_H + GAP_V + n × NODE_H_RICH + (n-1) × GAP_V/3

Layers span full width. Top layer = highest abstraction.

loop — Cycle / Feedback Loop

Arrange N nodes in a rectangular path (clockwise):

For 4 nodes (most common):

Positions:
  [0] top-left:     (CANVAS_PAD, CANVAS_PAD + TITLE_H + GAP_V)
  [1] top-right:    (CANVAS_PAD + NODE_W + GAP_H × 2, same y)
  [2] bottom-right: (same x as [1], y + NODE_H + GAP_V)
  [3] bottom-left:  (same x as [0], same y as [2])

Arrows: 0→1 (top), 1→2 (right), 2→3 (bottom, R→L), 3→0 (left, bottom→top)

For N nodes: distribute evenly across 4 sides of a rectangle.

tree — Tree / Hierarchy
Level spacing = GAP_V × 1.5
Sibling spacing = NODE_W + GAP_H / 2

Root: centered at top
Children: evenly distributed below parent, centered under parent

Subtree width = max(sum of children subtree widths, NODE_W)
Parent x = leftmost child x + (rightmost child x + NODE_W - leftmost child x) / 2 - NODE_W / 2
hub — Hub and Spoke (Center Radiate)

Center node at canvas center. Spokes at equal angles.

Lookup table (use these positions instead of computing cosines):

N spokesPositions relative to center (dx, dy)
3(0, -R), (R×0.87, R×0.5), (-R×0.87, R×0.5)
4(0, -R), (R, 0), (0, R), (-R, 0)
5(0, -R), (R×0.95, -R×0.31), (R×0.59, R×0.81), (-R×0.59, R×0.81), (-R×0.95, -R×0.31)
6(0, -R), (R×0.87, -R×0.5), (R×0.87, R×0.5), (0, R), (-R×0.87, R×0.5), (-R×0.87, -R×0.5)

Where R = 180 (radius). Spoke node position:

x[i] = cx + dx[i] - NODE_W / 2
y[i] = cy + dy[i] - NODE_H / 2
columns — Parallel Columns
Column x[i] = CANVAS_PAD + i × (NODE_W + GAP_H)
Header y     = CANVAS_PAD + TITLE_H + GAP_V
Item y[j]    = Header y + NODE_H + GAP_V/2 + j × (NODE_H + GAP_V/3)

Each column has a header node (colored) and vertically stacked item nodes below.

matrix — Comparison Matrix
CELL_W = 140
CELL_H = 45
HEADER_H = 40

Col header x[c] = CANVAS_PAD + HEADER_W + GAP_H/3 + c × (CELL_W + GAP_H/3)
Row header y[r] = CANVAS_PAD + TITLE_H + HEADER_H + GAP_V/3 + r × (CELL_H + GAP_V/3)
Cell (r,c): x = Col header x[c], y = Row header y[r]
funnel — Funnel
MAX_W = 360
MIN_W = 120

w[i] = MAX_W - i × ((MAX_W - MIN_W) / (n - 1))
x[i] = CANVAS_PAD + (MAX_W - w[i]) / 2
y[i] = CANVAS_PAD + TITLE_H + GAP_V + i × (NODE_H + GAP_V / 3)

Centered, decreasing-width bands stacked vertically.

timeline — Timeline
LINE_Y = canvas vertical center
Node spacing = NODE_W + GAP_H

Event nodes alternate above and below the timeline:
  Above: y = LINE_Y - NODE_H - GAP_V/2
  Below: y = LINE_Y + GAP_V/2
  x[i]  = CANVAS_PAD + i × (NODE_W + GAP_H)

Draw a horizontal line at LINE_Y spanning full width.
Draw vertical ticks from line to each node.
sequence — Sequence Diagram
LIFELINE_GAP = 180
MESSAGE_GAP  = 50
PARTICIPANT_Y = CANVAS_PAD + TITLE_H + GAP_V
PARTICIPANT_W = 140
PARTICIPANT_H = 40

Participant x[i] = CANVAS_PAD + i × LIFELINE_GAP
Lifeline: vertical dashed line from bottom of participant box downward

Message y[j] = PARTICIPANT_Y + PARTICIPANT_H + GAP_V + j × MESSAGE_GAP
Messages: horizontal arrows between lifelines

Diagram Type Reference

Core Types

TypeCodeBest ForExample
Linear FlowflowSequential steps A→B→CAPI call flow, data pipeline
Vertical Flowflow-verticalTop-down processesDecision process, approval chain
ComparisoncompareA vs B side by sideTraditional vs AI approach
Layer StacklayersTech stack, tiersSystem architecture layers
CycleloopIterative processesML training loop, CI/CD
TreetreeHierarchies, taxonomiesOrg chart, decision tree
Hub & SpokehubCore concept + branchesProduct feature map

Extended Types

TypeCodeBest For
Parallel Columnscolumns3+ parallel concepts
MatrixmatrixMulti-dimension comparison
FunnelfunnelFiltering, conversion
TimelinetimelineVersion evolution, history
SequencesequenceComponent interactions

Selection Guide

Content PatternRecommended Type
Sequential stepsflow or flow-vertical
Two things comparedcompare
3+ parallel conceptscolumns or hub
Layered systemlayers
Iterative/cyclical processloop
One core, many brancheshub or tree
Components communicatingsequence
Change over timetimeline
Multi-criteria evaluationmatrix
Progressive filteringfunnel

Quality Checks

Before delivering the .drawio file, verify ALL of the following. Fix any failures before saving.

Layout Checks

  1. No overlapping nodes — For every pair of nodes, their bounding boxes must not intersect. Verify: |x1 - x2| >= width OR |y1 - y2| >= height.
  2. Canvas large enough — No node extends beyond: max(x + w) + CANVAS_PAD <= CANVAS_W and max(y + h) + CANVAS_PAD <= CANVAS_H.
  3. Consistent spacing — Gaps between adjacent nodes should match GAP_H / GAP_V (±10px tolerance).
  4. Alignment — Nodes in the same row share the same y. Nodes in the same column share the same x.

Text Checks

  1. Text fits in node — Estimate: Chinese characters ≈ 14px each at font 13; English characters ≈ 8px each. If text width > node width - 20px padding, either widen the node, reduce font, or add <br> line breaks.
  2. Minimum readability — No font size below 9px. No node smaller than 80×30.

XML Checks

  1. All arrow targets exist — Every source="X" and target="Y" must match an id="X" / id="Y" defined as a vertex.
  2. Unique IDs — Every id attribute is unique across the entire XML.
  3. Correct parent — All content elements have parent="1" unless intentionally grouped.
  4. Valid XML — Well-formed, all attributes quoted, HTML entities escaped (< > & ").

Style Checks

  1. Theme consistency — All fill/stroke/font colors come from the selected theme. No ad-hoc hex values.
  2. Arrow routing — Arrows use orthogonal routing only (horizontal + vertical). No diagonal arrows. Return arrows route around the outside, never crossing through unrelated nodes.

Color Usage Principles

This is the most important section for visual quality.

The 4+6 Rule

Each theme has 4 base colors and 6 extended colors:

  • Base 4: primary, process, accent, neutral
  • Extended 6: success, warning, error, secondary, storage, group

Blue (primary + process) should always be the dominant color family, but the amount of non-blue accents should scale with diagram size.

Color Budget by Diagram Size

Node CountTarget ColorsGuideline
3-5 nodes2-3 colorsBlue dominates. At most 1 accent node.
6-8 nodes3-4 colorsBlue ~60%. Add 1-2 non-blue at semantic turning points.
9+ nodes4-5 colorsBlue ~50%. Distribute 2-3 non-blue for visual rhythm.

6+ colors almost always looks bad regardless of diagram size.

Color Assignment Strategy

  1. Blue dominates — primary and process should cover the largest visual area and the biggest nodes.
  2. Accent is a scalpel, not a paintbrush — Use accent for at most 1-2 key highlights. Never on the largest node.
  3. Scale with length — A 4-node flow with 2 colors looks clean. A 9-node flow with only 2 colors is a monotonous wall. Add non-blue colors at natural semantic boundaries to create rhythm.
  4. 3-consecutive guideline — Avoid more than 3 adjacent nodes in the same color. If you spot 4+ consecutive blue nodes, promote the most semantically distinctive one to a non-blue color.
  5. Distribute spatially — Non-blue nodes should be spread across the diagram (top/middle/bottom), not clustered in one region.

Semantic Color Heuristics

When deciding which nodes get non-blue colors, use this table:

Node TypeRecommended Color
User input / starting pointprimary
Standard processing stepprocess
Decision / branching pointwarning or accent
Domain-specific / translation stepsecondary
Key transformation / highlightaccent
Data source / external systemneutral
Error path / fallbackaccent or error
Successful output / endpointsuccess or primary
Database / storagestorage

Examples

Bad (rainbow — every node a different color):

[neutral] 数据源 → [process] 整理 → [warning] 检查 → [success] 清洗 → [error] 告警 → [storage] 入库

Bad (wall of blue — 9 nodes all the same):

[primary] 提问 → [process] 校验 → [process] 评估 → [process] 翻译 → [process] 执行 → [process] 解读 → [process] 可视化 → [process] 标注 → [primary] 返回

Good (short flow, 2-3 colors):

[neutral] 数据源 → [process] 整理 → [process] 检查 → [process] 清洗 → [primary] 入库
                                        ↓ (异常)
                                  [accent] 告警处理

Good (long flow, 4-5 colors with rhythm):

[primary] 提问 → [process] 校验 → [warning] 评估 → [secondary] 翻译 → [process] 执行 → [process] 解读 → [accent] 可视化 → [process] 标注 → [success] 返回

Design Principles

  1. Narrative titles — Use "How OAuth 2.0 Authorizes a User" not "OAuth 2.0 Diagram".
  2. Bilingual labels — Use the user's language. Technical abbreviations (API, LLM, CI/CD) stay in English regardless.
  3. Orthogonal arrows only — All arrows run horizontally or vertically, no diagonals. Always include edgeStyle=orthogonalEdgeStyle; in every arrow's style attribute.

Gotchas — Common Failure Points

These are the most common mistakes when generating draw.io XML. Check for these first when debugging.

  1. Rich node text overflow — The <b>Title</b> inside a rich node uses a separate text cell. If you put the title in the value attribute of the background rect AND in a text cell, the title renders twice. Use value="" on the background rect.
  2. Arrow ignores exit/entry points — If you omit exitX/exitY/entryX/entryY from the arrow style, draw.io auto-routes, which often looks wrong. Always specify explicit exit/entry points.
  3. HTML entities in value attributes — value attributes use HTML, so < must be <, > must be >, & must be &. Missing escapes break the entire XML. The most common miss: &bull; in bulleted lists — use &bull; when inside an attribute.
  4. Dashed group box covers its children — If a dashed group box is defined AFTER its child nodes in the XML, it renders on top and hides them. Always define group boxes BEFORE their child elements.
  5. Canvas too small — pageWidth/pageHeight that are too small cause nodes to be cut off in the exported image. Always compute from layout formulas: max(x + w) + CANVAS_PAD.
  6. Forgetting parent="1" — Every content element must have parent="1". Missing this silently breaks the node.
  7. Diamond text overflow — Diamond/rhombus shapes have less usable area than rectangles. Keep labels to 2-3 short words. Use font size 11 instead of 13.
  8. Snake layout wrong arrow direction — In snake layouts (flow with >5 nodes), the wrap-around arrow must exit from the bottom of the last node in row N and enter the top of the first node in row N+1, not go sideways.
  9. Cycle arrow goes through center — In loop diagrams, the return arrow (last→first) must route along the outside of the rectangle, not diagonally through the center.
  10. Coordinate calculation off-by-one — When computing n items: there are n nodes but n-1 gaps. Canvas width = PAD×2 + n×NODE_W + (n-1)×GAP_H, not n×GAP_H.
  11. Diagonal arrows on branching/merging — When a centered node branches to two side-by-side targets, exit/entry points are not aligned vertically. Without edgeStyle=orthogonalEdgeStyle; in the style, draw.io renders these as diagonal lines. Always include it in every arrow.

Initial Setup

On first invocation, check if config.json exists in the skill directory. If not, ask the user:

  1. Default theme — Which color theme to use by default? (tech-blue / morandi / mint / terracotta / indigo)
  2. Output directory — Where to save .drawio files? (default: ./diagrams/)
  3. Language — Primary language for labels? (zh / en / auto-detect)

Save responses to config.json:

{
  "defaultTheme": "tech-blue",
  "outputDir": "./diagrams",
  "language": "auto"
}

On subsequent invocations, read config.json and apply defaults. User can override per-invocation with --theme, --lang flags.


Supporting Files

The skill directory contains these files. Read them when needed — don't load everything upfront.

FileWhen to read
themes.mdWhen applying colors — has all 5 themes with 10 semantic colors + 7 text colors each
xml-reference.mdWhen writing XML — canvas boilerplate, 8 element templates, arrow direction table
examples.mdWhen generating a diagram — 3 complete XML examples with coordinate calculations

| config.json | On every invocation — user preferences (created on first run, see Initial Setup) |

Example .drawio files (in examples/)

These are real, working .drawio files you can read as reference when generating similar diagram types:

  • examples/flow-cicd.drawio — Linear flow, 4 nodes, tech-blue theme
  • examples/compare-monolith-vs-micro.drawio — Comparison, 2 columns × 3 rows, morandi theme
  • examples/loop-ml-training.drawio — Cycle, 4 nodes clockwise, mint theme

平台分布

Codex

33.26%
按下载量换算22

Claude

32.27%
按下载量换算21

Cursor

18.73%
按下载量换算12

Gemini CLI

9.29%
按下载量换算6

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

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

继续浏览同类 Skills