Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/lipu-jpg/openwrite/text-processingnpx skills add LiPu-jpg/Openwrite --skill text-processinggit clone --depth 1 https://github.com/LiPu-jpg/OpenwriteWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00039 | $0.01186 |
| Opus 5 | $0.00019 | $0.00593 |
| Sonnet 5 | $0.00008 | $0.00237 |
| Haiku 4.5 | $0.00004 | $0.00119 |
Grade A, and why
text-processing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
文本处理系统
处理长文本，包括智能切割和渐进压缩。
核心概念
切割（chunking）：
- 按章节边界智能切割
- 默认 3万字/chunk
- 超长章节自动二次切割
压缩（compression）：
- 章 → 节 → 篇 三级压缩
- 保留关键信息和叙事逻辑
- 支持解压缩回原貌
可用工具
| 工具 | 说明 |
|---|---|
chunk_text |
将大文本切割为chunk |
compress_section |
压缩节/篇摘要 |
使用示例
切割大文本
用户: 这个100万字的文件太大了，切割一下
AI:
[COMMAND] chunk_text {
"file_path": "/path/to/novel.txt",
"chunk_size": 30000
}
结果:
- 总块数: 34
- chunk_1: 第1-5章, 28500字
- chunk_2: 第6-10章, 31200字
- chunk_3: 第11-15章, 29800字
...
压缩节摘要
用户: 压缩一下"修炼篇"的内容
AI:
[COMMAND] compress_section {
"arc_id": "arc_001"
}
结果:
- 篇: arc_001 (修炼篇)
- 压缩后: 1200字
- 压缩比: 15:1
- 内容: 主角从普通人成长为筑基修士...
压缩单个节
用户: 第一节的内容太多了，帮我压缩
AI:
[COMMAND] compress_section {
"arc_id": "arc_001",
"section_id": "sec_001"
}
结果:
- 节: sec_001 (师门试炼)
- 压缩后: 500字
- 压缩比: 8:1
切割规则
识别的章节格式
第X章/第X节/第X回Chapter X/CHAPTER X序章/楔子/尾声/番外
切割优先级
- 按章节边界切
- 不拆开单个章节
- 超长章节按段落切
压缩级别
| 级别 | 范围 | 压缩比 | 用途 |
|---|---|---|---|
| 节压缩 | ~5章 | 5:1 | 上下文窗口 |
| 篇压缩 | ~20章 | 15:1 | 大纲回顾 |
| 卷压缩 | 全书 | 50:1 | 整体概要 |
发送前分级压缩
ContextBuilder 的总预算由 OPENWRITE_CONTEXT_TOKENS 控制，默认 64K，软件
允许范围为 12K–512K。超限时使用 tiered-hierarchical-v2：
| 级别 | 优先处理 | 必须保留 |
|---|---|---|
| L1 | 可重建的旧章节记忆 | 精确上文、作者意图、创作罗盘、当前章 |
| L2 | 大纲摘要和窗口 | 当前章及其前后邻章 |
| L3 | 真相运行态、次要人物、精确上文长度 | 高相关人物和关键状态变化 |
| L4 | 最小工作集硬适配 | 在正常最小预算内保留核心控制面 |
每一级后重新估算；最终估算必须不高于配置预算。压缩只影响本次请求的深拷贝，
不得改写 src/、完整正文、节/篇持久化摘要或 JSONL 会话原始记录。
使用场景
场景1：处理长参考文件
用户: 参考作品有80万字，怎么处理？
AI: 先切割再逐块分析
[COMMAND] chunk_text {
"file_path": "参考作品.txt",
"chunk_size": 30000
}
场景2：管理长上下文
用户: 前50章的剧情太长了，摘要一下
AI: 压缩到篇级别
[COMMAND] compress_section {
"arc_id": "arc_001"
}
场景3：查看节概要
用户: 第二篇的剧情发展是什么？
AI:
[COMMAND] compress_section {
"arc_id": "arc_002"
}
压缩内容保留
压缩时保留：
- 主要角色的关键决策
- 重要的剧情转折点
- 伏笔的埋设和回收
- 世界状态的重要变化
压缩时舍弃：
- 场景描写细节
- 次要角色的日常
- 重复的描述
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 164 lines · 39 tokens per session scan A 761425ae2f33
text-processing is a skill published in the GitHub repository LiPu-jpg/Openwrite (672 stars, last pushed 5d ago), licensed Apache-2.0. It adds 39 tokens to every session and 1,186 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
awesome-novel
和 AI 协作写小说的工作流系统。9 个 agent 协作完成从设定到归档的完整写作流程。入口检测 → 初始化/迁移 → 交 novel-agent 调度。适用场景：从零写新小说、导入已有小说。.
workflow-producer
Skill "workflow-producer" from dongbeixiaohuo/writing-agent, covering 工作流导演 (workflow producer), ⚠️ 第一条规则：先确定模式，但不重复询问, 第二条规则：使用 subagent 执行任务, 第三条规则：风格必须显式确认，禁止代选 and 第四条规则：v2 协议是唯一机器契约源.
style-modeler
只根据用户提供或明确允许获取的样本建模。把作者身份用于样本分组和风格库检索，不把外部履历、既有印象或样本之外的观点写进风格档案。.
web-article-extractor
使用隔离的 Chrome DevTools MCP 从博客、新闻、公众号等网页提取正文，返回结构化内容，或保存 Markdown 和远程图片。用户要求提取文章、抓取网页正文、保存为 Markdown、下载文章图片或排查正文选择器时调用。.
clarity
Draft, rewrite, or review reader-facing prose so it is specific, useful, and recognizably the author's without inventing facts or performing humanness. Use for essays, articles, newsletters, documentation, talks, launch copy, and other important prose that feels generic, hollow, or AI-shaped. Supports co-write…
predict
Estimate likely 24-hour post performance from the user's historical data. Use after the user writes a post and wants a range estimate, upside view, or expectation check.