terminal-ops

Use it when:: You ask the agent to run something, check a repo, fix a failing build or test, or push a fix.
It does:: Pins down repo, branch, diff and mode, reads the error before editing, fixes one failure at a time and reruns the proving command.
You get:: A report of surface, evidence, action and a status word, from inspected through verified locally to pushed, or blocked.
Won't:: Claim a fix before the proving command passes, claim a push the branch didn't make, or run destructive git commands.

TL;DR

An operator workflow from ECC for terminal work where proof matters. It first settles the exact repo path, branch, local diff and which mode you asked for: inspect, fix, verify or push, staying read-only if you only wanted a review. Before changing anything it reads the error, the failing file or test and the git state, using any logs you've already given. Fixes stay narrow: one dominant failure at a time, the smallest proving command first, a bigger build or test pass only after that, and a narrower scope instead of broad retries when a command keeps failing the same way. It prefers the repo's own scripts, leaves unrelated local work alone and avoids destructive git commands. The report names the repo, branch and mode, the failing command or diff, what changed, and a status of inspected, changed locally, verified locally, committed, pushed or blocked; any push claim names the target branch and result. It pulls in ECC's verification-loop, tdd-workflow, security-review, github-ops or knowledge-ops skills when relevant.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill terminal-ops

skills.sh page Source on GitHub All skills from affaan-m/ecc

Total Downloads: 5,400 on skills.sh, Nov 9, 2026
Repo stars: 299,776 affaan-m/ecc
First seen: May 19, 2026 on skills.sh

Weekly Downloads

442

+71% over the 8 weeks to Nov 9

Weekly values

Week to	Installs
Sep 21	258
Sep 28	164
Oct 5	142
Oct 12	232
Oct 19	408
Oct 26	400
Nov 2	469
Nov 9	442

Category	category:engineering category:debugging category:software-engineering Test-first work, implementation from specs, git hygiene and scope control. Find root causes, review code and test what you built. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:remote Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service.
Needs	needs:none Instructions only. Works in any agent that supports skills.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	verification debugging ci scope-control git

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: terminal-ops
description: Evidence-first repo execution workflow for ECC. Use when the user wants a command run, a repo checked, a CI failure debugged, or a narrow fix pushed with exact proof of what was executed and verified.
metadata:
  origin: ECC

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