PromptsEdge
FreeGitHubAutomation

Terminal Ops

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.

affaan-m on GitHub

Curated by PromptsEdge from a public repo · MIT license. All credit goes to the author.

What is this skill?

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.

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

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

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

Related skills

View all →