行长优化器

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install line-length-optimizer
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 line-length-optimizer。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

行长优化器会检查正文文本的行宽（即每行的字符数），并在文本过宽或过窄时推荐实用的容器宽度。它采用桌面端每行 45–75 个字符、移动端每行 35–45 个字符的排版指导，并优先使用以 ch 为单位的 max-width，使宽度与字体相关，而不是依赖固定像素值。
这款 Openclaw Skills 工具可根据文本样本、CSS 尺寸，或在具备 Figma 访问权限时根据所选文本节点进行分析。它会报告采用的假设、每行字符数的估算值或测量值、结论及理由。它只会提出修改建议，不会擅自编辑文件或 Figma 节点；本工具适用于正文文本的换行，不适用于标题或单行 UI 文本。

应用场景

检查文章、博客文章或卡片描述，判断其文本栏是否易于阅读。
用户询问文本栏是否过宽或过窄时，评估相关段落。
根据桌面端和移动端的行宽指南，评估 CSS
max-width
、容器宽度和字号。
在提供文本块但没有现有布局尺寸时，推荐易读的
max-width
。
检查所选 Figma 文本节点，并识别固定宽度、自动宽度或文本截断行为。
比较桌面端和移动端的行宽，判断是否需要响应式宽度规则。

工作原理

读取可用输入。 使用提供的文本、CSS、尺寸、字号和目标设备。如果可以访问 Figma，请检查所选文本节点，而不是要求用户粘贴其内容。
估算每行字符数。 根据文本计算或估算平均行长，或者将 ch 宽度解读为大致的字符数目标。对于像素宽度，应考虑字号和字体，因为字形宽度各不相同。
与目标范围比较。 按每行 45–75 个字符评估桌面端文本，按每行 35–45 个字符评估移动端文本。将衬线字体的容差和字体特征作为背景因素，而不是单独的硬性限制。
给出结论和修正建议。 说明行宽是否在范围内、过宽或过窄，然后建议合适的 max-width 或宽度调整。除非现有代码库的惯例另有要求，否则优先使用 ch。
解释理由。 包含字符数估算、假设以及相关的桌面端／移动端注意事项。说明较窄的文本栏可能会加剧边缘参差或连字符断词问题。
将修改留待批准。 将 CSS 作为建议提供。只有在用户明确要求时，才编辑文件或调整 Figma 节点大小。

配置指南

SKILL.md 未指定软件包、安装程序、CLI 命令或必需的运行时依赖项。按照宿主的技能加载说明，将技能添加到 AI 编码代理使用的技能目录或配置中，然后向代理启用该技能。对文本或 CSS 进行审查不需要单独配置。
如需进行基于 Figma 的审查，请为代理提供 Figma MCP 或插件访问权限，并选中一个文本节点。直接调整节点大小是可选操作，且只有用户明确要求修正时才应执行；否则，请报告建议尺寸。

数据架构

该技能由指令驱动，不定义持久化数据存储、生成文件或机器可读的输出架构。审查过程中会使用以下信息：
输入或元数据 用途
文本块 估算或测量平均每行字符数。
CSS 宽度和字号 评估现有文本容器；已知 font-family 时可提高基于像素的估算准确度。
目标设备 选择桌面端、移动端或两者；默认报告两者。
Figma 文本节点属性 使用 textAutoResize、宽度、高度、字号和字体系列评估所选节点。
技能元数据 名称：line-length-optimizer；版本：1.1.0；状态：已接受；项目：Design Engineering Playbook。
响应会将结果整理为结论、测量或估算的每行字符数、具体的宽度建议，以及对计算过程的简要说明。默认不会写入文件。在 Figma 中，WIDTH_AND_HEIGHT 表示自动宽度文本，没有可供评估的固定行宽；NONE 和 HEIGHT 使用节点的固定宽度；对于 TRUNCATE，还需要标记被隐藏的溢出内容。

高级特性

响应式评估：
提供桌面端和移动端建议，并指出何时可能需要针对不同断点设置不同宽度。
考虑字体的估算：
ch
解释为近似字符宽度，并说明像素到字符数的估算会因字体、字号和字样而异。
Figma 节点检查：
利用文本自动调整大小行为和节点尺寸，区分固定宽度、自动宽度和截断文本。
明确修改的保护措施：
提出 CSS 和 Figma 调整建议，但不会擅自应用；直接编辑必须由用户提出请求。
考虑排版的建议：
指出较窄的行宽可能加剧边缘参差和连字符断词问题，并将标题和单行 UI 字符串排除在审查范围之外。

name: line-length-optimizer description: Use when checking or fixing the measure (line length) of a text block — verifying a paragraph or container sits in the 45–75 character range (35–45 on mobile) per Bringhurst/Latin readability guidance, and producing a max-width/ch fix. triggers: use_when: - user asks to optimize line length or "measure" - user asks for max-width for body text or a container - user pastes a paragraph and asks if the column is too wide/narrow - user asks for readable column width, desktop vs mobile do_not_use_for: - headings, labels, or single-line UI strings - full type-scale generation (see type-scale-generator) - vertical rhythm / spacing between blocks (see vertical-spacing) metadata: author: Monika Zapisek project: Design Engineering Playbook version: "1.1.0" status: accepted

Line Length Optimizer

Purpose

Check whether a block of body text sits within a comfortable reading measure, and produce a concrete CSS fix (max-width in ch or px) when it doesn't. Based on the standard typographic range: 45–75 characters per line on desktop, 35–45 on mobile (Bringhurst, Latin — see References).

When To Use

Reviewing a container/component that holds body copy (article, blog post, card description) for readable width.
The user pastes a paragraph and asks "is this column too wide?" or gives a max-width/font-size and asks if it's in range.
Not for headings, buttons, labels, or anything that's one line by design — measure only matters for wrapping prose.

Inputs

One of:

A CSS snippet or container width + font-size (compute expected characters-per-line), or
A block of text + a stated or assumed container width, or
Just a block of text with no width given — in that case, output the recommended max-width rather than judging an existing one.

Target device: desktop, mobile, or both (default: report both).

Outputs

Verdict: in range / too wide / too narrow, with the measured or estimated characters-per-line.
A concrete fix: max-width: NNch; (preferred — ch scales with font, unlike a fixed px) or an equivalent px value if the codebase doesn't use ch.
Change log explaining the math, not just the answer.

Questions

This skill is an audit, not an interview. Work in this order: read what the file or the input already says, report, then ask.

Ask only when a value can't be read and the answer would change the result. One question at a time.
Don't ask for anything the request already states or the file shows — say what you took and where it came from.

If the question can't be answered, state the assumption and carry on. Never stall the report on it.

Always ask before writing to a file or a Figma node.

Questions this skill may need:

The target device (desktop or mobile), when the container width doesn't make it clear. Without an answer, report both.

Workflow

Get characters-per-line.

If given a text block: count average characters per line (including spaces) across the paragraph, or estimate from total character count ÷ expected line count if it's reflowing.
If given max-width + font-size (+ font-family if known): estimate using ch unit semantics — 1ch ≈ the width of "0" in the given font, so max-width: 65ch targets ~65 characters regardless of font-size. If the input uses px instead of ch, note that the actual character count will vary by font and flag it as a reason to prefer ch.

Compare against target range.

Desktop: 45–75 characters, 65 is the commonly cited sweet spot (Bringhurst).
Mobile: 35–45 characters.
Serif body text tolerates the higher end of the range better than sans-serif at small sizes — note this as a soft factor, not a separate hard range.

Verdict + fix.

In range: confirm, no change needed.
Too wide: recommend max-width: 65ch; (or narrower, e.g. 60ch, if the content is dense/technical) on the text container.
Too narrow: recommend removing an over-tight max-width or padding, or increasing container width — narrow columns cause more line breaks and more ragged/hyphenation pressure, which interacts with microtypography's Rule 3.

If mobile and desktop diverge, recommend a responsive value: either two breakpoint-specific max-width values, or a ch-based value that already scales reasonably since mobile font-sizes are usually smaller too — call out if a media query is actually needed (e.g. desktop uses a much larger font-size, breaking the ch scaling assumption).

Report, don't silently edit a stylesheet. Output the CSS as a suggestion in the response; only apply it to a file if the user explicitly asks you to edit that file.

Figma Node Integration

When running with Figma access (Figma MCP / plugin context), read the selected node instead of asking the user to paste text:

textNode.textAutoResize — determines what "width" even means for this node:
NONE or HEIGHT → the node has a fixed width; read textNode.width (or the bounding box) directly and treat it as the measured container width.
WIDTH_AND_HEIGHT (auto-width) → there is no fixed measure to check; the box grows with content. Flag this instead of computing a verdict — recommend switching to HEIGHT (auto-height, fixed width) if the intent is a readable paragraph column, since auto-width text has no line wrap at all.
TRUNCATE → fixed width and height with the overflow cut off; measure the width as for NONE, and flag that part of the text is hidden.
textNode.fontSize and textNode.fontName.family — needed to convert a pixel width into an estimated character count (characters-per-line ≈ width in px ÷ average glyph width, which scales with fontSize and varies by typeface — monospace and condensed faces need a different divisor than a default sans).
Action back to Figma: if the fix is "too wide," the agent may resize the node's width directly (set textNode.resize(newWidth, textNode.height) or the equivalent plugin API call) to the pixel width corresponding to ~65 characters at the node's current fontSize/font — but only when the user has asked for a direct fix, not as a silent default. Otherwise, report the recommended width and let the user apply it.

Quality Checklist

Character count is stated explicitly (measured or estimated), not just "looks too wide."
Recommendation uses ch unless the codebase's existing convention is px/rem — match existing convention if shown in the input.
Desktop and mobile both addressed, even if the answer is "same value works for both, here's why."
Didn't touch headings, labels, or non-wrapping UI text — flag if the user's target isn't actually body prose.

If a fix is suggested for a real file, it's proposed, not silently applied, unless the user explicitly asked for a direct edit.

Noted the interaction with microtypography Rule 3 when the fix affects ragged-edge risk (narrower column → more hyphenation/rag pressure).

References

Bringhurst, R. (2012). The Elements of Typographic Style (4th ed.). Hartley & Marks — standard measure: 45–75 characters per line, 66 as the classic ideal.
Hochuli, J. (2008). Detail in Typography. Hyphen Press — how the eye scans a line, and why an optimal word count per line reduces reading fatigue.
Latin, M. (2017). Better Web Typography for a Better Web. — practical ch-based implementation for web body text, and the mobile 35–45 character range.
Figma Plugin API Docs: TextNode.textAutoResize.
Related skill: microtypography — apply after fixing measure, since a corrected column width changes where ragged-edge and hyphenation risks actually occur.
微排版
UI ROI 审计