terminal-ops

terminal-ops 技能概览

terminal-ops 是一款以证据为先的终端执行技能，面向 repo 工作，而不是通用的编码副驾驶。它最适合需要实际运行命令、检查仓库、追踪 CI 或构建失败，或做出一个范围很窄但要有变更与验证证据的修复的用户。

terminal-ops 用来做什么

当任务取决于真实的终端输出时，就用 terminal-ops 技能：检查 git 状态、运行测试、复现 bug、验证修复，或确认某个变更是本地修改、已提交还是已推送。terminal-ops 技能的设计目标是减少猜测，把执行过程和证据链明确下来。

terminal-ops 的突出之处

terminal-ops 的核心差异点在于验证闭环。它会推动你先检查再编辑，优先使用仓库内现成的辅助脚本，并在声称成功之前重新运行能够证明结果的命令。对比泛用提示词，在正确性比速度更重要时，它更有优势。

适合的用户与场景

这份 terminal-ops 指南适合在活跃代码库中工作的 agent 和开发者，尤其是仓库里有 CI、脚本或发布约束的时候。它不太适合高层头脑风暴、纯架构讨论，或者根本不需要终端操作的任务。

如何使用 terminal-ops 技能

安装并定位 terminal-ops 技能

先使用仓库 skills 目录中的 terminal-ops 安装路径，然后先打开 SKILL.md。一个可用的安装命令是：npx skills add affaan-m/everything-claude-code --skill terminal-ops。之后，把这项技能当作终端操作的工作流层，而不是替代仓库约定的东西。

提供能解锁工作流的输入

要高效使用 terminal-ops，起点是清晰的操作目标和约束。好的请求会说明要检查什么、什么算成功，以及任务是只读、修复导向，还是发布导向。

更强的输入示例：

• “在 packages/api 里复现失败的测试，找出最小修复，然后在总结前重新运行相关测试。”
• “检查仓库状态，查看构建日志，告诉我这是代码问题还是环境问题。”
• “针对这次 CI 失败做最小修复，然后在本地验证，并准确说明改动了什么。”

先读对文件

如果是在 Code Editing 场景下使用 terminal-ops，先看 SKILL.md，再查看任何会影响执行的仓库说明，例如 README.md、AGENTS.md、metadata.json，以及如果存在的话，rules/、resources/、references/ 或 scripts/ 这些目录。仓库预览通常只显示 SKILL.md，所以在真实安装后，你要预期支持文件会更少，也要更多依赖技能文本本身。

按照证据优先的闭环执行

terminal-ops 的使用模式是：先检查、再复现、然后有针对性地修改、重新运行证明命令，最后准确汇报验证了什么。第一轮要尽量聚焦在最小且相关的命令或测试上，尤其是当故障可能来自脚本、环境不匹配或 git 状态问题，而不是代码本身的时候。

terminal-ops 技能 FAQ

terminal-ops 是普通提示词的替代品吗？

不是。普通提示词也可以问代码问题，但当工作必须在终端里真正执行并证明结果时，terminal-ops 更合适。它是一套操作型工作流，不只是回答风格不同。

什么时候不该用 terminal-ops？

如果你只想要概念解释、设计建议，或者不需要执行的摘要，就不要用它。若你无法运行命令、检查仓库，或之后无法验证结果，它也不适合。

terminal-ops 对新手友好吗？

可以，只要你能描述清楚一个具体任务，并接受分步骤的工作流。这个技能能帮助新手避免跳过验证，但前提是你能提供仓库、预期行为，以及任何失败命令的输出。

terminal-ops 和更通用的 coding 技能相比如何？

terminal-ops 比通用编码指导更窄。只要终端输出、git 状态和执行证明比广泛的实现讨论更重要，就用它。正是这种窄范围，让 terminal-ops 技能在 Code Editing 和 repo 操作中更有用。

如何改进 terminal-ops 技能

一开始就说清楚你需要什么证据

最好的 terminal-ops 结果来自明确“必须证明什么”：是复现了失败测试、通过了 lint 检查、构建完成，还是分支已经推进到上游。如果你只说“修好它”，工作流仍然有帮助，但输出可能没有那么聚焦。

在第一条提示里减少歧义

把仓库路径、失败命令、相关错误文本，以及诸如“不要改行为”“只读审计”或“最小可行修复”之类的约束都写进去。更强的输入能提升 terminal-ops 的效果，因为它能让技能更早选对检查和验证步骤。

围绕验证迭代，而不只是围绕代码

如果第一次修复不对，就要求更窄的复现方式、不同的测试切片，或者和上一个 git 状态做对比。对 terminal-ops 来说，最有价值的后续通常是更好的证明目标，而不是更长的解释。