Skip to content
cccskills
FreePublished on GitHubEnglish overview

terminal-ops

Run repository commands, inspect Git state, investigate CI or build failures, and verify focused fixes. Report the commands and results as evidence, clearly distinguishing local changes, local verification, commits, and pushes.

OriginalShow the original 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.

affaan-m/ECC
AI rating90/ 100See how to install

Good for

  • Inspecting repository and branch state
  • Investigating CI or build failures
  • Making and verifying a focused fix
  • Checking whether changes were committed and pushed

Overview

What it does

Run commands in a repository to inspect its state, investigate failures, make small fixes, and verify the results. The skill first checks the repository path, branch, outstanding changes, and requested scope, then examines errors and relevant files. After a fix, it reruns the command needed to demonstrate the result and reports what changed and what was checked. Reports distinguish local changes, local verification, commits, and pushes so you can see exactly how far the work has progressed.

When it helps

Use it when CI—the system that automatically builds and tests changes—fails, or when you need to fix a local build error. It also helps when you want test and command results as evidence alongside a statement that something has been fixed.

Example requests

  • “Check this repository's branch and outstanding changes.”
  • “Investigate the CI failure, make only the necessary fix, and verify it again.”
  • “Push the changes and report the target branch and result.”

Notes

Audit-only and review-only requests stay read-only. The workflow respects unrelated local changes and avoids destructive Git commands. Related skills such as verification-loop and github-ops are used when needed.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Objective evaluation

AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.

Clear instructionsIs it clear when to use it and what it does?
AGoodUse cases explicitly include running commands, inspecting repository state, investigating CI, and making focused fixes.
Concrete stepsAre steps, inputs, outputs, and examples spelled out?
AGoodIt defines steps from identifying the working surface through verification, plus an output format for evidence, actions, and status.
SafetyAre sending data, deleting files, and running commands disclosed?
AGoodIt requires read-only reviews, prohibits destructive Git commands, and protects unrelated local changes.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingGit operations and related skills are documented, but setup instructions for the required environment are absent.

The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (1)

  • SKILL.md2.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

accessibility

FreeSummaryAI rating 100

Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.

  • Adding descriptive labels to icon-only buttons
  • Reviewing keyboard navigation and modal focus
  • Checking contrast and control sizes
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-architecture-audit

FreeSummaryAI rating 80

Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.

  • Investigating failures that appear only inside an agent application
  • Tracing old conversation content leaking into new sessions
  • Checking skipped or falsely claimed tool execution
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-eval

FreeSummaryAI rating 80

Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.

  • Comparing coding agents on real development tasks
  • Evaluating a new tool or model before adoption
  • Checking performance after agent updates
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-harness-construction

FreeSummaryAI rating 100

Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.

  • Define an AI agent’s tool set and input formats
  • Make tool results and next steps easier to interpret
  • Specify safe retries and stopping conditions
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-introspection-debugging

FreeSummaryAI rating 100

Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.

  • Diagnosing repeated tool calls with no progress
  • Investigating quality loss as context grows
  • Checking file paths and environment mismatches
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-introspection-debugging

FreeSummaryAI rating 100

Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.

  • Diagnosing repeated failures in an agent run
  • Investigating loops through the same tool calls
  • Reviewing output degradation as context grows
affaan-m/ECC283.7KUpdated Oct 5, 2026

See all skills by affaan-m

Report a problem with this skill