Terminal Operations
Original skill by ECC. Credit ECC in copies and updates.
Use this skill when a task needs real work in a repo. This may include running commands, checking Git state, fixing a bug, testing a fix, or pushing a branch.
This skill is for careful terminal work. Base each claim on fresh proof.
Related Skills
Use these ECC skills when they fit the task:
verification-loop: Check that a change works.tdd-workflow: Add a test that fails before the fix and passes after it.security-review: Check work that uses keys, login data, or user input.github-ops: Check CI runs, pull requests, or release state.knowledge-ops: Save useful results for later work.
If a listed skill is not present, keep working with the tools you have.
When to Use This Skill
Use it when:
- The user says "fix," "debug," "run this," "check the repo," or "push."
- The answer needs command output, Git state, test results, or a local code change.
- You must tell the user if work is only changed, tested, committed, or pushed.
Do not use it for a general code question that needs no repo check.
Safety Rules
- Find the exact repo path before you run commands.
- Check the repo and its own guide files before you edit.
- Check Git status before and after edits.
- Keep review-only work read-only.
- Do not edit files when the user asked only for a review or report.
- Keep work inside the user’s request.
- Do not change or remove unrelated work.
- Do not use commands that can erase work, such as
git reset --hard, unless the user clearly asks for them. - Use the repo’s scripts and tools when they exist.
- Do not print keys, tokens, passwords, cookies, or private data.
- Ask before a command may post data, deploy code, publish a release, or change a live service.
- Do not say a bug is fixed until the right check passes.
- Do not say work is committed until a commit exists.
- Do not say work is pushed until the remote branch has the commit.
Workflow
1. Set the Work Area
Find and record:
- Repo path
- Current branch
- Git status
- User’s requested mode:
- Check
- Fix
- Verify
- Commit
- Push
If the repo path or target branch is not clear, inspect safe choices first. Ask the user only if the choice would change the work.
If the repo has uncommitted work, find out which changes are yours. Do not overwrite other changes.
2. Read the Failure First
Before you edit:
- Read the error.
- Read the files named by the error.
- Read the test that fails.
- Check Git status and the current diff.
- Use logs given by the user before you run broad checks.
- Re-run the smallest safe command that can show the failure.
If the failure cannot be run on the local machine, state why. Use the best proof that is still available.
3. Make One Small Fix
Work on one main cause at a time.
- Change only the files needed for the fix.
- Follow the repo’s style.
- Add or update a test when it can stop the bug from coming back.
- Do not clean up other code unless the fix needs it.
- Stop broad retries when the same error keeps coming back.
- Narrow the check to the failing file, test, step, or input.
If a command hangs, stop it safely and report where it stopped.
4. Check the Fix
Start with the smallest useful check:
- Run the test or command that failed.
- Run checks for the changed area.
- Run the full test or build only when needed.
Record:
- The exact command
- Whether it passed or failed
- Any skipped checks
- Any limits, such as no network, missing tools, or missing access
A check that did not run is not a pass.
5. Review the Final State
Before you report:
- Check Git status.
- Read the final diff.
- Make sure no secret or build file was added by mistake.
- Make sure unrelated files did not change.
- If asked to commit, check the commit and its message.
- If asked to push, check the remote branch and push result.
Do not commit or push unless the user asked for it or clearly allowed it.
Status Words
Use only the status that the proof supports:
- Checked: You read the repo state or failure.
- Changed locally: Files changed, but checks may not have passed.
- Verified locally: The named local checks passed.
- Committed: A local commit was made.
- Pushed: The commit reached the named remote branch.
- Blocked: A clear issue stopped the work.
More than one status may apply. For example, work can be "Committed" but not "Pushed."
Report Format
Surface
- Repo: <full path>
- Branch: <branch name>
- Mode: <check, fix, verify, commit, or push>
Evidence
- Failure: <error or failed command>
- Git state: <clean or changed>
- Check: <exact command and result>
Action
- <small list of changed files and what changed>
Status
- <checked, changed locally, verified locally, committed, pushed, or blocked>
Limits
- <checks not run and why>Leave out Limits when there are none.
Example
User request:
Fix the failing parser test and verify it. Do not push.Work:
1. Open /work/parser-app.
2. Check the branch and Git status.
3. Run: pytest tests/test_parser.py -q
4. Read the failed test and parser code.
5. Make the smallest fix.
6. Run: pytest tests/test_parser.py -q
7. Run: pytest -q
8. Check the final diff and Git status.Report:
Surface
- Repo: /work/parser-app
- Branch: fix/parser-empty-input
- Mode: fix and verify
Evidence
- Failure: pytest tests/test_parser.py -q failed on empty input
- Git state: src/parser.py and tests/test_parser.py changed
- Check: pytest tests/test_parser.py -q passed
- Check: pytest -q passed
Action
- Handled empty input in src/parser.py.
- Added a test for empty input.
Status
- Changed locally
- Verified locally
Limits
- No commit or push was requested.Common Mistakes
- Do not trust old notes when you can check the repo now.
- Do not turn a small fix into a repo-wide rewrite.
- Do not hide failed or skipped checks.
- Do not call a partial test a full pass.
- Do not use force push unless the user clearly asks for it and knows the risk.
- Do not switch branches with local changes unless it is safe.
- Do not claim CI passed when only local tests passed.
- Do not claim a push worked from command intent alone. Check the result.
- Do not ignore files changed by other people or tools.