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