Terminal Ops
当用户需要实际的仓库执行时使用：运行命令、检查 git 状态、调试 CI 或构建、进行窄修复，并精确报告更改内容和已验证内容。
该技能有意比通用编码指导更窄。它是一个基于证据的终端执行的操作员工作流。
技能栈
在相关时将这些 ECC 原生技能拉入工作流：
verification-loop用于更改后的精确证明步骤tdd-workflow当正确的修复需要回归覆盖时security-review当涉及密钥、认证或外部输入时github-ops当任务依赖于 CI 运行、PR 状态或发布状态时knowledge-ops当已验证的结果需要捕获到持久项目上下文中时
何时使用
- 用户说“修复”、“调试”、“运行此”、“检查仓库”或“推送它”
- 任务依赖于命令输出、git 状态、测试结果或已验证的本地修复
- 答案必须区分：本地更改、本地验证、已提交、已推送
安全护栏
- 编辑前先检查
- 如果用户仅要求审计/审查，则保持只读
- 优先使用仓库本地脚本和辅助工具，而不是临时自制的包装器
- 在重新运行证明命令之前，不要声称已修复
- 除非分支实际已推送到上游，否则不要声称已推送
工作流
1. 解析工作表面
确定：
- 确切的仓库路径
- 分支
- 本地差异状态
- 请求的模式：
- inspect
- fix
- verify
- push
2. 先读取故障表面
在更改任何内容之前：
- 检查错误
- 检查文件或测试
- 检查 git 状态
- 使用任何已提供的日志或上下文，而不是盲目重新读取
3. 保持修复窄化
一次解决一个主要故障：
- 首先使用最小的有用证明命令
- 仅在本地故障解决后才升级到更大的构建/测试过程
- 如果命令以相同的签名持续失败，则停止广泛的重试并缩小范围
4. 报告确切的执行状态
使用精确的状态词：
- inspected
- changed locally
- verified locally
- committed
- pushed
- blocked
输出格式
SURFACE
- repo
- branch
- requested mode
EVIDENCE
- failing command / diff / test
ACTION
- what changed
STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked
陷阱
- 当可以读取实时仓库状态时，不要依赖过时的记忆
- 不要将窄修复扩展到整个仓库的混乱更改
- 不要使用破坏性的 git 命令
- 不要忽略不相关的本地工作
验证
- 响应中需命名证明命令或测试
- git 相关的工作需命名仓库路径和分支
- 任何推送声明需包含目标分支和确切结果