terminal-ops

Terminal Ops

当用户需要真实的仓库执行时使用：运行命令、检查git状态、调试CI或构建、进行窄修复，并准确报告更改和验证的内容。

此技能有意比通用编码指导更窄。它是一个面向证据优先终端执行的操作工作流。

技能栈

在相关时将这些ECC原生技能引入工作流：

• verification-loop 用于更改后的精确证明步骤
• tdd-workflow 当正确修复需要回归覆盖时
• security-review 当涉及密钥、认证或外部输入时
• github-ops 当任务依赖于CI运行、PR状态或发布状态时
• knowledge-ops 当需要将验证结果捕获到持久的项目上下文中时

使用时机

• 用户说“修复”、“调试”、“运行这个”、“检查仓库”或“推送它”
• 任务依赖于命令输出、git状态、测试结果或已验证的本地修复
• 答案必须区分本地更改、本地验证、提交和推送

防护措施

• 先检查再编辑
• 如果用户只要求审计/审查，保持只读
• 优先使用仓库本地脚本和辅助工具，而非临时即兴包装
• 在重新运行证明命令之前，不要声称已修复
• 除非分支实际推送到上游，否则不要声称已推送

工作流

1. 确定工作表面

确定：

• 确切的仓库路径
• 分支
• 本地差异状态
• 请求的模式：
  • 检查
  • 修复
  • 验证
  • 推送

2. 首先读取失败表面

在更改任何内容之前：

• 检查错误
• 检查文件或测试
• 检查git状态
• 使用已提供的日志或上下文，避免盲目重新读取

3. 保持修复窄小

一次解决一个主要失败：

• 首先使用最小的有用证明命令
• 仅在本地失败解决后才升级到更大的构建/测试通过
• 如果命令持续以相同签名失败，停止广泛重试并缩小范围

4. 报告精确执行状态

使用精确的状态词：

• 已检查
• 本地更改
• 本地验证
• 已提交
• 已推送
• 已阻塞

输出格式

表面
- 仓库
- 分支
- 请求模式

证据
- 失败的命令/差异/测试

操作
- 更改了什么

状态
- 已检查 / 本地更改 / 本地验证 / 已提交 / 已推送 / 已阻塞

陷阱

• 当可以读取实时仓库状态时，不要依赖过时的记忆
• 不要将窄修复扩大为仓库范围的变动
• 不要使用破坏性的git命令
• 不要忽略无关的本地工作

验证

• 响应中命名了证明命令或测试
• 与git相关的工作命名了仓库路径和分支
• 任何推送声明包括目标分支和确切结果