terminal-ops — Claude skill: run commands, debug CI
A repo execution skill: runs commands, reads git state, debugs CI failures and makes narrow fixes with proof of what was actually verified.
npx skills add affaan-m/ECC --skill terminal-ops -a claude-codeWhat terminal-ops does
terminal-ops is an operator workflow, not general coding advice. It kicks in when the task depends on command output: a failing test, a broken build, a repo check, or a narrow fix you want pushed. The skill inspects the error, the file and git state before touching anything.
The workflow is spelled out in steps. First settle the working surface: repo path, branch, local diff, and the requested mode (inspect, fix, verify, push). Then read the failing surface, keep the fix narrow, and report with exact status words: inspected, changed locally, verified locally, committed, pushed, blocked. Output follows a fixed shape with SURFACE, EVIDENCE, ACTION and STATUS blocks.
It pulls in other ECC skills when they fit: verification-loop for proving steps, tdd-workflow when a fix needs regression coverage, security-review around secrets or auth, github-ops for CI and PR state, knowledge-ops to capture the outcome. Worth installing if you run an agent against a real repo and are tired of "should be fixed now". If you only want an audit, the skill stays read-only.
What it helps with
- debug a failing CI run and find the cause
- run a command in the repo and show its output
- make a narrow fix and rerun the proving command
- tell changed locally apart from committed and pushed
- check git state before editing anything
Example prompts for the agent
- run the tests in this repo and show me what fails
- debug the CI failure on branch feature/auth, touch only that test
- commit and push the fix, name the branch and the result
How to install terminal-ops
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill terminal-ops -a claude-code2Manually: put the files in place
~/.claude/skills/terminal-ops/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/terminal-ops/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill terminal-ops -a codex2Manually: put the files in place
.agents/skills/terminal-ops/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill terminal-ops -a cursor2Manually: put the files in place
.cursor/skills/terminal-ops/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC terminal-ops2Manually: put the files in place
.github/skills/terminal-ops/SKILL.md1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill terminal-ops -a gemini-cli2Platform CLI
gemini skills install https://github.com/affaan-m/ECC --path skills/terminal-opsManually: put the files in place
.devin/skills/terminal-ops/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill terminal-ops -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set146
The whole set →Similar
Questions about terminal-ops
How do I install terminal-ops in Claude?
Run npx skills add affaan-m/ECC --skill terminal-ops -a claude-code. The skill lands at ~/.claude/skills/terminal-ops/SKILL.md.
What does terminal-ops do?
It drives an agent through a repo: runs commands, reads git, debugs CI and build failures, makes a narrow fix, and reports exactly what was verified.
How is terminal-ops different from general coding guidance?
It is deliberately narrower: a terminal execution workflow where the answer rests on command output. It will not claim a fix until the proving command has been rerun.
Source text
SKILL.md · MIT
--- 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 ```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
© affaan-m · MIT · affaan-m/ECC