tdg-personal/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.
80
80%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has a solid structure with an explicit 'Use when' clause covering multiple trigger scenarios, which is its strongest aspect. However, the individual actions listed are somewhat generic ('a command run,' 'a repo checked'), and the acronym 'ECC' is unexplained jargon that limits clarity. The description would benefit from more specific concrete actions and broader trigger term coverage.
Suggestions
Expand trigger terms to include common variations users might say, such as 'build failure,' 'pipeline error,' 'test failure,' 'broken build,' or 'deploy issue.'
Define or expand the 'ECC' acronym so the description is self-explanatory to users unfamiliar with the term.
Make the listed actions more concrete—e.g., instead of 'a command run,' specify 'execute shell commands with captured output' or 'run build/test commands with logged results.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names several actions (command run, repo checked, CI failure debugged, narrow fix pushed) and mentions 'exact proof of what was executed and verified,' but the actions are somewhat generic and not deeply concrete—e.g., 'a command run' and 'a repo checked' are vague. | 2 / 3 |
Completeness | Clearly answers both 'what' (evidence-first repo execution workflow with proof of execution) and 'when' (explicit 'Use when' clause listing four trigger scenarios: command run, repo check, CI failure debug, narrow fix push). | 3 / 3 |
Trigger Term Quality | Includes some natural trigger terms like 'CI failure,' 'debugged,' 'fix pushed,' 'command run,' and 'repo checked,' but misses common variations users might say (e.g., 'build failure,' 'pipeline error,' 'test failure,' 'deploy issue'). 'ECC' is domain-specific jargon that may not be universally understood. | 2 / 3 |
Distinctiveness Conflict Risk | The 'evidence-first' and 'ECC' framing provide some distinctiveness, but terms like 'command run,' 'CI failure debugged,' and 'narrow fix pushed' could overlap with general CI/CD skills, debugging skills, or git workflow skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured operator workflow skill that excels at conciseness and progressive disclosure. The workflow is clearly sequenced with appropriate validation checkpoints. The main weakness is that actionability could be improved with concrete command examples (git commands, common test runners) rather than purely procedural descriptions.
Suggestions
Add concrete command examples in the workflow steps, e.g., `git status`, `git diff HEAD`, `git log --oneline -5` for 'inspect git state', to make the guidance more immediately executable.
Include a brief concrete example showing the full workflow applied to a real scenario (e.g., a failing test), demonstrating the output format filled in with actual values.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. Every section earns its place—no explanations of basic concepts, no padding. The guardrails, workflow steps, and status words are all tightly written and assume Claude's competence. | 3 / 3 |
Actionability | The workflow provides clear procedural guidance with specific status words and a structured output format, but lacks concrete executable commands or code examples. Steps like 'inspect the error' and 'inspect git state' are directional rather than specifying exact commands (e.g., `git status`, `git diff`, `git log --oneline -5`). | 2 / 3 |
Workflow Clarity | The four-step workflow is clearly sequenced with an explicit 'read before write' checkpoint, a narrowing discipline for fixes, and clear status reporting. The guardrail 'do not claim fixed until the proving command was rerun' serves as a validation checkpoint, and the verification section adds explicit feedback loop requirements. | 3 / 3 |
Progressive Disclosure | The 'Skill Stack' section provides clear one-level-deep references to related skills with brief descriptions of when each applies. The content is well-organized into logical sections (When to Use, Guardrails, Workflow, Output Format, Pitfalls, Verification) without being monolithic or deeply nested. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents