夜雨聆风如果你想给 Claude 做自己的工作流插件，别先想功能。
先看目录结构。
Anthropic 这次开源的 knowledge-work-plugins 仓库，最有用的地方不是“它有 11 个插件”。真正有用的是：它把一个 Claude 插件该怎么组织，直接摆出来了。
一个典型插件长这样：
plugin-name/
├── .claude-plugin/plugin.json
├── .mcp.json
├── commands/
└── skills/
看起来很普通。
但这里面分工很清楚。
.claude-plugin/plugin.json 是插件说明。告诉 Claude 这个插件是谁、做什么、有哪些能力。
.mcp.json 是工具连接。比如 Slack、Notion、Jira、Figma、BigQuery。你要换成自己的工具栈，主要就是改这里。
commands/ 放显式命令。用户主动调用，比如产品管理插件里的 brainstorm，或者 README 里举的 /data:write-query。
skills/ 放自动触发的能力。Claude 判断当前任务相关时，会自己用这些说明。
这个区分很关键。
很多人做 agent，所有东西都往一个 system prompt 里塞。最后 prompt 越来越长，模型也越来越难判断什么时候该做什么。
Anthropic 的做法更像拆模块。
高频动作，放 commands。
领域判断，放 skills。
外部数据，放 connectors。
比如工程插件。
它的 skills/ 下面有 code-review、debug、architecture、incident-response、testing-strategy 等。code-review 不是只说“请认真审代码”。它明确写了要看安全、性能、正确性、可维护性，还给了输出格式。
debug 也一样。
它不是让 Claude “分析一下问题”。
它把流程拆成 reproduce、isolate、diagnose、fix。先复现，再缩小范围，再给假设，再修。
这就是技能文件的价值。
它不是知识库。
它是工作习惯。
产品管理插件也很典型。
write-spec 不是直接生成 PRD。它先要求理解功能，再收集用户问题、目标用户、成功指标、约束、历史方案。然后才写 Problem Statement、Goals、Non-Goals、User Stories、Requirements、Metrics、Open Questions。
这说明一个事：
好的插件，不是让 Claude 输出更长。
是让 Claude 少走错流程。
如果我要给自己的日常工作做插件，我会这么拆。
第一层，插件名叫 content-operator。
它不做泛内容写作，只做“从素材到发布”的内容流水线。
第二层，commands：
/content:topic-audit
/content:rewrite
/content:ai-check
/content:platform-adapt
/content:wechat-draft
这些是我明确要执行的动作。
第三层，skills：
skills/topic-diagnosis/SKILL.md
skills/style-money/SKILL.md
skills/style-tech/SKILL.md
skills/ai-fingerprint-check/SKILL.md
skills/xhs-compliance/SKILL.md
skills/wechat-formatting/SKILL.md
这些是判断规则。
比如什么是好选题，什么叫 AI 味，什么词小红书容易出问题，公众号排版要怎么处理。
第四层，connectors：
{
"notion": "选题库和历史文章",
"wechat": "公众号草稿箱",
"github": "技术项目上下文",
"gmail": "读者反馈和合作邮件"
}
注意，连接器不是越多越好。
只接会影响输出质量的工具。
如果一个工具只是“看起来很酷”，但不会改变决策，就别接。
做这种插件时，我会先写一个最小版本。
只保留 3 个东西：
一个 /content:rewrite 命令。
一个 style-money 技能。
一个 ai-fingerprint-check 技能。
先让它稳定产出一篇能发的文章。
等这个跑顺了，再加小红书适配、公众号草稿箱、封面图。
不要一上来就做全套。
插件的坑也在这里。
结构太容易抄，所以很多人会误以为“建目录 = 做插件”。
不是。
真正难的是把你的判断写清楚。
比如 code review 技能，难点不是列安全、性能、正确性这几个词。难点是告诉 Claude：遇到 PR 时，先看什么，哪些问题必须拦，哪些只是建议，输出该怎么排优先级。
写 spec 也一样。
难点不是 PRD 模板。
难点是让 Claude 先问清楚用户问题，不要一上来编需求。
所以我看这个仓库，最大的收获是：
别把插件当 prompt 包。
把它当你的工作流源码。
你平时怎么判断、怎么检查、怎么交付，都可以拆成 markdown 和 JSON。
这套东西没有代码，也不用构建。
但它会逼你回答一个更难的问题：
你自己的工作，到底有没有一套稳定方法？
