【免费下载链接】paperthinLow-level agentic design patterns. Turning old engineering wisdom into reflexes your agent reaches for on its own—on any agent.项目地址https://gitcode.com/gh_mirrors/pap/paperthin点击查看免费下载paperthin 是一套「低层 Agent 技能库」它把老工程师多年沉淀的工程直觉写成一条条 Agent 能主动调用的技能Skill。本文以 paperthin 为例带你从零写出第一个 Agent 技能先看懂SKILL.md 的四段式标准——Goal / Workflow / Rules / Verification再按步骤落地一个真实可用、干净可靠的技能。一句话定位一个技能 一个目录 一份SKILL.md。四段式就是这份文件的「骨架」写对了Agent 才知道做什么、怎么做、受哪些约束、怎么算完成。 先认识 paperthin把工程直觉写成 Agent 技能多数 Agent 被指着目标时倾向于「加东西」——更多文件、更多选项、更多样板。paperthin 反其道而行每一条技能都在做减法把「重写而不打补丁」「单一事实来源」「冷读自检」这类老工程智慧变成 Agent 会自动触发的条件反射。它的设计核心是四象限地图用「数量 × 时间」两条正交轴把技能分成四个视角perspective。你写第一个技能前先要给它选对「家」。目录关注点要回答的问题depth/把手头这一个产物做干净、做对这一个东西干净且为真吗breadth/让同一个事实在多处保持一致一份真相是否处处一致coil/跨构建周期传递学习每一轮是否教会了下一轮mesh/多个独立视角收敛多方是否收敛到真相 记住一句话技能按「它触发或产出的工作范围」归类而不是按它调用了谁。例如sip只守一个交付物所以归depth/即使它可能跨文件调用别的技能。 SKILL.md 骨架一个目录 四段式一个技能就是skills/视角/名字/SKILL.md。官方作者指南 AGENTS.md 里给出的标准骨架长这样--- name: kebab-name # 与目录名、调用名一致 description: 富含触发语的一句话 # disable-model-invocation: true ← 仅用户可调用的技能才加 --- 一句话这个技能做什么 ## Goal — 目标做到什么程度算好 ## Workflow — 编号步骤一步步怎么做 ## Rules — 约束哪些红线不能碰 ## Verification — 收尾前自检如何确认完成四段各司其职缺一段都不合格段落一句话作用新手最容易踩的坑Goal说明产出标准更轻、更新、更准写成「做个工具」这种空话Workflow可执行、可复现的编号步骤步骤之间顺序混乱、无法照做Rules边界与红线只做减法、不改无关处把「建议」当成「规则」写进Verification收尾前的验收检查 汇报改了什么漏掉「报告变更」这一步✍️ 五步写出你的第一个 SKILL.md第一步给技能选对目录perspective先问两个问题定「家」数量它作用在一个产物上depth/还是散在多处breadth/时间它只管当下还是跨多轮迭代coil/再为它取一个**「能一眼猜出作用」的名字**用一个朴实的真词如shower、sip或一个真实术语的紧凑缩写如re0、ssotize。陌生光看名字就该能半猜出它干什么——禁止生造晦涩词更禁止用模型/厂商品牌命名。第二步写好 frontmatter 头部三要素头部只有三个关键项缺一不可--- name: title-chk # 必须与目录名完全一致 description: Check a drafts title for clarity. Use when the user asks to review or improve a headline or document title. # disable-model-invocation: true ← 用户型技能才加 ---这里有一个新手最关键的抉择——谁来触发它详见 docs/invocation.md模型可调默认省略disable-model-invocation。description要写成「模型面向」保留触发语如Use when the user wants…这样 Agent 才会自动开火。仅用户可调加上disable-model-invocation: true。description改成「人类面向」的一句简介去掉触发列表。只有当「这个动作本该由人主动决定」时才这么用提交、发布、部署否则它的存在本身会带偏 Agent。第三步四段式逐段写Goal / Workflow / Rules / Verification下面用一个只读的「标题检查」技能title-chk走一遍帮你把四段填实--- name: title-chk description: Check a drafts title for clarity. Use when the user asks to review or improve a headline or document title. --- Check a title so a first-time reader grasps the topic and stakes in one pass. ## Goal The title must be specific, honest, and readable in a single pass. It should not promise what the body does not deliver. ## Workflow 1. Read the title, then read the body end to end before judging. 2. Name the concrete topic and the readers stake. 3. Check for vague words, hidden jargon, and promises the body does not keep. 4. Offer at most two alternatives that fix a real problem. ## Rules - A pass that finds no real problem changes nothing. - Never invent a punchier title the body cannot back. - Keep the change to words only; do not restructure the body. ## Verification Before finishing: 1. The title matches what the body actually says. 2. No vague or unbacked promise remains. 3. Report what changed and why, or state that nothing changed.四段写法要点速查Goal— 写「产出标准」不写「功能描述」。对照re0的写法结果必须比输入更轻、更新、更准且不能读起来像变更日志。Workflow— 编号步骤第一步永远是「先完整读一遍再动手」。步骤要能被一个没有上下文的人照做。Rules— 每条都是可判定的红线。paperthin 的招牌句反复出现一次什么都没改进的 pass就什么都不改克制即产品。Verification— 收尾前逐条打勾并汇报「改了什么 / 为什么」。只读技能也要报告「没改」是合法结果。第四步让它能「单独活」paperthin 的铁律是技能自包含一个技能可能被单独安装不带上兄弟技能所以运行期规则要内联写进本技能而不是指向 AGENTS.md 或别的技能。技能之间要协作用/skill式措辞调用如「运行/re0」禁止../跨目录硬引用。第五步发布前自检让脚本替你把关提交前跑 scripts/validate-skills.sh它会自动替你检查这些硬性标准——这也是 paperthin CI 的准入门槛检查项要求frontmatter必须是合法 YAML由 scripts/check-frontmatter.cjs 校验否则直接丢技能name必填且必须与目录名一致description必填且≤ 800 字符超了说明你写成了段落四段小节Goal/Workflow/Rules/Verification四个##缺一不可跨目录引用禁止出现../深层链接注册与目录需在plugin.json注册、在README列表中出现✅ 通过自检后用sip技能对自己刚写的技能「尝一口」再交付。 从两个真实样例看标准把两个风格迥异的技能放一起对比四段式的作用就一目了然模型可调的 skills/depth/re0/SKILL.mddescription满是触发语Use when the user asks to clean up, sync up, dedupe…让 Agent 在「清理、去重、改写」时自动开火Workflow里第 2 步就是「编辑前先通读」Verification要求「用陌生人的冷读视角再读一遍」。仅用户可调的 skills/depth/hate/SKILL.md头部级加上disable-model-invocation: truedescription改成人类面向的简介。它故意「不进模型视野」——否则一个随时可用的「拆台反射」会把 Agent 带向一味否定。 同一个骨架靠 frontmatter 的一行开关 description的写法差异就能切换「自动开火」与「人工开火」两种触发方式——这正是四段式头部设计的精髓。❓ 新手常见问题FAQQ1一个技能可以很长吗可以但要「克制」。paperthin 的哲学是减法——写不到改进的地方就一行不动。description有 800 字符软上限提醒你那是「描述」不是「段落」。Q2name为什么必须和目录名一致因为调用名、目录名、frontmatter 三者必须对齐校验脚本会逐一比对。对不齐/技能名就唤不起来。Q3我要写一个「提交 / 发布 / 部署」类技能该用哪种调用用仅用户可调加disable-model-invocation: true。这类动作本该由人拍板让模型自主触发只会引入偏见。Q4四段顺序可以调换吗不建议。Goal → Workflow → Rules → Verification是一条从「标准 → 做法 → 边界 → 验收」的固定心智路径校验脚本也按这四个##小节名逐一检查。 小结写出第一个 Agent 技能其实就是填满四段式选对目录perspective取一个「一眼懂」的名字写好头部name/description并决定谁来触发填实四段Goal 定标准、Workflow 给步骤、Rules 立红线、Verification 做验收让技能自包含用/skill措辞协作不硬引用兄弟目录跑一遍校验脚本用sip尝一口再交付。掌握这套 Goal / Workflow / Rules / Verification 标准你写出的就不是一次性提示词而是一条条 Agent 会主动伸手去拿、干净又可靠的长期技能。赞分享【免费下载链接】paperthinLow-level agentic design patterns. Turning old engineering wisdom into reflexes your agent reaches for on its own—on any agent.项目地址https://gitcode.com/gh_mirrors/pap/paperthin点击查看免费下载相关推荐如何写出你的第一个Agent Skill拆解OPC Skills的SKILL.md结构、脚本编排与依赖设计如何写出你的第一个Agent Skill拆解OPC Skills的SKILL.md结构、脚本编排与依赖设计 想让你的 AI 编程助手学会一项新本事本文以开源如何为 Jan Agent 编写 SKILL.md 可复用技能如何为 Jan Agent 编写 SKILL.md 可复用技能 如果你在 Jan Agent 里反复粘贴同一段流程说明——比如怎么打 release怎么人工智能AI 应用大模型本地部署桌面应用交互助手AI Agent如何编写你的第一个Antigravity Skills技能SKILL.md模板最佳实践完整教程如何编写你的第一个Antigravity Skills技能SKILL.md模板最佳实践完整教程 想为自己的 AI 代理扩展新能力 antigravity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考