Back to Details

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相关操作需指明仓库路径和分支
  • 任何推送声明都需要包含目标分支和准确结果