SKILL.md
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-loopfor exact proving steps after changes
tdd-workflowwhen the right fix needs regression coverage
security-reviewwhen secrets, auth, or external inputs are involved
github-opswhen the task depends on CI runs, PR state, or release status
knowledge-opswhen 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 / blockedPitfalls
- 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