terminal-ops

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Terminal Ops

终端运维

Use this when the user wants real repo execution: run commands, inspect git state, debug CI or builds, make a narrow fix, and report exactly what changed and what was verified.

This skill is intentionally narrower than general coding guidance. It is an operator workflow for evidence-first terminal execution.

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

本技能的适用范围刻意窄于通用编码指导，它是面向证据优先的终端执行的运维工作流。

Skill Stack

技能栈

Pull these ECC-native skills into the workflow when relevant:

```
verification-loop
```
for exact proving steps after changes
```
tdd-workflow
```
when the right fix needs regression coverage
```
security-review
```
when secrets, auth, or external inputs are involved
```
github-ops
```
when the task depends on CI runs, PR state, or release status
```
knowledge-ops
```
when the verified outcome needs to be captured into durable project context

相关情况下可将以下ECC原生技能引入工作流：

```
verification-loop
```
用于变更后的准确验证步骤
```
tdd-workflow
```
当合适的修复需要回归测试覆盖时使用
```
security-review
```
当涉及密钥、鉴权或外部输入时使用
```
github-ops
```
当任务依赖CI运行、PR状态或发布状态时使用
```
knowledge-ops
```
当验证后的结果需要记录到持久化项目上下文时使用

When to Use

适用场景

user says "fix", "debug", "run this", "check the repo", or "push it"
the task depends on command output, git state, test results, or a verified local fix
the answer must distinguish changed locally, verified locally, committed, and pushed

用户提到"fix"、"debug"、"run this"、"check the repo"或"push it"时
任务依赖命令输出、git状态、测试结果或经过验证的本地修复
回答必须明确区分本地变更、本地验证、已提交、已推送几种状态

Guardrails

护栏规则

inspect before editing
stay read-only if the user asked for audit/review only
prefer repo-local scripts and helpers over improvised ad hoc wrappers
do not claim fixed until the proving command was rerun
do not claim pushed unless the branch actually moved upstream

编辑前先检查
如果用户仅要求审计/审查，保持只读操作
优先使用仓库本地脚本和辅助工具，而非临时编写的自定义封装脚本
验证命令重新运行通过前，不得宣称已修复
除非分支确实已推送到上游，不得宣称已推送

Workflow

工作流

1. Resolve the working surface

1. 确定工作范围

Settle:

exact repo path
branch
local diff state
requested mode:
- inspect
- fix
- verify
- push

明确以下信息：

准确的仓库路径
分支
本地diff状态
请求的模式：
- inspect
- fix
- verify
- push

2. Read the failing surface first

2. 优先读取故障范围

Before changing anything:

inspect the error
inspect the file or test
inspect git state
use any already-supplied logs or context before re-reading blindly

在进行任何变更前：

检查错误信息
检查相关文件或测试
检查git状态
优先使用用户已提供的日志或上下文，避免盲目重复读取

3. Keep the fix narrow

3. 保持修复范围最小

Solve one dominant failure at a time:

use the smallest useful proving command first
only escalate to a bigger build/test pass after the local failure is addressed
if a command keeps failing with the same signature, stop broad retries and narrow scope

每次只解决一个主要故障：

优先使用最小可用的验证命令
仅在本地故障解决后再升级到更大范围的构建/测试运行
如果某个命令持续出现相同特征的失败，停止大范围重试，缩小排查范围

4. Report exact execution state

4. 报告准确的执行状态

Use exact status words:

inspected
changed locally
verified locally
committed
pushed
blocked

使用准确的状态术语：

inspected
changed locally
verified locally
committed
pushed
blocked

Output Format

输出格式

text

SURFACE
- repo
- branch
- requested mode

EVIDENCE
- failing command / diff / test

ACTION
- what changed

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

text

SURFACE
- repo
- branch
- requested mode

EVIDENCE
- failing command / diff / test

ACTION
- what changed

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

Pitfalls

常见误区

do not work from stale memory when the live repo state can be read
do not widen a narrow fix into repo-wide churn
do not use destructive git commands
do not ignore unrelated local work

可以读取实时仓库状态时，不要基于过时的记忆操作
不要将小型修复扩大为全仓库的代码调整
不要使用破坏性的git命令
不要忽略无关的本地工作内容

Verification

验证要求

the response names the proving command or test
git-related work names the repo path and branch
any push claim includes the target branch and exact result

响应中需指明验证命令或测试
git相关操作需指明仓库路径和分支
任何推送声明都需要包含目标分支和准确结果