opencode-repair
Fix OpenCode issues - blank sessions, missing worktrees, duplicate project rows, DB repair
71
63%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./dot_config/opencode/skill/opencode-repair/SKILL.mdQuality
Discovery
50%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 effectively lists specific concrete issues it addresses within the OpenCode domain, making it distinctive and specific. However, it completely lacks a 'Use when...' clause, which significantly hurts completeness and makes it harder for Claude to know when to select this skill. Adding broader trigger terms and explicit usage guidance would substantially improve it.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user reports OpenCode problems such as blank/empty sessions, missing git worktrees, duplicate entries in the project list, or database errors.'
Include broader natural trigger terms users might say, such as 'OpenCode not working', 'OpenCode broken', 'troubleshoot OpenCode', 'session empty', or 'database corruption'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: fixing blank sessions, missing worktrees, duplicate project rows, and DB repair. These are distinct, identifiable operations. | 3 / 3 |
Completeness | Describes what it does (fix various OpenCode issues) but has no explicit 'Use when...' clause or equivalent trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'when' is entirely absent, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes some natural keywords like 'blank sessions', 'worktrees', 'duplicate project rows', 'DB repair', but these are fairly technical/specific to OpenCode. Missing broader terms users might say like 'OpenCode not working', 'database corruption', 'session problems', or 'troubleshoot'. | 2 / 3 |
Distinctiveness Conflict Risk | Very specific to OpenCode troubleshooting with distinct problem types (blank sessions, missing worktrees, duplicate project rows, DB repair). Unlikely to conflict with other skills due to the narrow, well-defined domain. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong troubleshooting skill with excellent actionability — every diagnosis and fix includes concrete, executable commands with specific file paths and SQL queries. The workflow for the blank session issue is well-sequenced with clear dependencies between fixes. The main weakness is that the file covers multiple distinct topics (blank sessions, binary architecture, web UI bugs, LaunchAgent management) that could be better organized via progressive disclosure into separate files.
Suggestions
Split the Binary Architecture, Web UI Bug Diagnosis, and LaunchAgent sections into separate referenced files, keeping SKILL.md as an overview with links to each topic.
Remove some redundancy in the Notes section — several points (e.g., 'never DELETE project rows', 'mkdir is not enough') repeat guidance already given in the fix sections above.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient and avoids explaining basic concepts, but some sections are verbose — e.g., the 'Common pattern' explanation and repeated notes at the bottom restate things already covered in the fix sections. The notes section has some redundancy with earlier content. | 2 / 3 |
Actionability | Excellent actionability throughout — every fix includes executable shell commands and Python scripts with specific paths, SQL queries, and git commands. The diagnosis steps are concrete and copy-paste ready, and recovery steps for accidental deletions are included. | 3 / 3 |
Workflow Clarity | The diagnostic workflow is clearly sequenced (diagnose in order 1-4), fixes are labeled A/B/C with explicit dependencies noted ('Fix C must be done alongside Fix B'), and validation is addressed ('After any fix: fully quit and reopen Desktop'). The 'three coordinated steps' framing prevents partial fixes. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's a long monolithic file that could benefit from splitting — the Binary Architecture table, Web UI bug diagnosis, and LaunchAgent sections are distinct topics that could be separate referenced files. For a skill of this length (~120+ lines), inline everything is borderline. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- athal7/dotfiles
- Commit
4ed3a13
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.