terminal-ops

terminal-ops

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.

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

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

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

Settle:

• exact repo path

• branch

• local diff state

• requested mode:

inspect

• fix

• verify

• push

2. Read the failing surface first

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

3. Keep the fix narrow

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

Use exact status words:

• inspected

• changed locally

• verified locally

• committed

• pushed

• blocked

Output Format

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

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

Weekly Installs530Repositoryaffaan-m/everyt…ude-codeGitHub Stars157.6KFirst Seen11 days agoSecurity AuditsGen Agent Trust HubPassSocketPassSnykPassInstalled oncodex500opencode484gemini-cli481github-copilot480kimi-cli480antigravity480