停止重复自己。停止重复自己。真的——把它放进一个 Skill。

I’m happy to translate the article for you, but I’ll need the full text of the post. Could you please paste the content you’d like translated (excluding the source link you already provided)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown syntax, and any code blocks or URLs.

介绍

在我上一篇文章中，我谈到了 工作流即工作本身，以及设计流水线比任何单个提示都更重要。我仍然坚持这一观点。但我现在已经进入了下一层洋葱：当流水线本身变得重复时会怎样？

实验

我在五个项目中使用 Claude Code：

不同的语言、不同的领域，但显然有非常相似的使用习惯——我直到提问才注意到。

引发一切的提示

Chintan Turakhia 发了一条推文：
“经常运行此提示。别客气。”

scrape all of my claude sessions on this computer. give me a breakdown
of all the things i do, things that are worth making into skills vs
plugins vs agents vs claude.md

我运行了基本相同的提示（我的版本有几个拼写错误）。思路很简单：让 Claude Code 自我审视，读取我所有的会话，找出我因为太熟悉而看不见的模式。

Claude 并行生成了三个子代理：

1. 全局配置与插件探索器 – 检查我的全局配置。
2. 仓库爬虫 – 遍历每个仓库，读取所有 CLAUDE.md 和 AGENTS.md。
3. 项目特定分析师 – 深入各个项目的架构和规范。

大约一分钟后，它们共同绘制出了我的整个 Claude Code 生态系统。

Source: …

发现：验证与尴尬

验证

• 我有一个 特性规划流水线：openspec 提案 → beads 拆解 → worktree → 实现 → 合并 → 清理。
• 我使用了 复杂的代理团队模式，包括类型化代理和上下文感知的重生机制。
• 我拥有一个 审查流水线，配备了专门的安全、架构和代码质量专家代理。

这些都是 真实 的工作流，并且能够正常运行。

尴尬

• 我几乎在每一次会话中 重复相同的基本规则：
  • “绝不使用 Python。”
  • “始终使用 Bun。”
  • “使用 Claude Code 的原生工具，而不是 sed/awk。”
  • “代理必须频繁提交，但不能相互覆盖。”
  • “所有特性都必须以 openspec 开始。”

这些规则散落在每个项目的 AGENTS.md 文件中，每当 Claude 忘记时又会在行内重复，而且有时在不同仓库之间 相互冲突。我在真实的 token 和时间上不断重复自己，对一个“工作流工程师”来说，这种情况颇为讽刺。

立即行动

我查看了分析并立即采取行动，未中断会话：

计划

• 将推荐的内容添加到全局 claude.md 中，并从各项目中移除。
• 在 ~/repos/ 中创建一个新项目，用于托管所有推荐的插件。
• 实现 openspec-and-beads 技能。
• 实现 agent-team 技能。
• 编写包含已实现技能和待办列表的完整 README。

注意： 暂时不要连接任何新技能；我会创建一个 GitHub 仓库并将其发布在那里。

执行细节

Claude 进入了 plan mode，加载了两个元技能（executing-plans 和 writing-skills），并将工作划分为三个批次。

批次 1 – 全局约定

• 创建了全局 ~/.claude/CLAUDE.md，其中包含 所有通用约定。
• 对每个项目的配置文件进行外科式的去重，删除重复规则。
• 现在每个仓库只保留 项目特定信息。
• 一个文件、一个位置，由所有后续 Claude 会话读取 → 再也不会出现 “永远不要使用 Python” 的重复提醒。

批次 2 – Openspec 集成

• 不再在仓库中内嵌庞大的文档，而是使用 一行指向新技能的引用。

批次 3 – 技能仓库

创建了 ~/repos/claude-skills/，其中包含三个完整的技能：

~/repos/claude-skills/
├── README.md
├── plugin.json
├── marketplace.json
├── skills/
│   ├── openspec-and-beads/
│   │   └── SKILL.md
│   ├── agent-team/
│   │   └── SKILL.md
│   └── use-bun/
│       └── SKILL.md

openspec-and-beads 技能

将我最常用的工作流形式化：

1. 收集项目上下文。
2. 搭建包含动机和增量规范的变更提案。
3. 将其分解为关联到史诗的优先级 beads。
4. 在实现过程中进行跟踪。
5. 完成后归档。

在此技能出现之前，我会为每个新特性重新解释该概念。现在只需 一次调用。

agent-team 技能

捕获了并行运行多个代理的协作模式。
关键洞见：“cover agent” 模式 – 当某个代理的上下文窗口使用约 50 % 时，让它完成当前任务，为剩余工作创建一个新 bead，并重新生成一个全新的代理接手。

另外还编码了以下规则：

• 每个文件仅限一个代理，以避免合并冲突。
• 在每个逻辑检查点提交。
• 按逆依赖顺序关闭。

use-bun 技能

一张快速参考卡：列出常见 Node/npm 模式的 Bun 等价写法（例如 bunx tsc --noEmit 替代 npx tsc，Bun.file() 替代 fs.readFile）。虽小，却消除了整类 “我该如何用 Bun 做 X？” 的提问。

对测试的思考

writing-skills 元技能建议对新技能使用 完整 TDD：编写测试，观察其失败，然后实现。Claude 的回应相当务实：

“这段内容已经在数百条消息和 240 次会话中经过实证验证。‘测试’已经在数周的真实使用中自然完成。”

它直接进入 编写规范。

那种感觉是对的。技能的 TDD 与代码的 TDD 并不相同。验证已经在实践中完成。此练习的目标是 捕获已经有效的内容，而不是发现新行为。有时最好的测试套件就是 “我做了 50 次，它就能工作”。

最终仓库布局

~/repos/claude-skills/
├── README.md
├── plugin.json
├── marketplace.json
├── skills/
│   ├── openspec-and-beads/
│   │   └── SKILL.md
│   ├── agent-team/
│   │   └── SKILL.md
│   └── use-bun/
│       └── SKILL.md

Takeaways

• 自我分析可以揭示即使是最严谨的流水线中隐藏的重复。
• 将通用约定整合到 单一全局文件 中，可消除令牌浪费并保持工作区整洁。
• 将经常出现的模式转化为 可复用的技能，把“重复解释”变成一次点击即可完成的操作。
• 元技能（计划‑执行、写作）可以 自举它们所描述的过程——递归但强大。

如果你是工作流工程师（或任何大量使用 LLM 提示的人），考虑给自己的流水线做一次 镜像运行：让模型进行自省，然后在下一个会话之前根据洞察采取行动。这样可以获得更清洁、更快速、更 自我感知 的开发环境。

“你的 LLM 对话就是数据。240 次会话中包含了我在其中时看不见的模式。让 Claude 分析自己的会话历史就像对自己的工作流运行分析器；热点路径一目了然。如果你还没这么做，赶紧试试。” – Chintan

全局配置消除了整类浪费令牌的情况。每一次我输入的 “never use Python” 都在消耗上下文和注意力。把一个 CLAUDE.md 放在 ~/.claude/ 中就永久解决了这个问题。如果你在多个项目中使用 Claude Code，这可能是当前最具 ROI 的操作。

技能不过是形式化的习惯。我在本次会话中并没有临时决定使用 openspec‑and‑beads 工作流；我已经用了好几周。技能只是把已经成立的事实写了下来。如果你发现自己对 Claude 重复解释同一过程超过两次，那它就应该成为一个技能——而不是提示，也不是 CLAUDE.md 条目，而是一个技能。这个区分很重要，因为技能携带上下文、结构和顺序，而平铺的配置文件做不到。

“覆盖代理”模式值得成为一等特性。监控代理的上下文使用情况，并在其性能下降前有策略地重新生成它，同时将剩余工作分配为新任务，这在 2026 年仍是我手动完成的工作。当 Anthropic 再次发布基准博客时，我不得不编写技能来管理上下文窗口，因为工具本身不提供此功能……这是一种选择。Anthropic，如果你们在阅读这段文字：请偷走这个想法。我恳求你们。

Open TODOs

• 一个 beads MCP 插件，使代理能够原生查询和更新任务状态，而不是通过 bd 命令调用外部脚本。
• 一个审查流水线技能，用于生成专家代理并将它们的发现转化为后续 beads。
• 一个分支清理技能，因为合并‑删除‑移除的流程每次都完全相同，我已经厌倦了手动输入。

产生以上内容的会话大约用了 22 分钟：三个子代理、大量模式识别，以及从 “嗯，我到底在做什么” 到在 GitHub 上发布插件仓库的转变。对于一个星期六的上午来说，表现相当不错。