免费在 GitHub 公开中文介绍

table-fit

让比较结果和对应关系在约100列宽的终端中易于阅读，将Markdown表格限制为最多四列、单元格使用短语，较长说明改用列表或逐项标题。

原文查看原文说明

Keep a Markdown table readable in a narrow terminal of about 100 display columns - a wide table or one carrying prose in its cells wraps into unreadable ragged rows. Always call read_skill for bundled:table-fit before emitting a Markdown table in a final answer, and load it as soon as the answer starts forming as a comparison, a mapping, a feature matrix, a pros-and-cons, an options rundown, or a per-item summary across several dimensions. Do not load it for a table already inside a file being edited, for code, data, or test fixtures that merely look tabular, for tables the user pasted for you to read, or for an answer with no table and no tabular shape forming.

asgeirtj/system_prompts_leaks

实测评分未实测

查看安装方法

适用场景

在窄终端中阅读比较结果
制作标志与效果的对应表
将含长篇说明的表格改成列表
按项目标题整理详细比较

中文介绍

功能

table-fit用于整理终端回答中的表格，减少换行导致的布局混乱。它以约100列的显示宽度为前提，将Markdown表格限制为最多四列，标签列也计入其中，每个单元格只放简短短语。说明需要完整句子时改用列表；多个方面都需要详细解释时，则为各个项目设置标题。

适用场景

适合比较多个选项或功能，也适合列出设置项与含义的对应关系。如果回答因表格过宽，或单元格塞入过多长篇说明而难以阅读，也可以用它重新整理呈现方式。

使用示例

“把这些选项的比较整理成窄终端也容易阅读的形式。”
“用简短的对应表列出各个标志及其效果。”
“说明较长的项目，请分别用标题整理。”

注意事项

此技能未配置为供用户直接调用，而是由代理在最终回答需要输出表格时加载。不适用于正在编辑的文件内的表格、粘贴给代理阅读的表格，以及只是外观类似表格的代码或数据。它不会测量实际屏幕宽度，也避免通过截断内容或使用难懂的缩写来压缩宽度。

本介绍由 AI（OpenAI Codex）根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果（实测对比）。

安全性发送数据、删除文件、执行命令等是否有说明: A良好指令仅调整回答的呈现形式，不包含对外发送或修改文件的操作。
安装难易度所需工具和 API 密钥是否少且有说明: A良好未要求额外工具或凭据，并明确无需测量实际终端宽度。

不计入评分。由 AI（OpenAI Codex）于 2026年10月24日评估。仅供参考，安装前请同时查看原文。

如果您认为评估有误，请申请复核

包含的文件（1）

SKILL.md3.0 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Table Fit

The answer is read in a terminal about 100 display columns wide. A table wider than that wraps every row, and wrapped rows lose the column alignment that made the table worth using. So a table only pays for itself when it stays narrow.

Two budgets, both hard:

At most 4 columns. The label column counts as one.
Every cell a short phrase. Never a sentence, never prose.

If the content fits both, use the table. If it does not, do not shrink the font of the problem by abbreviating into unreadable shorthand, and do not let the table run wide. Switch shape instead.

When the content will not compress

Use one of these instead of a table. Neither is a lesser answer; for prose-heavy content they are the better one.

A list — when each item needs a sentence or two:

- **tokio** — the default. Widest ecosystem, work-stealing scheduler, heaviest
  dependency tree. Pick it unless you have a specific reason not to.
- **smol** — small and readable. Fewer integrations, so you write more glue.

Short per-item headings — when each item needs several dimensions covered in prose:

### tokio
Maturity: production-default across the ecosystem.
Tradeoff: large dependency graph and a heavier compile.

### smol
Maturity: stable, much smaller surface.
Tradeoff: fewer ready-made integrations.

Choosing

Count the dimensions the answer actually needs, then look at the longest value any cell would hold.

4 or fewer dimensions, all values short phrases → table.
More than 4 dimensions → drop the least useful ones to reach 4, or use per-item headings.
Any dimension whose values run to sentences → list or per-item headings, even if there are only two columns.

A mapping with short values on both sides — a key to its meaning, a type to its size, a flag to its effect — is the case tables are for. Keep those as tables.

Do not

Do not measure or ask for the real terminal width. The budget is static. Width is per-connection and transient, and must not enter durable context.
Do not keep a table and simply truncate cells; losing the content is worse than losing the table.
Do not restate the table as prose underneath it. Pick one shape.
Do not add a table to an answer that did not need a visualization at all. A single fact, a one-step action, or a simple edit stays prose.

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能