Terminal Ops
Run evidence-first terminal work—commands, git state, CI failures, narrow fixes—with explicit proof of what ran and what was verified.
Overview
Terminal Ops is an agent skill most often used in Ship (also Build and Operate) that runs evidence-first repo commands and reports what changed, verified, committed, and pushed.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill terminal-opsWhat is this skill?
- Narrow operator workflow: inspect repo → run commands → report changed vs verified vs committed vs pushed
- Explicit guardrails: read-only when asked, repo-local scripts over ad hoc wrappers, no fix claims without proof
- ECC skill stack hooks: verification-loop, tdd-workflow, security-review, github-ops, knowledge-ops
- Triggers on fix/debug/run/check/push language where answers must cite command output and git state
- Distinguishes local verification from remote CI truth via github-ops when needed
- 5 named ECC companion skills in the skill stack
Adoption & trust: 3k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a repo fix or CI answer but agents usually hallucinate success without showing commands, diffs, or test output.
Who is it for?
Indie maintainers who want an agent to operate like a careful on-call engineer with proof lines for every claim.
Skip if: Pure design reviews, greenfield prototyping with no repo, or tasks where the user explicitly forbids terminal access.
When should I use this skill?
User wants fix/debug/run/check/push behavior where the answer must cite command output, git state, or verified test results.
What do I get? / Deliverables
You receive a command-backed narrative separating local edits, verified checks, and git/CI state—optionally chaining verification-loop or github-ops before calling the issue resolved.
- Evidence log: commands run, outputs, and verification status
- Clear separation of local changes, commits, pushes, and CI state
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Ship because the workflow optimizes for proving fixes via tests, builds, and CI-aligned checks rather than greenfield feature design. Testing subphase matches debugging failing commands, interpreting test output, and refusing to claim “fixed” without a verification loop.
Where it fits
Reproduce a failing integration test locally and land a minimal patch with logged commands.
Parse CI logs, rerun the failing suite, and document verified green output before merge.
Trace a production exception to a reproducible local command sequence and confirmed fix.
How it compares
Operator workflow skill for real shells—not a replacement for hosted CI dashboards or passive code review checklists.
Common Questions / FAQ
Who is terminal-ops for?
Solo builders using ECC-style agents who debug real repositories and need honest status on commands run, tests passed, and whether changes left the machine.
When should I use terminal-ops?
In Build when applying a narrow code fix with tests; in Ship when CI fails or pre-release checks break; in Operate when reproducing production errors locally—especially after “run this,” “debug,” or “push it.”
Is terminal-ops safe to install?
It instructs agents to execute shell and git operations; review the Security Audits panel on this page and keep secrets out of prompts when security-review is not in play.
Workflow Chain
Then invoke: verification loop
SKILL.md
READMESKILL.md - 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 ```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 ## 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